New Bound and Blinded State TEL with blind that includes anchor to Issuee Key State at time of blindable update

[SmithSamuelM]

Bound and Blinded State Update for ACDC TELS

The blinded state field whose value is the blinded SAID or BLID could represent extended data structures that are similarly blinded but include additional fields. This proposal is for such an extension which includes in the blinded state the Issuee's sequence number and SAID of the current key event from its KEL. This would anchor the key state of the Issuee at the time of the state update via the bup event to the state of the ACDC given by the TEL and indirectly to th key state of the Issuer at the time of the bup event.

New Group Code

The new data structure would need a need group count code so that one or more of these blinds may be disclosed (unblinded) via an attachment to some other message.

Proposed new group code

 BoundStateSextuples: str = '-b'  # Bound Blinded transaction event state sextuples blid+uuid+said+state+bsnu+bsaid.
 BigBoundStateSextuples: str = '--b'  # Big Bound Blinded transaction event state sextuples blid+uuid+said+state+bsnu+bsaid.

# Bound Blinded State sextuple for Blindable State Update Event 'bup' for Transaction
# Event Registry. Binds the key state of the issue to the state update. This
# effectively cross anchors the issuees key state to the issuers key state at
# the time of the state update so that downstream issuances by issuee can be
# verified against the delegated entitlements (authorizations) from issuer
# d = SAID digest qb64 of blindable state (Noncer)
# u = UUID blind as deterministically derived from update sn and salty nonce (Noncer)
# td = SAID of ACDC top-level 'd' field value (Noncer)
# ts = state as string text (Labeler)
# bn = bound issuee key event hex sequence number at time of state update
# bd = bound issuee key event SAID at time of state update
# use BoundStateSextuples count code for CESR native
BoundState = namedtuple("BoundState", 'd u td ts bn bd')

Examples

Blind for Placeholder update

BoundState(d='EGzAGcDAmzaZ75IaHqjSz1lZsD59dBx-_BcxQer6UMnv', 
                     u='aG1lSjdJSNl7TiroPl67Uqzd5eFvzmr6bPlL7Lh4ukv8', 
                     td='', 
                     ts='',
                     bn='0',
                     bd='')

Blind for Populated update

BoundState(d='EO3Yn2kNnNTk94q2ppkUB9UyYq4mcw0d32ja7YymDQAn', 
                     u='aLfCdNAnc-0P2SiruarZSajXiUWu5iU2VfQahvpNCyzB', 
                      td='EMLjZLIMlfUOoKox_sDwQaJO-0wdoGW0uNbmI28Wwc4M',
                      ts='issued', 
                      bn='2', 
                      bd='EJOnAKXGaSyJ_43kit0V806NNeGWS07lfjybB1UcfWsv')

CESR encode group with two BoundStates above in group

(b'-bBJEGzAGcDAmzaZ75IaHqjSz1lZsD59dBx-_BcxQer6UMnvaG1lSjdJSNl7Tiro'
          b'Pl67Uqzd5eFvzmr6bPlL7Lh4ukv81AAP1AAPMAAA1AAPEO3Yn2kNnNTk94q2ppkU'
          b'B9UyYq4mcw0d32ja7YymDQAnaLfCdNAnc-0P2SiruarZSajXiUWu5iU2VfQahvpN'
          b'CyzBEMLjZLIMlfUOoKox_sDwQaJO-0wdoGW0uNbmI28Wwc4M0MissuedMAACEJOn'
          b'AKXGaSyJ_43kit0V806NNeGWS07lfjybB1UcfWsv')

Discussion

An ACDC can be used as a contingent delegated entitlement. These are big words for authorization. Contingent means it can be dynamically revoked or otherwise made invalid based on some conditions (contingencies). A revocation registry as a TEL is one way to make an ACDC contingent. Delegated in this sense (not to be confused with a Delegated AID) means that some Authoritative entity, as represented by their AID, issues an entitlement to some other AID. The issuer is the entitler and the issuee is the entitlee. In an ACDC, this means the ACDC is targeted, it MUST have an Issuee AID inside its a attribute section.

