Guardianship for SEDI

[SmithSamuelM]

Guardianship in the SEDI Context

Included here are some diagrams of ACDC Chained Graphs that could implement Guardianship in the SEDI Context.
These are notional arrangements for discussion and do not reflect any as yet to be specified State of Utah policy.

The examples below only model a very small subset of potential guardianship relationships.
These are meant to model specifically the Social Age Law that requires children to be at least 13 to engage in social media and
to also enable Parents to control or limit the access to social media of Non-Adult children.

Specifically, this means that the entity with the rights to authorize access of a 13-18 child is the legal guardian or guardian.
So the relationship in this case is that the child, as a citizen ward, has restricted rights to access social media. A parent can further modulate those rights. This looks like a delegation relationship where a child, meaning to access social media, must present proof of citizenship in order to fall under the jurisdiction of the laws of Utah and proof of age 13-18. This simple proof would not require guardianship at all. But the final property is to enable the parents' further ability to restrict social media access even for the ages 13-18 requires delegated authorization to the child from their parents(s) (guardians).

There are other guardian relationships that flow the other way. For example, an elderly person might wish to delegate to one of their Adult children a Power of Attorney (PoA) that gives the child the right to act on the elderly person's behalf. This is fundamentally different in several ways from social media access.

POA delegation requires that the Elderly person already be an adult of sound mind at the time of delegation. A child has yet to be an adult and so never had the right to delegate such a power. Indeed, a parent inherits certain rights by virtue of being a parent. And only the parent can delegate those rights back to the child.

There are other relationships where the Parent seemingly acts on behalf of the child, but the actual obligation imposed under law is a requirement on the parent, not the child. This extends to behavior by the child that the parent is responsible for like criminal fines upto $2000 and damage to school property.

In general, parents are assumed to be acting in a responsible manner with regard to the child as a ward or protectorate of the parent, soley by virtue of parenthood not via a specific act of delegation from the child. The Parent is endowed with the right to govern their child, not the other way around. This right decreases with age, and at a certain age children have a limited ability to emancipate themselves from the governance of their parents. LIkewise there are other rights that children are endowed with that a parent can not subrogate or impinge upon.

Guardianship credentials for other use cases parent and child may have a different structure.

To clarify, the legal relationships that are often labeled under the umbrella of guardianship are varied, and no one single set of ACDCs is likely to fit them all.

This discussion specifically models the property that a ward has a limited set of citizen rights, which rights are held by their parents and must be delegated back to their child, i.e., the parent is the supervisor of the child and can delegate responsibilities or entitlements to their child as ward.

One helpful line of discussion is to retrace the parent child relationship to the momemt of birth. Recall that a digital identity requires access to digital resources and the ability to use those resources. This typically means a wallet running on a computing device such as a mobile phone, tablet, or computer. At birth, a child has no ability to use digital resources and would not have access to such resources unless given them by their parent. So a birth it would be nonsensical to imagine a child delegating or granting to their parent any sort of authority or authorization. Indeed, given that the child has not ability to do anything, it would be nonsensical for the parent to delegate anything at all either. However, the parent could hold and manage the controlling keys that govern the digital identity of the child. This means that any use case where the child is required to present something or have something presented on their behalf it must be done by the parents. Thus the parents could be the custodians of the child’s digital identity. Any digital presentations could be done by the parent’s from a parental computing device because the parents would have control of the cryptographic keys that control that digital identity. Building from that foundation, most applications are the parent operating the child’s digital identity for the child. Its only when the child becomes old enough to operate a computer by themselves, and maintain their own digital identity that it makes sense for a child to have separable access to online resources. In that case, the Parent would delegate to their child attenuated capabilities to access those online resources. This is the model shown here.

Basic Guardianship Relationship: Guardian and Ward

Each citizen has a core SEDI citizenship credential. In this model of guardianship, Wards are lesser citizens since their rights of action are restricted or modulated by their guardian. Specifically in the case of parent as guardians the parents would initially be the controller of a child’s digital identity with custodianship over the cryptographic keys that control that digital identity. So if the State issued a SEDI to the Baby they are issuing it to an AID controlled by the parents not the Baby. An open question is at what age does it make sense for an infant to first have a SEDI. Is it at birth with parents as proxy custodians of that baby’s SEDI? Or only once the child is old enough to control a digital computing device?

Examples

Ward with Single Guardian

Ward with Single Guardian who Issues Delegated Authorization to Ward

The field AuthZ contains the specifics of the authorization. The syntx TBD. However some thought on the syntax is found in the presentations on EVAC (Edge Verifiable Agent Control)

Ward with Multiple Guardians where one issues authorization

DAG of ACDCs showing more Compoles Transfer of Authority Given Death of Primary Guardians

Bound Blinded Transfer Registry

A common use case for multiple guardians is that there might be a case (such as divorce) where the Guardianship is changed. There are two ways to handle a change.

The first is to revoke and reissue all the guardianship credentials (not the Guardian as Citizen credentials but the Ward and Guardian and Guardian credentials). Essentially starting over. This has the disadvantage that such reissuance might
add unnecessary friction and latency that may result in protection gaps where wards might be in limbo with respect to enforceable rights during the transition from a now outdated set of credentials to the new ones.

