Registrar Backers

[SmithSamuelM]

Registrar Backers

Unlike witness backers, registrar backers have associated metadata that specifies the registry or ledger upon which the registrar backer anchors the KEL events.

Originally it was proposed that registrar backers be indicated by using a transferable identifier derivation code but have an inception event with a null next field. This would make the registrar identifier effectively non-transferable but provide an inception event that could anchor meta-data. However, this would break a lot of witness-related code, which expects that the witness identifiers are explicit, not merely effectively non-transferable.

This revised proposal uses explicit non-transferable identifiers for backers but adds a new config trait to indicate that the backers are registrars and adds a new seal type to indicate the anchor for the metadata.

Config Trait

RB for registrar backers or ledger registry backed instead of witness pool backed.

Registrar Seal

{
  "bi": "BACDEFG8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
  "d" : "EaAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8J"
}

The bi field in the seal is the non-transferable identifier of the registrar backer (backer identifier). The first seal appearing in the a field list in the containing event with that registrar backer identifier is the authoritative one for that registrar (in the event that there are multiple registrar seals for the same bi value).

The seal must appear in the same establishment event that designates the registrar backer identifier as a backer identifer in the event's backer's list. Attached to the designating establishment event is a bare, bar, message that includes the registrar's metadata. Metadata could include, the address used to source events onto the ledger and a service endpoint for the leger registrar and a corresponding ledger oracle.

The d in the seal MUST BE the SAID of the associated metadata SAD. The SAD may appear as the value of the sd seal data field in a bare, bar message..

Bare Message

The bare, bar, message provides either a solicited or unsolicited disclosure of anchored data. It includes a reference to the establishment event, and its route indicates that it contains registrar metadata.

{ 
  "v": "KERI10JSON00011c_",
  "t": "bar",
  "d": "EFGKDDA8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
  "r": "process/registrar/bitcoin",
  "a":
  {
    "d" : "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
    "i" : "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
    "s" : "5",
    "bi", "BACDEFG8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "sd":  
    {
       "d": "EaAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8J",
       "stuff": "meta data field"
     }  
  }
}