In the world of access control, the term "Authorization" is equivalent to a contingent delegated entitlement. Therefore, for the sake of brevity. The remainder of this discussion will use authorization to mean an ACDC that has these features. Because authorization is a cumbersome word to repeat over and over, the access control community uses the shorthand "AuthZ" to refer to the concept of authorization.

With ACDCs, we have two parties and several data structures that are involved in the process of AuthZ. Therefore, at the risk of introducing new terms, I will use the following shorthand:

authzon = authorization an ACDC with an Issuer and Issuee and a blindable state tel that can dynamically revoke the associated ACDC
authzer = authorizer as represented by its AID (Issuer of an authorization)
authzee = authorizee as represented by its AID (Issuee of an authorization)
authzed = authorized

Chain of Authority

A chain of authzons is constructed when an authzee of one authzon becomes the authzer of another authzon, but which the authzon links back to a higher authzon in the chain of authority. The semantics of the edge in a given authorized authzon (i.e. lower in the chain of authority) is that the lower authzon needs to have an edge that links back up the chain to its authorizing authzon. The "delegation" of authority forms a two-way chain-of-authority. The issuee in an authzon is linking the authorizee who is being authorized. The Issuer is indicating the authorizer, and when a given authzon is itself authorized by a higher authority, then that authzon has an edge that links back to that higher authzon in the chain. So downward via issuer to issuee, upward via edges to the next higher authzon,

The semantics of a given edge that creates an authzon (authorization) chain-of-authority can attentuate the authority so authzed.

Because edges can be multiple, the general structure is a tree of authority where a given authzee can be authorized by multiple authorities linked upwardly by multiple edges in the authzon that is authorizing that authzee. This enables authority to be aggregated.
Without loss of specificity, when referring to a "chain-of-authority" using ACDCs as authzons, it is understood that any chain could have a tree structure.

The following mnemonic captures the full description of how a "chain-of-authority" using ACDCs works.

TADAAA for Tail Authenticated Delegated Attenuated Aggregated Authorization.
Unlike conventional access control mechanisms that employ bearer tokens, which are authenticated when issued, i.e., head authenticated, ACDCs, as authorizations, are authenticated when presented to the verifier who is distinct from the Issuer. This we call tail authentication. The authorization is authenticated at the point of use (tail), not merely at the point of issuance (head). This better supports the open-loop Issuer-Holder-Verifier model. Tail authentication is inherently more secure.

Issues with verifying Downstream Authzed Issuances

Because a given authzon may be revoked (or otherwise invalidated by the its Authzer). Depending on the agreed upon semantics for a given chain-of-authority so constructed this could breaks the chain-of-authority.

The open question is what happens to the authority of downstream authzons that were issued before their authorizing authzons were revoked or indirectly when some authzon in their chain-of-authority was revoked. In other works, what happens to authzons that were valid i.e. had a verifiable chain-of-authority at the moment of issuance but whose chain-of-authority as since been broken. Should those authzon's still be valid if there own revocation state is valid despite the chain-of-authority being broken at the time of validation not issuance?

In may applications the preferred answer would be Yes. An authzon whose revocation state is still valid "issued" and has not yet been revoked should still validate (verify as valid) even though some authzon to which the given authzon is chained has been revoked but which was not yet revoked at the moment of issuance of the given authzon that is at the end of that chain.

How to securely bind Issuee Key State

There are many potential solutions to this problem. However, given the blindable state update mechanizm introduced in ACDC v2, once seems particularly compelling. That is in the blinded state structure that is referenced by the blindable update event bup include a seal (anchor) to the key state of the authzee's AID by referencing the sn and SAID of its current key event.

We can assume that for chained authzons, that a downstream authzon issued by that authzee will have a blindable state TEL of its own. Which state is sealed (anchored) in the KEL of that authzee. Therefore if the authzer includes a reference to the latest event in authzee's KEL, a validator will be able to verify that a downstream authzon's seal or anchor in the authzee's KEL was anchored before the authzers state update was issued.