The second is to build into the structure a way to transfer control without starting over. This could allow a single revocation and transfer that does not expose the ward to risk, as it could happen automatically, in stride. This approach leverages to features of ACDC the first is a bound blinded state registry which registry could allow transfer of control. The second is also a bound blinded state registry that uses a new proposed transfer event that simplifies the transfer process. A bound blinded state registry manages delegable authority by binding the key state of the delegation so that a break in the chain of authority can be precisely verified in extent.

Bound Blinded Registry Delegation

Bound Blinded Registry Delegation with Transfer via Reversion of Control

Bound Blinded Registry Delegation with Transfer via Transfer Event

Edge Verifiable Agent Control

d = SAID
i = Issuee
rd = issuee usage registry SAID
rc = resource capabilities map 
       {
            rsourceroute1: [cap list read, write etc],
            resourceroute2: [cap list  read, write etc]
       }

[dhh1128]

Thank you for the diagrams, Sam. I had built a worked example of SEDI guardianship in #1530 before you posted this, and putting the two side by side leaves me with several questions I can't settle on my own.

Your Ward AuthZ Social credential is an argument for E1E that hadn't occurred to me. Its issuer is the guardian and its issuee is the ward, and the edge it draws to Ward as Citizen Ward reaches a credential the State issued to that same ward. Same issuee, different issuers. I2I rejects that edge and NI2I says nothing about it, so the edge carrying the most weight in your social-media case is the one #1527 exists for. That's a second use case beyond the identity/age pairing that motivated it, and a stronger one. I like it.

Your Guardian as Guardian credential carries the Ward AID in the attribute block, next to the Guardian Issuee AID. I put the ward only on an edge. Both keep the issuee as the guardian, so holder != subject holds either way, and I think the difference is about disclosure rather than impersonation. Your own point in #1515 is why I'd argue for the edge: "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." We both have the authority credential being disclosed whole, so an attribute ward AID reaches every verifier unconditionally, while an edge can wait for the contract terms. I might be missing something the attribute placement buys.

The direction of the edges differs too. Yours point from the guardianship up to the guardian's own citizen credential, and from the ward's citizen credential down to the guardianship, so the ward's credential declares that it is encumbered. Mine point from the guardianship to the ward's sedi-id and to a birth certificate, and never touch the guardian's own SEDI. Yours has a property mine lacks, in that a verifier holding only the ward's credential can see the restriction without being told about it. It also seems to have a cost, which is that the ward's credential has to be reissued whenever guardianship changes. But I don't care about that cost that much, and anyway, I think your Bound Blinded Transfer Registry section can remove it, right?

The multi-parent diagram and the priority-switch diagram both need edge groups, and edge groups crash in keripy today. Both places that walk the e section assume every non-d/o label is a flat edge carrying n: the edge loop in Verifier.processCredential, and Reger.sources at src/keri/vdr/eventing.py:2663. A nested group raises KeyError: 'n' in both. I measured that while looking at ME for #1555, and #1560 is the fix; it's open. Priority Switch is also not in the m-ary table in the spec, and its rule, switching off inactive higher-priority edges, depends on what "inactive" means. That is the same sort of thing I got stuck on for NOT, NAND and NOR in #1571, where I could not find a definition of "invalid" anywhere in the spec. I'm glad to write the spec text for either one if you tell me what you want it to say.

Two things came out of the bulk-issuance work that bear on guardianship in particular.

The first is index alignment across holders. In the independent-registry example I'm writing now, sedi-age copy k carries an E1E edge to sedi-id copy k, and that works because one holder derives both sets from salts she controls. Guardianship needs the guardian's credential copy k to point at the ward's sedi-id copy k, and those are two holders, two sets, and possibly two agencies. I can't find anything in 15.4 that says how the index gets coordinated across them. Without an answer the guardian's copies all point at one stable ward credential, which puts back the correlator bulk issuance removes, and puts it in the credential the ward has the least control over. Is there an intended answer here, or is this something that should be written up?

The second is revocation. Guardianship ends globally, by majority, death, restored capacity, or court order. With one registry per copy, revoking is M writes, and a partial revocation leaves some verifiers seeing a terminated guardian as valid. Per-copy revocation is what you want for an over-21 spend and close to the opposite of what you want for an authority credential. The batch root seal looks like it answers this, since all M revocation events can ride one anchor and get the padding at the same time, but I don't see the requirement stated. It seems like the spec should distinguish entitlement credentials from authority credentials on this point.

Last thing. #1530 models the guardian presenting about the ward, which is the case for an infant or an incapacitated adult, where the guardian holds the keys. Your diagrams model the guardian issuing an authorization to the ward and the ward presenting it, which is the 13 to 18 social-media case. Your text distinguishes those two regimes carefully, so I don't think either of us is modeling the wrong thing, but I'd rather build the one Utah needs first. I'm going to assume it's the 13-year-old. If not, please let me know.

