Samuel Smith

Eventually we will be able to further simplify the key state notification by removing the `a` field that contains an event seal when the endorser has a transferable identifier. This...

After thinking about the anticipated effort to support key state notification requests I think its worth the effort to add the new complex attachment group. The new attachment group is...

@pfeairheller > I assume the demise of the VRC receipt will wait for another time? Yes it will break a lot of code and interoperability to kill VRC just now....

Given what appears to be consensus I checked in the python code with the latest revised ksn and updated the code table. If there are no objections I will update...

I am not absolutely sure we need the `te` in the key state notice but I am not absolutely sure we don't either. The commitment an endorser makes to the...

I believe that after some thought, that at least given our current set of event messages, that is, icp, rot, dip, drt, ixn, that we do not need the `te`...

In thinking about actually using key state notice when the event is delegated. Not having the full delegation location seal in the key state means that one MUST look up...

With regard the specific label for the message type of the latest event for the `ksn`, in KERI compact labels we tried to find one letter labels for all the...

# Revised Key State Notice with `f`, `dt` and `p` fields One helpful approach to refining the `ksn` is to find a seminal use case and see if the `ksn`...

@pfeairheller Short answer yes. A longer answer: There are several mechanisms one may use for security: One mechanism is a cryptographically verifiable data structure from a cryptographic root of trust...