From a ordering perspective this imposes a partial ordering of any authzons in a chain.
In order to seal (anchor) a Key event, that event had to exist before the anchoring event. This means from a valid authority point of view, a given state update that changes state, the change applies to events in the authzee's KEL after the event so anchored in the state update. So that state of an issuance that happens in or before an anchored key state event that is then anchored in a state update is not changed by the state update. But any issuances anchored subsequent events are affected by the state change.

Thus we can bind all down stream authzons in such a way that at any point in the future a validator can cryptographically verify the
authorization state of any authzon in the chain despite dynamic breaks in that chain.

Complications

Because KELs can have rotation recovery events that dispute prior interaction events up to but not including the most recent rotation event or if delegated AIDs can dispute events up to an including the most recent rotation event, then we would have the corner case
where an downstream authzon state was anchored in TEL state update event which anchor points to an event invalidated by a recovery rotation of the authzee.

This is actually not fatal, since the the authzer had to have "seen" the later disputed event so the time frame in the KEL wherein the chain of authority was unbroken can still be determined as long as the authzee keeps a copy of its KEL with the now disputed event. The authority of the authzer is still valid in that it saw that event. This is complicated but still doable.

A mitigation, is that one purpose of blindable state TELs is to decorrelate state update events from the actual changes in state. This means that an authzer can issue state updates on a regular basis that provide checkpoints to the current authzee key state. This minimizes the window where a given rotation recovery might impinge on a given downstream issuances validity.

Example:

Amy is root authorizer = authzer
Bob is downstream authzee relative to Amy
Bob issues a PO to Cal under authority from Amy

Setup

ak1 means event at sn=1 in Amy's KEL
abt1 means event at sn1 in Amy's TEL for authzon to Bob
bk1 means event at sn=1 in Bob's KEL
bct1 means event at sn=1 in Bob's TEL for its PO to Cal

acdc1 is some ACDC

Square brackets following a symbol for a KEL or TEL means an anchor to the KEL or TEL in the brackets.
For example ak1[abt1] denotes ak1 KEL event has anchor referencing abt1 TEL event

Chain-of-authority and events

At ak2 Amy anchors abt1 which gives Bob a state of "issued" for Bob's authzon via ACDC0 from Amy so we have:

