0:00 Ned Smith ｜ Secure Asset Transfer Protocol ｜ KERI Conference 2026
0:04 Welcome to the session on
0:07 Secure Asset Transfer Protocol. I'm Ned
0:10 Smith. I happen to be Sam's brother.
0:14 So I've been introducing myself as
0:16 Sam's brother for a long time.
0:20 I'm the younger one. But I have a
0:24 30-year career at Intel and then another
0:26 eight years in industry. All of it
0:29 related to security. So Sam's the
0:32 newcomer in the group to security, just
0:36 so you know. And I've also been a
0:39 prolific inventor. So I have over 500
0:41 granted patents
0:44 and I've been interested in
0:47 doing some work in the IETF. Most
0:51 recently I have been looking at the
0:56 SATP protocol in one of the working
0:59 groups in the IETF. So I'm going to just
1:02 give you a quick overview of what the
1:04 IETF is as a standards organization and
1:06 how the SATP group fits in there. So
1:09 IETF is the acronym for internet engineering task
1:13 force. It's really a standard setting
1:15 body that's recognized internationally.
1:18 It is the body that defined the internet
1:20 protocol. So it is all
1:23 things internet originated in the IETF.
1:27 The organization itself is
1:29 structured around different areas. So
1:32 there's a internet area, a routing area,
1:35 security operations, general
1:37 applications and real time. There's a
1:40 few others that I didn't mention here.
1:42 And within the applications in real time
1:45 area, also called ART,
1:47 there's a working group called Secure
1:49 Asset Transfer. And they're the ones
1:52 that are doing the work to define a
1:54 secure asset transfer protocol.
1:56 And I'm going to talk about that the
1:59 rest of this talk.
2:02 To dive in here, there's a what
2:04 you might think of as the canonical use
2:06 case in SATP to drive the technical
2:10 portions of it. So I'm going
2:12 to walk through this use case. It's
2:14 essentially a token issuance use case.
2:17 And this token
2:21 use case, it's built around this
2:23 something called the asset reference
2:25 token or art not to be confused with the
2:28 working group. But it's a sort
2:32 of a reference token for
2:36 for working through the
2:40 challenges associated with
2:43 building
2:46 systems around tokenized
2:49 assets
2:50 and stable coins. In this
2:53 use case the token issuer in step
2:56 one issues and declares an asset that is
2:59 then given to an artifacts
3:03 registry to make it persist there so
3:06 so that
3:09 the asset is known to exist. In step
3:11 two, the issuer mints a token. And
3:14 we're using the acronym network
3:16 one or NW1 to refer to the
3:22 token issuer side of this exchange.
3:25 And they mint the token and in
3:28 this token, there's sort of the value
3:29 part or part one, which is the part that
3:32 is on the chain. And then there's
3:34 something called context data, or part
3:36 two, which refers to any artifacts that
3:38 are not on-chain or maybe partially
3:40 on-chain but in some way represent some
3:44 stability to the stable coin asset.
3:50 The importance of that linking
3:55 will come in a little bit later
3:58 in the context of the asset network.
4:02 So in this case, they've minted the
4:03 minted the coin and then there's an
4:05 entity that is the interface to the
4:08 asset management network. So we're
4:09 calling this, network one,
4:11 asset network one. And that's
4:13 where you interface to whatever is your
4:16 distributed ledger technology, whether
4:17 it's a public, private, or even a
4:19 monolithic
4:20 Network.
4:23 And then in step four, the gateway reads
4:25 a token from network one, which we're
4:28 calling the SATP gateway one, and that
4:32 then in step five interfaces with the
4:34 artifacts registry to collect the
4:36 additional data that's there
4:39 and it validates that prior to the
4:41 asset transfer. And then in step six,
4:45 this is sort of the jumping off point
4:46 for actually doing the transfer over the
4:49 SATP protocol. And the idea is you're
4:51 transferring an asset from gateway
4:54 one or the token
4:56 issuance domain into another network
4:59 which is receiving that asset.
5:05 What are the SATP entities? There's
5:09 something called the originator
5:11 which is the entity that owns the asset
5:12 and then the beneficiary which is the
5:14 entity that's receiving the asset.
5:17 There's a set of hosts that are in
5:19 the model for how that exchange happens.
5:22 So there's the gateway which are the
5:23 endpoints of the protocol. There's an
5:25 asset network or an oracle that is the
5:28 controller of all the domain assets.
5:30 Anything that's relevant to the context
5:33 in which that gateway operates is
5:37 represented by this notion of
5:40 an asset network; could be one or many
5:43 hosts.
5:44 Then there's the user application or
5:46 orchestrator which is the kind of the
5:48 controller or the entity that's driving
5:51 the you know the asset transfer that's
5:54 coordinating the resources and
5:56 and giving the instructions to the
5:58 gateways to present their
6:02 assets on the protocol.
6:06 There's another entity which I call the
6:09 host owner. It's not in the first
6:13 iterations of the protocol. It's not
6:15 really called out directly, but it's
6:17 implied in the some of the some of
6:21 the message exchanges that appear in
6:24 stage one of the protocol. So I'm
6:25 calling it out as it's a real
6:28 entity and we'll call it the host
6:30 owner for now just to make the slides
6:32 more clear, but it's these
6:34 entities that are responsible for
6:36 administering the infrastructure and
6:39 it represents the entities
6:41 that are responsible for
6:44 that are legally
6:48 responsible for the asset.
6:51 There's also something called an
6:52 artifacts registry. Think of it as a
6:54 directory that maintains asset transfer
6:57 context and makes it u persistent
7:01 for whatever additional
7:08 Your investigation that's needed on
7:10 the asset.
7:11 It's something that provides the audit trail
7:15 for the protocol.
7:23 So here is a view of the architecture
7:25 for SATP.
7:25 One of the main goals of this
7:29 architecture is to essentially implement
7:31 a an atomic two-phase commit protocol
7:34 for the asset exchange. It's
7:37 fundamentally decentralized. In other
7:38 words, there's no assumption that the
7:41 originator and the beneficiary share
7:45 a trusted third party relationship.
7:48 There's a tokenized and
7:50 non-tokenized asset. So, not everything
7:52 is on-chain per se. But it can exist
7:55 and it is relevant to the to the
7:58 exchange of assets.
8:00 It needs to be auditable and
8:04 and the assets need to be durable.
8:07 There's also the notion of a canonical
8:09 identifier, which is to say that the
8:12 representation of the identifiers and
8:14 the information that are known to the
8:16 originator don't have to be the same as
8:18 the representation of identifiers that
8:21 are known to beneficiary B. In other
8:24 words,
8:26 the attributes that are in
8:28 common have to be negotiated or created
8:31 as part of the protocol.
8:33 But it's not requiring that
8:37 the asset identifier has
8:41 to be
8:42 morphed into a namespace that's
8:46 defined by the protocol or the
8:48 artifacts registry.
8:52 There's a need for asset versioning,
8:54 pinning and roll back. That's part of
8:55 the two-phase commit requirement. And
8:59 There's also requirements for
9:00 provenenced asset transfers. In other
9:02 words, you should be able to unwind this
9:06 asset transfer and be able
9:08 to identify all the stages in the
9:11 transfer after the transfer has
9:13 happened.
9:16 And so as you can see in the
9:19 diagram, the protocol is divided into
9:22 four stages. Stage zero, stage one, two
9:25 and three. And
9:30 and you see the artifacts registry kind
9:32 of in the middle. It's not really a
9:33 separate entity. and I'll talk
9:36 more about why that is in a second.
9:43 One thing to note is that
9:44 the authority model from
9:47 the perspective of the architecture in
9:49 the first series of drafts, there is
9:53 an assumption, that's implicit, that it's
9:56 X.509 certificate based and so this is a
10:00 bias that finds its way into the
10:02 specifications and there's
10:05 no normative text that
10:06 says it has to be X.509 but the way that
10:10 the people are thinking, their bias
10:11 towards X.509 thinking, and so that tends
10:15 to be an uphill battle as you
10:17 contemplate integrating your KERI
10:20 concepts into this.
10:24 And so part of the initial investigation
10:26 that I did into this environment, was to
10:28 look at what would it take to
10:31 integrate vLEI authorization into a SATP
10:34 architecture.
10:36 I sketched out how you
10:40 might do that. We have the
10:42 the standard GLEIF and QVI and
10:46 LOU entities represented and then we
10:48 have the within the domain the SAT
10:52 domain you have something I'm
10:54 calling the SAT domain which is
10:57 whatever is the appropriate way to
10:59 identify that organization. So here
11:02 I've just coined the term
11:04 originator.example.org
11:06 or beneficiary.example.org
11:08 to capture that idea.
11:11 The point is it becomes an LEI
11:13 holder
11:14 and then there's the OOR
11:17 and the ECR entities; those are also
11:20 represented.
11:25 These entities aren't defined in
11:28 the architecture or in any of the
11:30 specifications but there is
11:33 somebody,
11:34 the CEO for example, that can that
11:37 has the legal responsibility for
11:41 the asset and there is something that is
11:44 responsible for you know provisioning or
11:47 issuing credentials to the hosts.
11:53 And then on the asset
11:57 side we basically have some
11:59 requirements, maybe
12:01 the legal requirements for the asset,
12:03 but the asset authority is
12:06 someone that you know has legal title or
12:08 ownership of the asset. They have the
12:10 right to disposition the asset or to
12:12 transfer it. It needs to be a
12:14 non-repudiable authorization.
12:18 And there's this notion of express
12:20 delegation and recorded disposition as
12:24 well as effective date and some other
12:25 legal requirements that have to be
12:28 met in order for this protocol to work
12:31 but it's not defined yet in the
12:35 set of specifications of how to do
12:37 that.
12:42 One other note is, from the
12:46 perspective of LEI, that actually the
12:47 hosts are not legal entities.
12:51 They're devices and there
12:54 and in LEI there
12:57 isn't the notion of a credential that's
13:00 appropriate for a device. But
13:04 it could be anything: It could be a
13:05 certificate, there could be a DID
13:08 but you could also have a KERI KEL as
13:10 the credential, but it's not specified
13:13 in the specification that says that it
13:17 can't be anything any of these,
13:20 But like I said before, there is an
13:22 assumption that it's probably a
13:24 certificate.
13:27 [To next slide, red.]
13:32 In 2023 this working group
13:35 was formed and the working
13:40 group sat down and said "okay,
13:42 what do we want to work on, what charter
13:44 should we bring to the working group" and
13:47 of course one suggestion was
13:49 let's start with stage zero; that's the
13:51 first part of the protocol. But it
13:54 became clear that people were not really
13:57 clear about what should be in stage zero
13:59 and so they said let's start where we're
14:02 least confused which was stage one. So,
14:05 the first set of protocols begin with
14:07 stage one. And I'm going to just briefly
14:10 walk through stage one, two, and three.
14:12 If you have questions, chime in.
14:15 But it's the
14:18 easy part basically. The important
14:22 aspect of stage one is there's
14:24 a there's sort of a handshake that says,
14:26 "Hey, I want to do a transfer." So you
14:28 propose your transfer and then the
14:30 the recipient then acknowledges the
14:34 request and then you begin the
14:37 transfer. Part of that proposal is to
14:41 provide all of the contextual
14:43 information necessary in order to
14:45 perform the asset exchange. And so what
14:49 you see here is a
14:53 snapshot of the transfer protocol
14:56 message and then kind of the body of
14:59 it, which is the transfer claim which is
15:01 where all the ugly data shows up that
15:03 provides the context for the being able
15:06 to transfer the asset.
15:09 The interesting thing though is the
15:12 transfer context identifier is supposed
15:13 to be negotiated in stage zero but we
15:16 haven't defined it yet. So it's just a
15:18 placeholder,
15:20 a string. 'tstr' means string.
15:24 Then there's these other things that are
15:27 showing up which refer to domain
15:28 bindings. So there's the verified
15:31 originator entity ID and the verified
15:33 beneficiary entity ID. These are strings
15:36 again undefined as to what is in the
15:39 string.
15:42 Then there's a bunch of information
15:45 about the context of the various
15:48 devices. And so there's the originator's
15:50 public key which presumably is there
15:53 to be able to verify the identity of
15:56 the originator. So you got the identity
15:58 the originator's identity plus the
16:00 originator's public key which can be
16:01 used to authenticate the identity.
16:04 And then there's some of the other
16:05 entities here. So there's the gateway.
16:08 There's the network.
16:13 There's also identities and
16:16 and credentials for both the gateway,
16:18 the network and the identity. And then
16:20 down at the bottom there's this notion
16:22 of the owner
16:24 Which is not
16:26 well defined but it asserts that
16:28 there is some entity within the
16:30 gateway that is the legal owner of the
16:32 asset.
16:39 in one of the recent
16:41 meetings there was observed
16:44 "Hey, there's in this transfer init claim
16:46 claim, there's all of this information
16:48 but as we contemplate looking at stage 0
16:50 it seems like a lot of that
16:52 information already exists somewhere in
16:54 stage 0; do we need it all here"
16:58 and that's kind of setting the stage
17:00 for the next slide but basically
17:05 My interest in this started with
17:07 a draft that I did called
17:11 SATP vLEI binding and it's
17:17 essentially populating some of these
17:18 values with the assumption that
17:20 if I had an infrastructure that
17:23 looked like KERI underneath
17:25 how would I integrate that and
17:30 that was the genesis of that draft.
17:36 One of the other outcomes of doing the
17:39 draft was to define media types for the
17:43 various payloads that are CESR
17:45 specific. So it proposes
17:49 Additions to the IANA registry for
17:52 CESR payloads.
17:57 So moving on we have the stage 2 protocol
18:00 which is essentially locking. So before
18:03 we can actually
18:04 transfer the asset, we
18:07 need to lock the asset. So very simple
18:09 kind of request-response locking. It's a
18:12 it's a not fine-grained locking,
18:14 it's a global lock around everything.
18:17 And then we have a two-phase commit
18:19 protocol which includes in this the
18:23 notion of minting a new
18:26 asset in the beneficiary domain
18:30 and burning or destroying the asset in
18:33 the sender domain.
18:37 There isn't this notion
18:39 of "Hey, I transferred the asset." It's
18:43 just bookkeeping in some sense.
18:45 Right?
18:55 All right. So now the working group is
18:57 almost done with the specification
18:59 for the architecture and for the
19:02 protocols from stage zero to stage
19:04 three. They're in review by the working
19:09 group and the area. And the way that
19:13 the process works is when the working
19:15 group believes they're done with
19:16 something, they issue a last
19:20 call on the specs which basically says,
19:23 that the period for
19:26 providing feedback is ending. Please,
19:28 give us your
19:32 feedback because we're going to
19:33 move it to the next phase which is to
19:36 deliver it to the area directors and
19:39 then on to what's called
19:43 the internet engineering
19:46 group. So, IESG is their
19:50 acronym. So what it means is
19:53 If all of those reviews are
19:55 successful, then it will progress to RFC
19:58 status.
19:59 Okay?
20:02 Since they're kind of done with
20:06 The stages 1 through 3, they're
20:09 now rechartering to look at stage 0.
20:14 And then in the context of that,
20:16 what are the objectives or
20:18 requirements for a stage 0 portion
20:21 of the protocol. So one of
20:23 the important aspects is that this
20:25 notion of a transfer context identifier
20:28 needs to be defined. What does it really
20:30 mean? What are the properties of an
20:32 identifier for the transfer context?
20:35 How do we represent asset
20:37 identification?
20:39 How do we represent asset ownership
20:42 and validation?
20:43 How do we represent the authorization
20:46 to transfer?
20:47 There's also the exchange of travel rule
20:50 requirements in financial
20:54 contexts where it's
20:56 basically saying "How do we know
20:58 what information has to be included
21:01 in the transfer in order for the
21:04 appropriate context to be represented
21:06 equally on both sides."
21:09 How do you represent gateway ownership
21:11 and validate that? How do you
21:13 negotiate the transfer? There's also
21:17 information about the asset itself.
21:20 How do you classify it? And
21:22 then there's something called mutual
21:24 attestation which is a
21:29 future requirement but it's essentially
21:31 saying "We want to be able to get
21:34 information about the environments in
21:36 which the hosts operate to better
21:40 minimize or mitigate
21:43 risks associated with potential
21:45 attackers.
21:50 So here's the stage zero protocol.
21:52 I'm not going to go through this in
21:55 huge detail but I want to draw your
21:57 attention to step one which is a request
22:01 to transfer a context and there's a
22:04 tokenized artifact record which
22:07 correlates to the part one of the token
22:10 that gets issued. So there's some
22:11 information in the token that is used to
22:14 to generate an identifier which we'll
22:17 call the transfer context ID.
22:20 And then there's a binding of the
22:24 transfer context ID to other assets.
22:27 within the context of the domain,
22:29 there could be a variety of digitized
22:31 artifacts that are off-chain or domain
22:34 specific, that are tied to the
22:38 token in some way; but not in the token.
22:42 So there's a binding step and then
22:44 there's a propagation step in step
22:47 four which is to say now that I have
22:49 this context for transferring an asset I
22:52 need to notify the beneficiary and
22:57 say "Hey, we're going to
22:58 progress with this
23:01 asset transfer.
23:04 That happens in step four and
23:05 five. Step six is basically giving
23:09 the beneficiary the opportunity to bind
23:12 some of its assets to this exchange as
23:14 well. So we have the DR2 from the
23:18 beneficiaries side that's binding assets
23:22 and then it returns with its
23:24 propagate in the other direction to say
23:26 in the context of the current transfer
23:29 transfer context that we're exchanging
23:32 here are my attributes that I'm adding
23:34 and what happens then in step
23:37 eight is we now have
23:40 the senders set of
23:46 assets, the beneficiary set of assets
23:50 and context and then we update the
23:53 registry with the transfer
23:57 context. So this is saying now that
23:59 we've established the context we're
24:00 going to make it persist in the registry.
24:10 And that happens in step eight B.
24:12 One thing to note is that
24:14 the registry doesn't have to be a
24:19 single registry. It doesn't have to be
24:21 in essence a trusted third party. It
24:24 could be separate registries.
24:29 Network one could have
24:32 its own choice of registries and network
24:34 2 could have a different choice of
24:36 registries. They would have the same
24:38 information in them because of the
24:40 protocol, we've negotiated that, but
24:43 they don't have to be the same registry.
24:46 That's the point I want to make here.
24:52 And then and then we go through the rest
24:54 of the stages one through three
24:56 transfer the asset. Then in
25:01 stage zero there's a step nine which is
25:03 sort of after the asset is exchanged
25:05 there's a finalise message to the
25:08 registry that basically says yes the
25:10 whole thing happened correctly and
25:14 we're done with the transfer.
25:19 My observation here is that the stage 0
25:22 is a lot like an inception event
25:24 for an asset transfer.
25:28 And so I think some of the creative
25:29 thinking around this is to take a look
25:31 at the registry architecture in KERI
25:35 and say what can we leverage
25:38 from that architecture to
25:41 influence the direction of this
25:45 SATP protocol, in terms of the registry
25:47 design.
25:52 And then of course just by the way since
25:56 the registry contains
25:57 all of this state and context can we
25:59 simplify you know stage 0 protocol:
26:03 you take some of the information
26:04 out of there; it seems bloated otherwise.
26:10 What are the desirable
26:12 properties of an artifacts registry?
26:15 This is not a complete list. This is
26:19 sort of current thinking and so there's
26:21 an opportunity now to influence where
26:23 this goes. If there are other
26:26 desirable properties we can
26:30 entertain adding them to the list or
26:32 working to have them added to the list.
26:34 But the general sense it's append
26:37 only. This seems to align with
26:41 the assumptions that we make for
26:46 You know KERI logs and
26:48 transaction logs availability which is
26:51 to say "Hey, I can have replicated
26:53 registries."
26:55 The spec is not
26:58 trying to limit
27:00 the structures in any way to
27:03 prevent replication or redundancy
27:07 auditability, canonical
27:09 preservation (we talked about that),
27:11 durability,
27:12 which is database
27:15 concept. As well as
27:18 discoverability, domain isolation,
27:20 extensibility, privacy, provenance
27:23 and verifiability. So these are all
27:26 the illities there may be
27:28 some others. They're open
27:31 to suggestions for what other
27:33 properties you think you need.
27:39 Let's talk a little bit
27:41 about future of SATP. I mentioned
27:43 earlier that they are anticipating
27:45 integrating of a tested hardware and
27:47 and context. A little bit to
27:51 observe the motivation for how that for
27:54 why that's important to them. If you
27:57 think about it, in an asset transfer, if
27:59 there's a failure
28:02 Early in the transfer, the cost of
28:04 recovery is much lower than if it
28:06 happens late in the transfer. You get
28:09 this sort of exponentially
28:12 increasing cost curve as you progress
28:15 through that protocol.
28:17 One way to help to prevent
28:22 failure is, at least from the
28:25 perspective of attacks, is to
28:28 introduce trusted platform hardware.
28:31 This idea of a trusted platform
28:33 blueprint which has at its core a
28:37 trusted platform hardware component.
28:39 Think of the blueprint as
28:42 identifying a set of
28:45 hardware, firmware, software,
28:47 system software components that all
28:51 work together and can attest to their
28:57 nature
29:00 Using industry-standard
29:02 attestation protocols.
29:04 The blueprint says "Hey, I've got
29:06 this trusted environment and I can prove
29:08 to you that it's a trusted environment."
29:12 Some of the properties of this are:
29:14 I have a hardware isolated execution
29:16 environment. My gateway runs within
29:20 this environment that is
29:23 walled off or sealed off hardened
29:25 against a variety of different attacks.
29:27 That's a preventative approach.
29:31 The hardware that's built on top of
29:35 isolated containers or what's called
29:36 confidential container technology,
29:40 that a lot of the vendors are
29:43 providing. So it turns out that all of
29:45 the major silicon vendors are
29:48 are supplying to the market their
29:51 acronym soup of confidential
29:53 container technology. Question
30:01 how much do I got left? Well, but
30:02 t– Then you have there's a window of time
30:03 for people to transition out.
30:05 Okay.
30:05 – Sorry.
30:06 All right.
30:07 So I got I'm almost done. So we got
30:09 about 10 minutes it looks like.
30:12 The important point here is: the industry
30:15 is building hardware supported
30:18 isolated execution and the IETF
30:21 expects for things like SATP gateways to
30:24 run in those kinds of environments.
30:28 So further down, there's
30:30 something called attestable hardware
30:31 Root of Trust and something called Dice.
30:34 This dice is technology that I've worked
30:36 on personally. I'm one of the primary
30:38 authors of the dice specifications
30:42 in the industry and all of the major
30:45 industry players have adopted dice. So
30:48 Nvidia, ARM, AMD, Intel and then
30:50 standards organizations like the TCG and
30:52 OCP have all built around the
30:56 notion of a dice hardware root of
30:58 trust. It isn't
31:01 that you have a
31:04 variety of different technologies based
31:05 on different vendors. They're all
31:07 working to have a common open hardware
31:11 representation for a hardware root of trust.
31:17 So what is attestation? This is maybe the
31:21 most abbreviated
31:23 explanation of attestation that
31:26 I've done. But in a nutshell,
31:29 the way attestation works is to
31:31 improve risk management. You think of
31:35 it from this perspective of
31:37 flow of information. You have like the
31:39 SATP gateway which is the attestor.
31:41 It's providing evidence to an
31:42 attestation verifier who produces a
31:45 result which is an assessment of how
31:47 trustworthy the platform is and then the
31:51 SATP gateway, which is the
31:54 the beneficiary
31:56 which is referred
31:58 to as the relying party in this
32:01 architecture, writes their information to
32:04 the attribute registry. In addition
32:07 to all the other stuff that we went
32:08 through in the protocol, in the registry
32:10 there's also device attestation
32:12 information that then could be used,
32:16 a long with the other information in
32:18 the transfer context used by an actuary,
32:21 to make an assessment of what the risk
32:23 is that's associated with this asset
32:25 transfer. And if you think about
32:28 how value that could be is
32:30 whenever there's an asset,
32:32 whenever you're transferring assets,
32:34 there's risk of something going wrong
32:36 and who's responsible for
32:39 for compensating
32:42 something that goes wrong. So, chances are in
32:45 large amounts, high value
32:48 asset transfers, there's going to be an
32:49 actuary there that's providing some sort
32:52 of compensating transaction to offset
32:54 the risk.
33:02 Last slide: What are the opportunities
33:05 for SATP that are sort of essentially
33:07 KERI aware? I think there's three of
33:09 them. One is what does it mean to have a
33:12 KERI-enabled trusted platform? So you
33:14 might say "Hey, one of those layers
33:16 should be like the KERIpy library."
33:19 And we might take a look at the KERI
33:21 controller and say "Shouldn't
33:23 the hardware Root of Trust
33:26 and the layers
33:28 that are at the fundamental
33:29 bottom end of this stack be KERI
33:33 capable, such that when a verifier is
33:36 verifying not only
33:39 the KERI-related
33:43 information but also the device
33:47 certificates, and so forth, that
33:49 are behind the attestion and
33:52 verify the infrastructure associated
33:57 with those credentials are also
34:01 KERI enabled
34:05 That's one thing. Another is
34:07 enabling the artifacts registry with
34:09 ACDC technology. If you
34:14 were attending Sam's talk
34:17 earlier this week on the
34:20 registry architecture, you noticed
34:22 that there was the
34:25 notion of a
34:29 set of
34:32 the witness-watcher
34:36 pattern associated there. Which
34:39 is to say: I could have a registry
34:41 a bifurcated
34:45 registry where one registry is
34:48 acting on the behalf of the
34:51 gateway way 1 and then another one is
34:53 acting on behalf of gateway 2.
35:02 and then the third one is the LEI
35:03 enabled asset transfer. This
35:04 builds on work that I've already started
35:06 in that sense where you know
35:08 essentially what's what we need to
35:10 do here is define how to provision
35:14 the other SATP hosts, like the
35:19 gateway and the network and so forth,
35:21 with KERI credentials
35:25 We can have an
35:27 entire hierarchy that's built around the
35:29 the KERI credential and the vLEI
35:33 ecosystem.
35:36 So that's it. Any questions?
35:40 – Do you think let's say hypothetically ..,
35:45 I'm being brought in with a group of
35:48 advisors to advise on a cap 'n trade
35:51 program where they're looking to have
35:54 the emissions allowances in a digital
35:58 form. There are some groups advocating
36:01 for a tokenized blockchain based
36:03 approach. There's me arguing for ACDCs and GLEIF
36:07 This country is interested in
36:10 having a liquid market because
36:11 allowances could be traded.
36:13 If you can reduce your emissions
36:15 more, you can sell your allocations
36:17 to others who cannot. So, they need to
36:19 buy in the market. Could this potentially
36:22 help facilitate a market for
36:26 trading and represent allowances?
36:29 Yeah, the major motivation was the
36:31 observation that hey, there's a bunch
36:35 of blockchains out there, they're
36:36 all proprietary in a sense that they
36:40 have different consensus algorithms and
36:43 different formats and whatever. But
36:44 people want it to move their
36:47 coin or their tokens from one to one
36:49 network to the other and there's no
36:52 industry standard way to do that.
36:54 So SATP was designed with that
36:57 motivation at heart. If a cap 'n trade
37:01 is trying to essentially move one
37:04 kind of asset from one kind of
37:06 blockchain to another kind of blockchain
37:08 and maybe backwards the other way, then
37:12 that's just an asset exchange,
37:16 which is just an extension of
37:18 the asset transfer. You just do another
37:22 asset transfer in the other direction
37:23 and then it's an exchange.
37:26 So I think it would work. It's
37:29 there's no design I don't see any
37:32 design goals that would prevent it from
37:35 working but that particular use case
37:38 might not be in the forefront of the
37:40 minds of the designers.
37:43 – Yeah, it's probably not.
37:44 Yeah.
37:46 – I have a question.
37:47 Yeah. – The bias toward X.519, is there
37:50 any sense in the community that
37:53 that the risk of the security
37:57 vulnerabilities of X.509 are materially
38:01 problematic?
38:05 The question is given the bias
38:07 towards X.509 is there any sense of the
38:11 problematic aspects of using X.509 in the
38:14 forefront of the minds of the various
38:16 other designers? And the answer is no. I
38:18 don't think they thought about it.
38:21 Okay.
38:23 So that's a conversation that
38:25 will come up in the context of stage
38:27 0 discussion.
38:29 It's a great timing for this
38:32 group to engage with that effort. That's
38:34 what it boils down to.
38:37 – We're having conversations with
38:39 the certificate authority about
38:41 integrating vLEI into group certificates.
38:46 Would that make this implementation
38:49 easier if the actual certificate was
38:52 there was being added if you still
38:54 needed to be integrated down to the gate?
38:56 It would make it easier if
38:59 somehow the working group decided that
39:03 they didn't need to do the extra work to
39:05 allow extensibility where extensibility is
39:09 needed on the credential type because
39:11 right now there's some
39:16 high-level wording and then some precise
39:19 examples based on [inaudible]
39:24 something in the middle that says "Hey,
39:28 this credential structure is
39:29 extensible and here's how you extend it
39:31 and here's how you say that it's a
39:33 different type of credential and here's
39:35 the type.."
39:36 And that's something that I'm trying to
39:38 get in there but they said "No, you're not
39:41 going to do it in stage 1; it's already
39:43 working group last call.
39:46 Right? But like I said
39:49 stage 0 might say "Well, we're
39:51 going to put all that information into
39:53 the registry and all you really need
39:55 is.. [abrupt end]