Related to that: Utah has said they don't want to depend on a separate GCD credential, so the fine-grained authorization has to be carried inline. Your AuthZ field is where I'd put it, and the EVAC resource-capabilities map is the only sketch of the syntax I have. Is EVAC written down anywhere beyond the presentations?

[dhh1128]

I asked above whether EVAC is written down anywhere beyond the presentations, and I still do not know. But I built the ward-presents shape from your second diagram, and the rc sketch ran into something concrete on the way, so here it is regardless of where the syntax ends up.

A resource route cannot be a map label in native CESR. Labels are governed by ATREX in src/keri/help/helping.py:462, which is ^[a-zA-Z_][a-zA-Z0-9_]*$, and Labeler enforces it on every native field map. An ACDC attribute section is always compacted through a strict Compactor, so there is no way to opt out for one block. A route written the obvious way, social/feed, raises SerializeError rather than failing validation somewhere a schema could catch it first. I only tripped over this because the example serializes across all four kinds; in JSON alone it looks fine.

The fix seems to be to carry the route as a value rather than a label, so rc becomes a list of {route, caps} pairs instead of a map keyed by route. That also buys the same thing the ordered-list form of dp bought in #1549: two routes that differ only in a character the label grammar forbids stay distinct, and two equivalent capability sets serialize identically. If rc stays a map, the routes have to be restricted to the label grammar, and slashes are out.

My example takes the second path for now, using _ as the separator and pinning the routes with a schema propertyNames pattern asserted equal to ATREX so the constraint is visible where someone would otherwise reach for a slash. It is in tests/acdc/test_ward_authz_presentation.py on a branch, and it models your diagram as drawn: four credentials, the AuthZ credential issued by the guardian to the ward with an I2I edge to the guardianship and an E1E edge to the ward's own citizen credential.

One other thing came out of building it that is not about EVAC and probably belongs to guardianship generally. An authority credential disclosed whole leaks whatever its validity dates are derived from. A custodial-parent guardianship whose effectiveDate is the date the parental right arose is the ward's date of birth, exactly, and expiryDate at majority is that same date shifted by eighteen years. So a credential held by the parent and about the parent's authority hands a verifier the child's birthday, in the same exchange that is carefully disclosing only an over-13 predicate from the child's own credentials. The first is avoidable by using the date the State recorded the relationship. The second is not avoidable at the credential layer, since the verifier does need to know when the authority lapses, so it wants either a coarsened date or validity carried solely in the registry. Worth a line in whatever governance framework ends up attached to these.

[SmithSamuelM]

@dhh1128

Your Guardian as Guardian credential carries the Ward AID in the attribute block, next to the Guardian Issuee AID. I put the ward only on an edge. Both keep the issuee as the guardian, so holder != subject holds either way, and I think the difference is about disclosure rather than impersonation. Your own point in #1515 is why I'd argue for the edge: "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." We both have the authority credential being disclosed whole, so an attribute ward AID reaches every verifier unconditionally, while an edge can wait for the contract terms. I might be missing something the attribute placement buys.

I agree that putting the WARD in an edge enables a layer of graduated disclosure. But that requires. a different ACDC. In my diagram the Ward SEDI has an edge back to its guardian so the guardian ACDC can't also have an edge back to the WARD (not a DAG not possible with SAID calculation).

The Ward ID can be partially disclosable by nesting it in its own subblock in the attribute section, not a field at the top level. Which is preferable to creating a new ACDC if for no other reason. An ACDC with and edge verses a partially disclosable block tradoff is usually determined by the Issuer. If two pieces of information have different issuers then they must be in different ACDCs and then a blindable edge enables graduated disclosure. If the two pieces of information have the same issuer then a blindable sub black in the attribute section is all that is needed.

The reason for the ward's SEDI having an edge to its guardian is that the legally responsible party is the guardian not the ward so the the ward only gets a SEDI if and wen the guaradian chooses to allow it. (usually this means that the guardian is managing the keys of the ward or at least the rotation keys).

The multi-parent diagram and the priority-switch diagram both need edge groups, and edge groups crash in keripy today.

Not surprised. The vlei doesn't use edge groups,

I asked above whether EVAC is written down anywhere beyond the presentations, and I still do not know. But I built the ward-presents shape from your second diagram, and the rc sketch ran into something concrete on the way, so here it is regardless of where the syntax ends up.

I started an EVAC white paper but have yet to publish it.

A resource route cannot be a map label in native CESR. Labels are governed by ATREX in src/keri/help/helping.py:462, which is ^[a-zA-Z_][a-zA-Z0-9_]*$

Yes I overlooked that in the example. I suggest using either a tuple of (route, [capabilities]) with a descriptive label or making the set a list of field maps instead of trying to find a different delimiter.

{
       "dog":  ("dog/go", ["read", "write"]),
       "cat":   ("cat/go", ["read", "write"]),

}

[
      (
           "route":  "/dog/go",
           "caps" : ["read", "write"]
      },
     {
            "route":  "/cat/go",
           "caps" : ["read", "write"]
     },

]

The later is what I originally wrote down but then tried to simplify it by making the route the label but forgot about the label restrictions.