Issuance
```ak2[abt1]``

Suppose that abt1 includes an anchor to Bob's key state bk1 so we have:

Bound Issuance

ak2[abt1[bk1]]

Now Bob issues a PO to Cal via ACDC1 with TEL event bct1. This is anchored in Bob's KEL at bk3. This gives:

bk3[bct1]

Let say Deb wants to validate ACDC1 when it is presented to Deb by Cal.

First Deb verifies that the latest event in bct1 shows that the state of ACDC1 is issued (by Bob) and that this event is anchored in Bob's KEL at bk3.

Second Deb checks that the latest event in the TEL for ACDC0 is abt1 and that event has state of issued.
Third Deb checks that the anchor in abt1 which is bk1 is for an event that is earlier than the anchor in bk1 for bct1. This means that
the PO was issued by Bob after Bob was authorized by Amy to issue the PO.

Since all the issuances are stil valid. Deb has verified the chain of authority for the presentation by Cal of the po ACDC1.

Suppose some time later Amy revokes Bobs authority to issue PO. Amy does this by issueing TEL event abt2. The event has anchor to Bob's current key state that is bk6. This new Tel event is anchored in Amy KEL at ak4.

ak4[abt2[bk6]]

Lets say that Cal tries to present the same PO to Deb. Suppose that Bob has not revoked the PO itself. So bct1 is the latest event in the TEL for ACDC1. So this part stil validates for Deb.
Now Deb goes to validate the chaink of authority for Bob.
Deb first checks the latest event abt2 in the TEL for ACDC0. Deb sees that abt2 has state of revoked.
Now Deb has to verify if Bob still had authority when ACDC1 was issued even though Bob no longer has authority to issue POs because ACDC0 has been revoked.

As before Deb checks that abt1's anchor to Bob's key state is to bk1 which is before bk3 when the ACDC1 was issued. Deb also checks
that abt2's anchor to Bob's key state is bk6 which is after bk3 when ACDC1 was issued. So ACDC1 was issued after Bob was authorized and before Bob was de-authorized to issue POs. So Deb correctly can validate that at the time of issuance of ACDC1 Bob had the authority from Amy to issue it despite that fact that at the dtime of Deb doing the validation Bob no longer has authority to issue POs for Amy.

Recall that a blinded state can be unblinded by the authzee because the authzee has knowledge of the blinding factor salty nonce. The unblinding is more complicated when the key state anchor is included because there are now more combination to check. But the authzee can walk their own KEL near the time of an observed state update to find the anchored state in the update.

While it may seem unnecessary for a validator to ever check the initial condition where the authzon was issued before the key event where the authzee issues a downstream issuance because there wold be no way for that downsteam issuance to refer to its authorizing authzon before that authzon is created. Checking the initial condition supports an on again off again use case. A given authzon might be suspended and then re-activated. So the "state" could be issued, revoked and reissued. Or more appropriately, issued, suspended, unsuspended, etc. This may be more convenient and lower friction than starting from scratch in issuing a competely new authzon once a prior authzon has been revoked. The setup and negotiation and assurance processes around initial issuance would not have to be redone when a given authzon is merely suspended not revoked or if revocation was not final but could be reversed.

Remarks

Because the Authson state and anchors to the Authzee's key state are in the blinded state structure, a third party cannot observe the state of the chain of authority for any authzee. Only second parties who must validate a presentation may observe given that the presenter unblinds. This makes the state of a chain-of-authority confidential and allows one to engage in graduated disclosures when presenting an ACDC which graduated disclosure can be extended to the TEL issuance/revocation associated with that ACDC.

When a chain of authority is long, it may be difficult for a validator to validate. For example, the Authzee at the bottom of the chain may have trouble producing all the unblinded state updates all the way up the chain. For chain's of authority that lie within an organization or at least the blinded portions of that chain-of-authority then the whole chain might use the same shared blinding factor salty nonce. This nonce would then be changed on some regular interval established by that organizations IT policy.

Another way to mitigate this is to use KERI enabled access to the blinded states further up the chain. A given Authzer could respond with unblinded state updates by attaching the unblinded state to a TSP protected response to signed qry from a dowstream authzee AID. This enables granular access to confidential information based on a whitelist of Authzee AIDs.

A variant of this would be to eat one's own dogfood and have upstream Authzer's require a presentation of any downstream Authzee's authzons in order to gain access to blinded information about dynamic changes to that authzees own chain-of-authority. Once of authority has been broken the authzee would be denied access. Therefore no whitelists of AIDs needed. The chain-of-authoriies set of TELs with anchored key states implements the policy engine for access to itself.

In some cases, however, the upper links in the chain do not need to be confidential (blinded) so those could be published via unblinded state attached to the update events. This uses the existing bup update events in the TEL, but a reply to a quey for the TEL event could have the unblinded state attached. Having some links in the chain of authority public this way, makes the chain-of-authority a mixed blinded and unblinded chain.

Question Change the Update upd message to include bn bd fields or remove it completely?

Currently the non-blindable state update event message upd is a fixed field at the top level. Given the advantages of anchoring the authzee (Issuee) key state to the TEL event update maybe the upd event message should be changed to add bn and bd for bound sn and bound said of the Issuee key state. The bd value can be empty when unbound..

In this vein, a new more complicated but extensible update type message could be defined , with an attribute field block that is a field map to include the key state anchors of the Issuee when such information does not benefit from being confidential (blinded).

Alternatively, given that a blindable state update is easily unblinded at any time by attaching the unblinded data with the update, why support both and non-blindable and blindable mechaanisms. This requires more code mainataneance more tooling etc. Originally, because, the V1 TELS are not blindable, the non-blindable state update was proposed for backwards compatibility, but this may be a bad idea for all the reasons that it is not minimally sufficient means. We only really need the blindaable state update.