The r field is the route. It is the equivalent of the resource path in a ReST interface but because KERI must support peer-to-peer asynchronous protocols (i.e. can't depend on http or ReST) the messages explicitly include a route that indicates resource being returned when unsolicited or the return route when solicited.

in the a block:

d, i, and s indicate the event holdeing the backer seal. said of event, identifier prefix of the event, sequence number of event. bi is from the backer identifier from the backer seal.

sd is the seal data SAD field block. The nested d said of this block MUST be the d field in the associated seal.

As an option, a registrar's metadata could be updated by anchoring a new metadata seal and promulgating a new bare, bar, message whose route indicates that it is updating leger registrar metadata. This allows registrar metadata to be updated in an interaction event.

A more secure approach to updating registrar metadata is to rotate the registrar's identifier in an establishment event and then provide the new metadata as the metadata for the new registrar identifier.

Prod Message

The prod, pro, message provides a solicitation, i.e. a disclosure request, for disclosure via a bare, 'bar` response.

{ 
  "v": "KERI10JSON00011c_",
  "t": "pro",
  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
  "r": "registrar/bitcoin",
  "rr": "process/registrar/bitcoin",
  "q":
  {
    "d" : "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
    "i" : "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
    "s" : "5",
    "bi", "BACDEFG8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "sd": "EaAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8J"
  }
}

The r field is the route. It is the equivalent of the resource path in a ReST interface but because KERI must support peer-to-peer asynchronous protocols (i.e. can't depend on http or ReST) the messages explicitly include a route to the resource being requested.

The rr field is the return route. Because KERI must support peer-to-peer asynchronous protocols (i.e. can't depend on http or ReST) the messages explicitly includes a return route so that the resource being requested is returned to the correct processor on the receiving end.

The request message, in this case the pro, prod, includes both route, r and return route, rr fields. The route is the path to the resource on the server host and the return route tells the server host how to return it. The r field in the corresponding bare, bar message is assigned the value of the rr field in the triggering pro, prod message.

An unsolicited bare, bar message uses a well known value for the resource as determined by agreement or the type of data being sent unsolicited. That is resource dependent.

in the q block:

d, i, and s indicate the event holdeing the backer seal. said of event, identifier prefix of the event, sequence number of event. bi is from the backer identifier from the back seal.

sd field is the said d from the backer seal i.e. seal data said

[rodolfomiranda]

Please, confirm if I understand it correctly:

• the b label will contain the backer identifier. (can it have other identifiers as well?)
• the c label will contain "RB" as a config trait
• the a label will contain a Registrar Seal composed by: -- bi label with the backer identifier -- d label with the SAID of the metadata SAD (bare message)

Questions:

1. what is the bare message type? bar or bre?
2. you said that attached to the designating establishment event there's a bare message. What it means that a message is attached? what are the mechanism to attach a message?
3. based on this, what's the correct order of the seal labels on a Registrar Seal? bi-d; or d-bi
4. is there a definition and how to use the r, rr and ri labels?

[SmithSamuelM]

@rodolfomiranda

I assume you mean the the field labels in an establishment event.

the b label will contain the backer identifier. (can it have other identifiers as well?) In this case no it only has the backer in its list the value of the b field value is a list so its value will be [bi]

the c label will contain "RB" as a config trait yes

the a label will contain a Registrar Seal composed by:

The a field value is a list so one of is entries will b a backer seal

I assume this is refering to a backer seal

-- bi label with the backer identifier -- d label with the SAID of the metadata SAD (bare message)

I fixed the definition above. I realized that the using the SAID of the Bare message was less privacy preserving than just using the SAID of a SAD of the metadata only. So the value of the d field in the label is the SAID of the metadata SAD however that is defined. This metadata SAD is the value of the sd field in the a section of the bare, bar message not the SAID of the whole bar message.

The reason we use anchoring seals and do not put the actual data in the KEL is to better protect the privacy of the associated data that is being anchored by the seal. This way the anchorer can decide how to disclose and under what conditions the associated data. The bare and prod messages provide one such mechanism but those could be encrypted and only sent to approved parties of the registrar backer is to operate in a private mode.

Questions:

what is the bare message type? bar or bre? bar fixed the inconsistent references above

you said that attached to the designating establishment event there's a bare message. What it means that a message is attached? what are the mechanism to attach a message?

Because KERI is meant to support any kind of transport protocol and specifically to support streaming on bare metal TCP or eventually UDP, any KERI message type can be interleaved in a stream. So for example, if an event message has the backer seal in it, then in the stream following the event message and any attachments like signatures the following message could be the bare, bar message. Its attached to the stream. Alternatively, when using http, one could tunnel a stream fragment in the body of the http message. The stream fragment could include both the event message with attachments and also the bare, bar message. Alternatively one could have a rest API for the sender of the event message wherein the recipient of and event message with a backer seal could see the seal and then use that as trigger to then request using the prod, pro message the corresponding bare, 'bar` message from the sender. All of the above are possible with KERI.

based on this, what's the correct order of the seal labels on a Registrar Seal? bi-d; or d-bi

bi, d

is there a definition and how to use the r, rr, and ri labels?

The ri field in the example has nothing to do with a registrar backer. It was just copied from a different example sorry. The example has been fixed.

The r and rr fields now have definitions above

[SmithSamuelM]

@rodolfomiranda Just to trigger a notice to reread my answers. I substantially updated them since my first response.

[iFergal]

This is an old issue but since it's still open I will ask here @SmithSamuelM @rodolfomiranda. :)

In this design, a ledger registrar is designated by its non-transferable AID that also acts as the entry point to the chain (which works for the current cardano-backer since Cardano uses Ed25519 keys).

But what happens if a ledger registrar loses access to its keys, so transactions can no longer be pushed on-chain - are all identifiers tied to it not stuck now since a verifier will be looking for ledger transactions from the specific address/AID from the b array of 1?

Since we are relying on the consensus algorithm of a ledger itself, rather than witnesses and KA2CE based on b and bt in the icp/rot event - would it instead be possible to:

• specify the ledger ~as a config trait~ in the metadata the registrar seal is of - e.g. CARDANO_MAINNET (from a known list), with b = [],
• push the KEL directly on-chain (no witness, since this isn't KA2CE - but I guess have a validity check),
• have verifiers or watchers (“global watcher”) read all of the chain, and build up an index of the global AID space?
  • this could be narrowed to specific address or pool of addresses too for performance gains based on a specific domain but now the identifiers aren't strongly bound to the entry ledger address.
  • watchers can provide watcher receipts - so verifiers can check with watchers that index the chain.

But maybe I'm missing a specific reason for needing an entry point/backer AID to be marked in the event.

Non-enterprise advantage: In an enterprise setting, having a central ledger registrar that can push events on-chain works. But for an average end user managing their personal identifiers, who may not be able to run their own ledger registrar instance - they would need to find some paid service for this. Since ledger transactions aren't free.

A more decentralised approach is possible if there exists identity wallets that can also operate under the hood as also a crypto wallet for that ledger (optionally). This is something we’re interested in exploring in the wallet I work on. If an end user has a funded wallet, they can serialise a transaction with their event themselves and push it to a node in the network, rather than a ledger registrar API. Then a global watcher or verifier can pick it up from the chain.

[SmithSamuelM]

To change the registrar as backer identifier, do a rotation event with new registrar identifier. Any other information associated with that registrar provide in the attached data anchored with the registrar backer seal. A change to the backer identifier is a trigger to look for a new seal in the rotation event.

We want to avoid putting too much public information in an event. We want the events to be private by default. Putting the registrar information other than the identifier in the sealed information accomplishes that. All the non-KERI stuff you suggest would likely be Ledger specific so it does not belong in the KERI specification. The reason for using a non-transferable identifier for the Registrar is to avoid the regress into having to get a KEL for the registrar. The registrar identifier does not have to be Ed25519 based it can be any public key based primitive supported by CESR. So it could be transformation of an Ethereum or Bitcoin address which use ECDSA secp256k1 which is already in the CESR code table.
So if the Registrar has to move to a new bitcoin address it just issues a rotation event and publishes the new Registrar identifier.

[SmithSamuelM]

Alternatively the registrar identifier is not actually a bitcoin address but the identifier of a trusted Oracle for the ledger. The registrate backer sealed data provides any and all details about that.

[SmithSamuelM]

Each type of registrar backer will need to define a protocol specification for that type so that one can evaluate how to validate it.

[SmithSamuelM]

A given AID controller is declaring in a non-repudiable locked to current key state way, a secondary root-of-trust that is a ledger not a witness pool. Statement made by the secondary root-of-trust need to be verifiable non-repudiable. The AID of the registrar is the trusted source for those statements. They can be signed by that identifier because a non-trans identifier is a public key. To rotate the key one must rotate the identifier. So the controller KEL becomes the key management source for secondary roots of trust. (witnesses or ledger registrars). That the ledger comes with a distributed consenus pool that has its own trust properties is ledger specific. KERI is managing the keys.

[iFergal]

To change the registrar as backer identifier, do a rotation event with new registrar identifier. Any other information associated with that registrar provide in the attached data anchored with the registrar backer seal. A change to the backer identifier is a trigger to look for a new seal in the rotation event.

OK, assuming this scenario where the original registrar identifier is completely lost/dead, then the rotation event can only be signed by the new registrar identifier. I guess I was assuming for a rotation event to be valid, it must be signed by the current backer registrar.

The new registrar identifier in this case would also have a new Cardano address. So for discoverability, a verifier needs to know the new address out of band or index all addresses (global watcher - though maybe scoped to a set of AIDs instead of all AIDs).

Statement made by the secondary root-of-trust need to be verifiable non-repudiable. The AID of the registrar is the trusted source for those statements. They can be signed by that identifier because a non-trans identifier is a public key.

I assume at least that as a verifier/watcher, I should read from the chain instead directly from a registrar backer API (like the current cardano-backer) because otherwise there's no proof that it actually went on-chain and used the ledger's consensus algorithm. This is sort of like a single normal witness with KA2CE and a threshold of 1, if we don't check the chain.

If the secondary root of trust is the ledger itself then I feel like the only proof that it went on the ledger is the valid ledger transaction itself. And not just a non-reputiable signature from the ledger registrar's AID because the registrar could just choose to not put it on chain. (or at least that these are combined, like registrar receipt within a transaction)

[SmithSamuelM]

Rotation events on a KEL are signed by the controller of the KEL not the registrar backer. The KEL is the primary root of trust. The registrar is a secondary root of trust and hence is replaceable at any time by an act i.e rotation event on the KEL (primary root of trust). These questions of yours are starting to feel like there is a fundamental misunderstanding of the basics of KERI. I suggest you read the KERI white paper in a little more detail.

[iFergal]

Yes sorry when I said signed by the registrar I meant as a receipt signature - the rotation event itself signed by the controller, of course.

If we can always change it, sounds good. It was actually the "joint confirmed witness rotation" section in the white paper for witnesses that made me think it might apply to ledger registrars - but that is also detailed as an optional step for validators. I'll give those sections a re-read.

[SmithSamuelM]

Yes so once the rotation event is published by the controller, the old registrar is no longer a registrar, so it no longer has any role to play as a registrar and therefore isn’t needed to sign anything, at least as a registrar. So it won’t be receipting anything.

[iFergal]

Thanks, this makes sense!

As a validator or watcher, can you describe what happens if I read transactions from the ledger directly and find the latest KEL but it's not witnessed by the registrar, for whatever reason?

[SmithSamuelM]

A ledger backer is essentially replacing a witness pool with the ledger pool of nodes. How that ledger pool "witnesses" the KEL is ledger specific. Its up to whoever decides to use a ledger instead of a witness pool to define what that means. And anyone who wants to interoperate with an AID that has a ledger backer instead of a witness pool of backers needs to understand how that works in order to decide if they want or can interoperate. So the ledger registrar AID is just a hook to discover the ledger as a secondary root-of-trust. For example, a validator of the ledger as backer could search for transactions on the ledger attributed to the (public key, address) that is derived from the Registrar AID. Those transactions for example could anchor the KEL as a whole or the KEL events invididually. Or something like that. That validator would have to accept that they trust the ledger to anchor that KEL and be able to verify those anchors as legitimate and not accept a KEL or a KEL event unless it was anchored. This is similar to not accepting an event on a KEL unless it has beeen witnessed (receipted) by a threshold number of witnesses. But KERI doen't normatively define what it means to validate a ledger backed KEL. It just provides a mechanism for someone to publish via a KEL that the KEL is ledger backed.

Each ledger backed mechanism needs to create its own specification that says to anyone who wants to interoperate with it what the validation rules are. In the early days of KERI, there seemed to be interest in leveraging existing Ledger infrastructure tooling to provide discovery via the ledger and backing via the ledger. Over time, as ledgers have increasingly come to be seen as platforms (islands) of non-interoperability, the interest in ledger backers has waned. In fact, to my knowledge, RootsID was the only one to implement a ledger backer for KERI. We originally thought GLEIF would want Ledger backers for Ethereum and Sovrin but it become clear that there was zero real interest. Most of those advocating for those ledgers actually didn't want KERI at all.

IMHO the best use of a ledger is not as a secondary root of trust to replace a witness pool but as a tertiary root of trust to provide a permanent anchor of KELs for archival purposes. More like a checkpoint. So a watcher or witness may behind the scenes want to anchor the kels the watch or witness on some ledger (or IPFs) as a reslient permanent archive to back them up. This hides the complexity of the ledger so that its not a barrier to interoperability.

The advantage of using a Ledger Backer for KERI is that a Ledger ecosystem gets a well defined decentralized key management protocol with key prerotation. But only for that Ledger's ecosystem. Interoperability with the broader KERI ecosystem requires that others implment the ledger specific validation rules. Otherwise they don't know how to trust the ledger. KERI makes KAWA the default witness pool algorithm as the lowest common denominator because it is compatible with cloud and internet infrastructure. No more ledger wars. Using secondary ledger backers outside of a given ledger ecosystem reintroduces the "ledger wars" inherent interoperability barriers.

They way we approached for Sovrin was a sovrin keri tunnel. The ledger was merely a discovery mechanism to go find the kel with the real witnesses. Sovrin events then became a tertriary root of trust not a secondary.

So using a registrar backer as a secondary root of trust with KERI is basically saying, If you want the goodness of KERI as a DKMI but you have a strong reason that you want to use KERI within the closed ecosystem of a given ledger. Then you can. KERI lets you do that. But you can't expect that everyone else using KERI that is not part of your closed Ledger based ecosystem to interoperate with you.

On the other hand, if you have a watcher who wants to be highly reputable, then you could back that watcher with a ledger as a tertiary root of trust and advertise that the KELs your watcher watches are backed onto a ledger. Now, someone can then use your watcher without having to understand the complexity of the ledger. If others who do understand the complexity of the ledger periodically verify that your watcher's kels are indeed being backed onto the ledger and they publish that, then you get a reputation for your watcher as a more trustable watcher. Likewise for a KERI Witness, or KERI Jury Pool, or KERI Judge.

A lesson learned from the W3C did specification. In the earliest of days, there was only one ledger backed identity system, Sovrin. But it became clear very quickly that Bitcoin maximalists and Ethereum maximalists, and other Ledger maximalists wanted to have ledger backed Identity systems using their preferred choice of maximalism. So in a now failed attempt at interoperability between ledgers, the W3C did specification was born that provided an interoperable discovery mechanism called a DID:DOC that would supposidly allow a given wallet to validate identity based operations (like verifiable credentials) from multiple different ledger based identity systems. In actuality, I don't know of any wallets in production that ever supported more than two DID methods. For example DID:PEER (non ledger backed) and DID:SOV. Or DID:ETH only. Now there are over 200 DID methods. This is the definition of non-interoperbility due to too much choice. Because one can't validate a DID method without implementing a code library for that method. A universal DID resolver is insecure. One has to go read the ledger to validate. And any non-ledger backed methods are susceptible to the security weaknesses they bring unless they have some replacement for a Ledger level security. KERI does, DID:PEER did. most others do not. The result is less overall interoperability fostered by too many DID methods.

In the early days it was thought that there would be some experimentation with disparate did methods but that only a handful would eventually win. The reality now in hindsight was that was an extremely naive view. The reality is that DID methods are each individually islands of non-interoperability because they do not have interoperable security so you can't trust the identity system unless you fully implement the tooling associated with that method. Which means its never going to be the that anyone supports more than one or two methods, practically speaking.

So to move forward we need to insist on with the security properties we need and then focus all our effort to gain adoption of the protocol that best provides those properties. That is how KERI was designed. As the one protocol that is secure. Security first, always.

[iFergal]

Thanks for such a detailed explanation; makes perfect sense that it's ledger specific. So it sounds like some of these discussions should be an issue in the cardano-backer repository.

But briefly, I've mostly been curious if we skip using the registrar hook and just post non-receipted KELs (with a seal whose metadata simply specifies the ledger and ledger network, the backer config trait and no/empty backer array) directly on chain from the controller, and a watcher can search the entire ledger space of KEL transactions. Maybe it's just complicating things.

---

Regarding non-interoperability with ledger registrars: This makes sense too, and I understand the lock in between ledgers. The main reason we've been thinking about this at the Cardano Foundation is to lower the barrier to entry to adopting KERI in our eco-system for end users managing their personal identifiers who can't run their own witnesses, and don't know what witnesses to trust, etc. And our enterprise use cases to use witness pools.

On the other hand, if you have a watcher who wants to be highly reputable, then you could back that watcher with a ledger as a tertiary root of trust and advertise that the KELs your watcher watches are backed onto a ledger. Now, someone can then use your watcher without having to understand the complexity of the ledger. If others who do understand the complexity of the ledger periodically verify that your watcher's kels are indeed being backed onto the ledger and they publish that, then you get a reputation for your watcher as a more trustable watcher. Likewise for a KERI Witness, or KERI Jury Pool, or KERI Judge.

This idea is super interesting to me. Highly reputable watchers is something I wanted to pursue with this "global watcher" where a validator may query a set of different reputable watchers - but I didn't think of it as an entry point for others who don't know the ledger, makes sense. Even better if there is a judge too.

But fully in agreement with the DID eco-system - I definitely don't want to also create a silo, so a lot to think about.

[rodolfomiranda]

On the other hand, if you have a watcher who wants to be highly reputable, then you could back that watcher with a ledger as a tertiary root of trust and advertise that the KELs your watcher watches are backed onto a ledger. Now, someone can then use your watcher without having to understand the complexity of the ledger. If others who do understand the complexity of the ledger periodically verify that your watcher's kels are indeed being backed onto the ledger and they publish that, then you get a reputation for your watcher as a more trustable watcher. Likewise for a KERI Witness, or KERI Jury Pool, or KERI Judge.

As @iFergal said, that's really interesting. Realizing that blockchain is the tertiary root of trust, then any KEL can be backed in the ledger independently of having a specific witness to do it, that also moves the ledger complexity to the watcher.