Replies: 8 comments 42 replies
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
At its heart, the IP is little more than a message format that includes source and destination addresses, and sufficient information to allow another entity to actively do the routing necessary to get the message where it needs to go. IP defines the packet. The routing protocols above the IP layer define how the routing gets done. IP is passive, and all active participants are above or below it. The latter slides in Sam's proposal that show the contents of messages helps to understand why he is so "excited" about the IP analogy. Separating the packet format from the actions on that format is the right approach because any actor that can understand the packet format can operate on it. In that sense, all we need to specify is the packet format. Like Sam did, we ask: What is the minimum information required to verify the message sender and contents? (Answering the questions has the message been modified and is the sender who they claim to be?). It's a great start. And we're off to the races... Also, we should concentrate on what is required to establish the various levels of trust. Addressing and routing can be delegated to TCP and IP because as Sam pointed out, we can trust the message and the sender, we don't need to trust the routing. |
Beta Was this translation helpful? Give feedback.
-
|
We haven't defined "routing" carefully. Because we haven't, "we don't need to trust the routing" sounds right. It IS right, under one definition of routing. But I intend to suggest that trust requires two different routing constructs, and one of them cannot be analyzed this way. It actually must be trusted to achieve certain goals. Whether these goals are part of what we define as "trust" is an important point of discussion. I will say more when I present. |
Beta Was this translation helpful? Give feedback.
-
|
Please note, @sawhitmire , that you said that IP packets contain enough information to do routing elsewhere. Very true. This is the heart of one of my concerns: I don't think Sam's proposal contains enough information to do routing elsewhere. An identifier is not enough to do routing, under the definition of routing that I want to argue for. |
Beta Was this translation helpful? Give feedback.
-
|
Then @dhh1128 we need to clarify what you mean by the second kind of routing. I suspect I think of it as something different. I think routing and discovery should be limited to the transport and IP layers. We need something analogous in the TSP, but it won't look anything like routing as we know it today. It might, for example, be how VIDs are linked to their level 1 utilities (I suppose we could call that routing, but it's a stretch). |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that's what my presentation will do. |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 Looking forward to your presentation. They are always thoughful and insightful.
We want to broaden the support for the TSP. My contention (in accordance with the hourglass principle) is that if the TSP is thin enough then all of IP and the main protocol layers above IP will be in the support. This means that we want UDP to be in the support not merely TCP and especially not merely HTTP. UDP is more performant and scalable than TCP. So there are use cases for Applications that sit above the TSP that would benefit from the performance advantage and we don't want to preclude them because we made the TCP to thick to allow UDP as a supporting layer. That does not mean we shouldn't design new routing protocols that leverage the TSP and there are supported by the TSP themselves. Trustable routing has a place and could be an area of active innovation just like it was for IP when IP first came out. But since IP routing already exists, end verifiability of the secure attribution of the source of a message allows us to use IP routing as is as a start. We don't have to wait. We get instant leverage of IP infrastructure. Thickening the TSP to require new routing agorithms as a prerequisite slows adoption and weakens the support of the TSP as a result. This is antitheticalj.. |
Beta Was this translation helpful? Give feedback.
-
|
Commenting on the fascinating discussion in the EU meeting about the features of the TSL. For as long as we've had the ToIP stack diagram, I've communicated that the key benefits that a Trust Spanning Layer (or DIDComm prior to that) has to offer to the trust applications above are
In my mind, there are two main components that solve these:
If this is correct, then a Trust spanning protocol should probably then have an identifier layer and a connection layer. |
Beta Was this translation helpful? Give feedback.
-
How about TSLP, Trust Spanning Layer Protocol? |
Beta Was this translation helpful? Give feedback.
-
|
@Oskar-van-Deventer I like it! The only other option I've heard is "TTSP" for "ToIP Trust Spanning Protocol", but I like TSLP better. I can see it being pronounced, "T-Slip". |
Beta Was this translation helpful? Give feedback.
-
|
How about TP for Trust Protocol ;) or was that Toilet Paper |
Beta Was this translation helpful? Give feedback.
-
Yeah, "TP" is often used as a verb, like "my house was TP-ed". More seriously, also in the context of the Discussion #16 on Telcos, the abbreviation "TSP" is used as "Telecommunication Service Provider", where some of those services could be related to the function of Intermediary Systems and Supporting Systems. So more reason to for a four-letter acronym. |
Beta Was this translation helpful? Give feedback.
-
|
I like Daniel Hardman's FAI ("Fundamental Authentic Intentions") acronym, and the associate pun "FAIthful" that hints to "http/RESTfull" |
Beta Was this translation helpful? Give feedback.
-
|
Whereas I admire the technical ingenuity of SCID and AID, I don't understand what sort of assurances they are assumed to provide. My bank requires me to re-authenticate an https-banking session after a few minutes of inactivity, as well as to confirm an internet-banking transaction. How would this be any different if SCID+AID were used? |
Beta Was this translation helpful? Give feedback.
-
|
@Oskar-van-Deventer I am not an expert at Sam's level on SCIDs and AIDs, but I do consider them to be (so far) the most secure form of decentralized identifier (and thus the most secure form of verifiable identifier, per the ToIP identifier taxonomy). As such, my understanding is that if the ToIP identifier used with the TSP was an AID, every TSP message would be signed by the current AID private key. That would mean that — under Sam's proposal — at the TSP layer your bank would be assured of authenticity of each message with regards to the AID used for that message. What the TSP layer by itself would NOT provide any assurance of is:
So the open questions in my mind are:
|
Beta Was this translation helpful? Give feedback.
-
Within an https-based session, my bank would be assured of authenticity of each message as well. And my bank requires re-authentication to make sure that not a different person had slipped behind my smartphone or PC. What trust does AID add, that https does not? |
Beta Was this translation helpful? Give feedback.
-
|
I would agree that AIDs alone do not add anything in terms of cryptographic strength to the connection. However, though AIDs may not be a complete solution, I do believe they can contribute significantly to solving the identifier binding problem. Here's why: When you establish an HTTPS connection with your bank, the connection is secured by cryptographic keys negotiated between your browser and the bank's HTTPS server. The only binding of this session to you, the real Oskar, is via the credentials you used to log into your bank account (and possibly other signals your bank is monitoring, such as your IP address). In other words, the actual cryptographic keys you are using in an HTTPS connection do not contribute at all to your "identifier binding". So that means the security of your identifier binding comes down to the strength of your account credentials. We all know what that means for usernames and passwords. If your bank requires multi-factor authentication, that ups the ante — an attacker/impersonator would now have to hack more than one channel. But they can still impersonate you by intercepting or spoofing communications on your behalf rather than needing physical control over your device. But if you are using AIDs stored in a digital wallet on your own device, you have a direct "identifier binding" to the cryptographic keys used to secure the connection with your bank. Those keys live only on your device. So now an attacker/impersonator would have to have physical control of your device. That still doesn't prove it is you, Oskar, the real human being, asking to transfer 100,000€ to some foreign bank account. To do that, we need other solutions such as biometric liveness detection. On that score, I'll go one level deeper into the underlying question about what benefits will ToIP-based decentralized trust infrastructure will provide that X.509/HTTPS trust infrastructure do not. To solve that biometric liveness detection today, your bank has to choose one or more solutions from various different vendors. And you, as a banking customer, have to implement/execute whatever biometric liveness detection method(s) your bank chooses. However, biometric liveness detection is a classic example of a "trust task" that has to be performed by many different applications from many different vendors and service providers. So with a properly layered protocol stack we could actually have a protocol for biometric liveness detection. And if that protocol was designed to be layered over the TSP protocol, the biometric liveness detection protocol would not have to solve any problem related to identifier trust. It could strictly focus on biometric liveness detection. And vendors of biometric liveness detection solutions add support for that protocol, now their solution can work for every relying party who integrates the protocol. Which is both more convenient for you as a consumer, and less work and cost for your bank. Everybody wins. |
Beta Was this translation helpful? Give feedback.
-
|
@talltree Drummond, thank you for this clarification. Is this a fair summary of your point? |
Beta Was this translation helpful? Give feedback.
-
|
I don't know what Drummond will say (I'm curious). But I would like to add my own comment. The first letter in "MITM" is "Man." Here, "man" isn't intended to gendered, and it isn't even necessarily human -- it is any identity that maps to a higher-level construct than an identifier or IP address. The essence of a MITM attack is to get someone to make a false assumption about the connection between the low level addressing construct and the high-level identity (the "man") it is bound to. When Diffie Hellman finishes at the start of a TLS session, both parties know with 100% confidence that they now share knowledge of an encryption key that could not have been learned by simple eavesdropping. But that does not mean that MITM risks have been eliminated, because neither party knows which high-level entity their newly minted session key has been shared with. There is an easy fox for this. HTTP + TLS typically performs higher-level authentication of some kind that binds each end of the cryptographic tunnel to a meaningful identity. Levels of assurance vary, but that's the essence. In typical HTTPS, we do this for the server by sharing a certificate, and we do it for the client by asking for a login. If either of these steps is skipped, then the secure cryptographic channel between the two endpoints could just be a cryptographic channel between one legitimate party and one malicious party -- or even between two malicious parties. AIDs that sign messages produce the same security assurance that a TLS session produces before the authentication step: you know for sure the low-level party (AID) that sent you something, but you don't know what high-level entity that AID represents. But the AID version of the guarantee is a bit better, IMO, because you don't have to renegotiate the session key over and over again like you do in TLS. It is also stronger in another crucial way. In TLS, once you've established the shared session key, either party could leak it to someone else. In AID-based authenticity, this is also possible but much less likely, because the key state has witnesses (allowing duplicity with key usage to become probabilistically detectable). Further, an AID can be multisig, which makes it much, much harder to corrupt the control of an AID. And an AID has the pre-rotation benefit that TLS session keys do not. Setting aside the advantages of AIDs over TLS session keys at the lower level, AIDs also offer a convenient bridge to better and strong authentication at the higher, human-oriented level where bindings need to happen to eliminate MITM. It is ACDCs, which are cryptographically bound to the AIDs at the lower level. These ACDCs are the analog to HTTPS's certs and logins, but unlike HTTPS, they are symmetrical (same mechanism for both sides). They are stronger than x509 certs because they are bound to an identifier with pre-rotation features instead of to a public key. This means that x509 breaks under both innocent and malicious disruptions (lost key, lost password, proactive key rotations, stolen key), whereas ACDCs are robust under both. And ACDCs are stronger than login because the connection to the holder is cryptographic (whether you control an AID is provable, and multisig can be required) rather than circumstantial (passwords are weak, and MFA is fragile). So: TSP is less susceptible to MITM than HTTPS for a variety of reasons. That doesn't mean TSP is impervious -- there's always a chance that someone's identity could be taken over -- but it's significantly less likely. If my proposal is accepted, TSP gets stronger for another reason as well, which is that it becomes possible to reason strongly about the security properties of an interaction, no matter how complex it gets. For any given step in an arbitrarily complex interaction, we can answer questions like, "Could an eavesdropper have seen this message?" and "Who would constitute an eavesdropper, exactly, under the intentions of the sender?" and so forth. |
Beta Was this translation helpful? Give feedback.
-
|
Like any identifier, there can be fraud with AIDs, they could be stolen, be taken over, devices lost, access lost, etcetera. For issues with my domain name, phone or IP connectivity, I know whom I should contact. If there are issues with an AID, what could be the potential impact to the associated device, person or organization? What would a non-tech-savy citizen, consumer or employee do? Who are you going to call? |
Beta Was this translation helpful? Give feedback.
-
@dhh1128 Daniel, I 100% believe you that this may be brilliant. However, I do not understand it to a point that I can explain it to other people. In the mid 1990's, I did not understand these funny "IP packets" and they incomprehensible A.B.C.D addressing, nor what the use of this funny stuff would mean to regular people. Nowadays, any technical person can draft a use case that clarifies what IP packets do (e.g. "Alices goes to a webshop ..."). How can we explain this "pre-rotation" in regular-person terms (e.g. "Alice drops her smartphone into the toilet ...")? |
Beta Was this translation helpful? Give feedback.
-
|
Here's an attempt. Alice always creates TWO keypairs when she creates an AID, not one. Keypair1 is the keypair she's using to control the AID at inception, and Keypair2 is the NEXT keypair she is going to use, when a rotation happens. Her inception event includes a commitment to both. The Keypair2.pub is NOT identified by value in the inception event, but rather by its hash. This means that Keypair2 can be recognized at some future date, when it is eventually used -- but it is not known before then. As Alice uses her AID, Keypair1 is periodically loaded into memory on her device, but Keypair2 remains in cold storage (e.g., on paper in a vault). There are certain attacks that can be carried out against Keypair1, especially if Alice uses it to sign many times. Keypair1 might also be stolen by malware running on Alice's device, by peeking at memory for a trusted process while it has that keypair in memory. But Keypair2 is not vulnerable to any of these attacks. Now, suppose that Alice does actually lose control of Keypair1. A malicious attacker somehow gets Keypair1.priv and wants to wrest control of Alice's identity away from Alice. The first thing the attacker will want to do is rotate to a new key that only he, not Alice, controls. But he can't do that, because Alice has already committed to the next key that she will use; the key the attacker wants to use won't match that pre-commitment. This means that the attacker can keep using Alice's compromised key, but can't actually replace its value with a new key of the attacker's choosing. And it gets better. Although the attacker might make casual use of this compromised key, he can't actually do anything really consequential, because consequential stuff like issuing or revoking a credential involve witnesses. And as soon as Alice's witnesses learn of a new event in Alice's key event log, Alice can learn of it as well. (That's what KERI watchers are for, and it's why there is logic [based on GLEIF code] that automatically syncs a local wallet with witnesses to detect this kind of duplicity.) As soon as the attacker tries to do something that matters, and Alice finds out about it, she now has a way to lock the attacker back out of the AID. She generates a new keypair (Keypair3), and does a rotation event that announces that Keypair2 is now the one she's using. This reveals to the world for the first time the public key she committed to long ago, and it sets up the next rotation at some indefinite point in the future. Best of all, Alice can do the rotation at a point in time before the first consequential event the attacker did with her key, basically invalidating the issuance or revocation or whatever thing caused witnesses to be involved and alerted Alice to the mischief. So this mechanism means that A) An attacker's ability to wrest control is limited to wresting control for the remaining duration of the current key's lifecycle only -- Alice can always get control back; B) During the time the attacker has control of one of Alice's keys, the most he can do is sign stuff that doesn't require witnesses; C) There's already a built-in mechanism that allows Alice to discover consequential mischief; D) When she does discover consequential mischief, she can recover quickly and precisely. Of course there are caveats. Alice is still liable for whatever signatures an attacker creates during the compromised period, including the ones that don't involve witnesses and the one DID involve a witness and eventually alerted her to duplicity. Just because she goes back to her key event log and inserts a rotation that undoes a duplicitous event doesn't mean that she's off the hook, legally, for bad key management. But at least she can definitely assert which events she was actually responsible for, and clean up the public record so everyone knows how she draws the dividing line. Later, the duplicitous behavior is never able to create new victims. And she gets control back -- control that is every bit as strong as it one was. |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 Daniel, thank you for this swift response, which is completely comprehensible to the semi-expert that I consider myself. However, I am still having difficulty translating this to real-human-being cases. I have never met a human being named Alice, who manually handles keypairs, or who has a vault for cold storage of electronic keys. Not to mention that visibility of private keys to human eyes, even their controller, is a bad practice. I also don't know any bank, that would accept a mere electronic signature to release the contents of a bank account. What you describe looks like an account-recovery method, cf multi-factor authentication. However, I had the perception (please correct me if I am wrong) that human-being authentication is a ToIP layer 3 feature, and that ToIP layer 2 is supposed to be purely machine-to-machine. |
Beta Was this translation helpful? Give feedback.
-
Agreed. We assume that most real-world people will use software that performs some or all of the behaviors I've described, on their behalf. Software can't put a piece of paper in a vault, but it can print a piece of paper and tell someone to do so. Or it can shard Keypair2.priv in 5 pieces and securely share the pieces with 5 of Alice's friends. Etc. How the rotation key is protected is a matter for UX people and dev teams to struggle with -- but my reaction is that this is a reasonable solvable problem that doesn't require a lot of invention, just some lovingly built software.
I transfer money across the Atlantic regularly using digital actions (e.g., entering a password, clicking buttons) that are substantially less secure than what I've been describing here.
"Alice" in my narrative is an idealization that could be a machine. There is nothing in what I've described that requires the binding of an actual human identity. This is the distinction Sam has been at pains to make -- authentication of the controller of an identifier and authentication of a legal person are quite different. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarification! This help to understand the role of KERI. |
Beta Was this translation helpful? Give feedback.
-
|
@Oskar-van-Deventer with respect to "authentication" in the TSP proposal of an Identifier Security Overlay there are two type or levels of authentication. The first is authentication to the crytographic identifier (pseudonuym) this authentication is essentially a digital signature. This says that the statement was issued by someone who had control of the private key or keys (for multi-sig) in order to generate the signature. This I call secure attribution to the identifier. Depending on the application the second level may happen out of band to the first level. This enables privacy protection. IF the secure attribution is not secure then the linkage to a natural person is not very useful because the natrual person may no longer be in control of the private keys. So it may be that one has to re-authenticate or relink in some circumstances. But in any event TSP provides the secure attribution as the spanning layer. Other trust mechanisms can be layered on top. |
Beta Was this translation helpful? Give feedback.
-
|
@SmithSamuelM Sam, thank you for the clarification. How does your two-level concept relate to these two steps? |
Beta Was this translation helpful? Give feedback.
-
|
The TSP suite of protocols could produce a protocol that is a viable alternative to HTTPS. In 2012 Daniel Bernstein the creator of the suite of cryptoprotocols NaCL (most commonly known as LibSodium) (Ed25519, X25519 and so forth) created much more secure scalable alternatives to TCP+TLS with DNS/CA these are called CurveCP (which is a UDP based alternative to TCP+TLS) and DNSCurve which is a curveCP secure alternative to DNS. Unfortunately despite the prestige of Daniel Berstein and the fact he contributed fully function production class open source libraries. CurveCP and DNSCurve have not had much adoption. I contributed to this movement in 2014 but writing a peer-to-peer version of CurveCP called RAET and contributed that to open source. The problem with any adoption of an alternative to HTTPs is that HTTPS tooling is ubiquitous. So IMHO a better approach for the TSP is to fix the authentication of HTTPs than to outright try to replace it. Or at least do both. The primary weakness of recent versions of TLS and HTTPS is not the crypto in TLS, its DNS/CA. Of course there are problems with leakage of information out of any HTTPS session because of cross side scripting buit into HTTP/javascript. But those are controllable by the client and server. The more insidious attack is one that is not detectable by the client or the server for that matter. So both parties can blithely believe for some time that their communications were, authentic and confidential. This attack is called a DNS or BGP hijack which results in the attacker creating a perfectly compliant verifiable dns certificate for the hosts domain. A client can then be misdirected to a malicious host who presents the forged but fully verifiable certificate. That this attack is even possible is a fundamental an unfixable flaw in the design of DNS/CA. To fix it requires augmenting any Https connection with an additional authentication step that is outside the control of the DNS/CA system. We don't have to replace HTTPs we can fix it if both the client and server agree to the extra setup. This is a much lighter lift then to rip and replace HTTPS. It depends on how much leverage of https is beneficial in any given application versus using something new. |
Beta Was this translation helpful? Give feedback.
-
|
What do we imagine to be the preferred scope of the narrow waist of the stack that the TSP (the neck) sits atop? In Sam's proposal, the waist was shown as IP -- meaning precisely the "IP" that is the acronym for "Internet Protocol", the second half of the familiar "TCP/IP" pair and the core of the Internet Protocol Suite. I've always wondered if this is what the "IP" in ToIP is / should refer to. Do we only have trust problems over the internet proper, or do we have problems any time digital data flows to a remote party? Do we want to solve trust problems when info flows over NFC, Bluetooth, LoRa, UWB, LEO satellite transports, databases, message queues, sneakernet, short-wave radio...? Is the "IP" in ToIP intended to generally refer to digital remoting tech, with IP just being a convenient example? That list that I just gave includes some things that don't typically integrate with IP at all (NFC and Bluetooth; note that I said "typically", not "never"), some that are lower-level MAC protocols (LoRa, UWB), some that are (typically) higher level (databases and message queues), and some that are orthogonal to IP entirely (QR codes, sneakernet, ultrasound, short-wave radio...). Do we want our trust spanning protocol to work for these? One possible answer is to say: all of these are out of scope. The waist is pure "IP"; if it's not flowing over the true internet, we don't intend to provide trust for it. Another possible answer is to say: All of those examples can work, if they are (or become) part of a stack that uses IP. This is what I assume Sam's answer is. Am I right, @SmithSamuelM ? As Sam pointed out in his presentation, application-layer protocols above the TSP can always short-circuit. Two apps can communicate via a DB table without using IP, if they have a way of accessing the DB locally (sqlite?). And Sam's proposal provides authenticity in that scenario. But it's interesting to note that in these cases, the TSP neck isn't actually dependent on the proposed waist. The same is true of the cases that are orthogonal to IP (QR codes...). Protocols that are lower in the stack than IP don't interoperate; I can't send a message from a LoRa device and read it on UWB without using a router and IP. So the temptation is to say, "We don't need TSP to work over any of those. They just build up to IP and then go back down to something lower-level." This is what Sam implied (in my mind, at least) with his diagrams. But there are problems with this. The most important is that two devices that talk the same protocol that's lower-level than IP are forced into an IP dependence in order to get trust, if we say that the neck always sits above the IP waist. Two Bluetooth devices can't talk to one another and use TSP unless they have and use IP addresses, also? So much for TSP between Alice and Bob's phones when they're offline... Two NFC devices? So much for TSP as a basis of trust in payments... One of the things that the neck and waist implies is that the only stuff that has to fit underneath the neck is the stuff that fits atop the waist. I think the appropriate span of the TSP is actually bigger than that. This matters, because the breadth of what's spanned changes the appropriate tradeoffs for the spanning protocol atop that breadth. |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 We have said from the very start that the ToIP stack is transport independent — and thus that the "IP" in the name is just suggestive of Internet-scale interoperability, not a literal dependence on the TCP/IP stack. I believe everyone is operating under that assumption, including @SmithSamuelM. So I believe Sam has just been using the TCP/IP stack and its IP "waist" as an analogy for any protocol stack that could be used to transport TSP "trust packets". Sam, please correct me if I'm wrong. |
Beta Was this translation helpful? Give feedback.
-
One of the main reasons I went to some length to include the short circuit diagrams is because of the confusion that results when we try too hard to build a stack and stick to the strict layering of the stack. Clearly short circuits are useful obvious optimizations that are the exceptions that prove the rule. Forcing implementers to NOT use short-circuits out of some hobgoblin of consistency goes against the higher level goal that the hourglass theorem is trying to guide us toward. That higher level principle is that broader adoption wins and if short circuits are obvious easily implemented special case optimizations that increase adoption then we should use them. Slide 23 shows a shortcut at the spanning layer but the label of the slide is "shared layer routing shortcut" that means if two applications share infrastructure on any layer at or below the TSP then they are free to use a shortcut at that layer. Which means that any shared infrastructure below the TSP would broaden the support for the TSP if that shared infrastructure were part of the support and hence increases adoptability. which is the bigger principle that the hourglass principle is trying to explain, that is, how did IP win over all the other competing protocols. So much so that except for very narrow application protocol types where local channels are sufficient by themselves and don't benefit from being IP enabled, (which the same ones @dhh1128 is pointing to, NFC, USB, Bluetooth ) all protocols either became IP enabled or went away. However, that said, the ToIP foundation, the TSWG, and the TSPTF have to make a decision. Does ToIP really mean over IP or do we let in other protocols in support of The TSP that are not part of the IP stack. My slides assumed that ToIP means ToIP so my slides reflect that and I think that is the 99% use case. But my inclination is to say yes to non-IP stacks in the support if for no other reason than it broadens support for the TSP, which is the end goal anyway. The only caveat is that support for those other protocols should not thicken the TSP layer. Therefore there needs to be resolution layers analogous to ARP that sit below the TSP to adapt those other protocols. Because if we thicken the TSP in order to accommodate support from the 1% we make it harder to be supported by the other 99% and net lessen adoptability. |
Beta Was this translation helpful? Give feedback.
-
|
@talltree , I am happy with Sam's proposed answer as he states it here. I would like to make a formal proposal that the TSPTF adopt it explicitly as a guideline. Can we put that on an upcoming meeting agenda? |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 You'd think that as a co-lead of this task force, I could keep up with all the discussion threads. But I clearly missed this one for the last three weeks. However, in the intervening time, I also created a simple hack for "specmarking" (how's that for a new term? ;-) any point in these discussions that we want to be sure to include in the spec. We just reference issue #30 (conveniently called "Spec Checklist"). And voila, it will appear as a link there. And yes, I will make a note to add it to the agenda of an upcoming meeting. |
Beta Was this translation helpful? Give feedback.
-
|
@SmithSamuelM , on the image that your presented that shows the trust spanning layer: I understand that the applications above the TSP is something that need to be developed and will come up once the trust layer is being adopted. However it's not clear for me what are those platforms sitting below the TSP. Are those actual working platforms that the TSP has to be integrated with? or are those something new that should to be built after the TSP? Can you elaborate a bit on that with some concrete example. I'm trying to analyze the proposals from an implementation point of view. |
Beta Was this translation helpful? Give feedback.
-
They could be both. From an adoption perspective existing platforms may want to have trust cross from their trust domain to another. To do so requires supporting the TSP to enable that transitivity. In that case the platform might have components that sit both above and below the TSP. Because the diagram shows them sitting below they are providing support to the TSP not using the TSP. A platform may provide are some useful function that supports the TSP. For example, a secondary root-of-trust using the Cardano ledger for KERI AIDs instead of a witness pool might be more useful for those who are members of the Cardano ecosystem, but the primary root of trust is appraisable in other trust domains via the TSP. Or some support function like discovery Web search engines can be used to look up service endpoints for AIDs published in /.well-known for example |
Beta Was this translation helpful? Give feedback.
-
This discussion thread is for discussion of the first proposal, presented by @SmithSamuelM in the TSPTF meetings on 2023-02-08.
Please use this discussion thread to ask any questions or make any comments about Sam's proposal. We will start separate discussions for each additional proposal.
Beta Was this translation helpful? Give feedback.
All reactions