Replies: 7 comments 48 replies
-
|
Having asked this question, I am now looking through other things we've published to see if we've already answered it. It's a mixed bag, I think. Principle 1 of our Design Principles assumes a communication paradigm, and the terminology section and mental model diagram early in that doc clearly assume intentionality in relationships, not just authentic data. However, Principle 2 ("Connectivity is its own reward") is described with this phrase: "Connectivity in this context should be understood as the ability to exchange trustworthy information between any two endpoints." This is a more generic formulation that "communication" as I'm defining it -- it mentions "information" rather than something semantically richer like "message" and it describes endpoints but makes no assumption about intentional actors. In the actual spec that we've written, we seem to make stronger assumptions: "With regard to the first design goal, establishing trust between parties requires that each party develop confidence in the following properties of their relationship" (Section 6.1). This is a communication framing, not just a data framing. Later, we say of the Trust Spanning Protocol, "The main function of this protocol is to enable universal end-to-end communication among all Endpoint Systems using trusted messages" -- followed by 3 observations about "communication", followed by this paragraph: "This protocol is designed to be universal in the sense that all Endpoint Systems, regardless of their form factors or implementation methods, can communicate with each other using messages incorporating standard trust guarantees." (section 8.1) And we have requirements like this one, which are not about authentic data: "The ToIP Trust Spanning Protocol MUST support extensible message schema. [REQ 2.13] This enables different Trust Task protocols to be constructed without changing the base format." Or this: "L2.1 A ToIP Endpoint System MUST communicate with another ToIP Endpoint System using the ToIP Trust Spanning Protocol." (Note the use of the word "communicate" and note as well that the careful definition of Endpoint System includes intentionality.) @talltree or @wenjing, can you comment on whether the distinction between data and communication has been deliberately discussed before? Are we using "communication" as a convenient generic word to mean simply the production of data, or do we actually mean it in the sense that linguists and most business contexts would assume? |
Beta Was this translation helpful? Give feedback.
-
|
@
I would say yes to 1 but not for the reasons you discussed. Given that we agree that there are two stacks and that the authentic communicaiton stack for lack of a better term satisfies the inclusion relationship of the authentic data stack there is a way to say yes to both by saying yes to 2. Let me elaborate. The TSP architecture design team spent a while and a lot of effort discussing the design principles and as a result came up with a prioritization of three of those principles. Authenticity, Confidentiality, Privacy. Where authenticity highest priority, then confidentiality, then privacy. What I understand this to mean is that when a given ToIP protocol design must make a tradeoff between the three, that design SHOULD fall on the side of trading confidentiality for authenticity and trading privacy for either confidentiality or authenticy. This does not mean as some of these discussion has falsely concluded that headers to packets must be in that order or mechanisms must be applied in that order with respect to a given "communication". But It does say something about an inclusion relationship in an hourglass stack design. I would rephrase the questions as one question as follows: [?yes or no] We want the TSP to embrace the mission of specifying how to achieve trust for all apps that deal in authentic communication where authentic communication does not weaken the security properties of authentic data We have made an inclusion relationship that makes saying yes to 2 dependent on the ToIP principles while scoped to be narrower and sit higher in the stack. The difference in the questions is are your question are trying to affirm an opinion about the definition of a scope. And my question affirms an opinion about dependency or inclusion with respect to two scopes. I find the latter more important. My unease about this and related "topicality" or scoping discussions is that as far as I can tell (having attended many discussions and presentations by yourself and others who contributed to the design of DIDComm) that DIDComm was not designed with the same prioritization of the new ToIP architecture principles. The DIDcomm spec describes two properties, security and privacy and does not distinguish privacy from confidentiality. It does not have a clear or consistent message on what it means by security with respect to authenticity. Indeed, I believe it would be fair to say that DIDcomm is a privacy first design that makes some problematic assumptions about security. It also has a stated goal of supporting interoperability across the DID ecosystem which has problematic security issues between different did methods. Given those differences in design goals and tradeoff structure, It would be most serendipitous if DidCom ended up being the best that we can do with respect to the ToIP principles. Having yet to see anything more than hints of what a revised DIDCom as TSP that fits the ToIP principles looks like, I am extremely uncomfortable with what feels to me to be a premature scoping of the set of features that belong in the TSP stack unless those are strongly caveated on a dependency relationship as I expressed above. I don't disagree that the TSP could or should be more narrowly defined than the "authentic data" stack above but I strongly disagree that we should untether it from such a secure foundation. I often use the phrase interoperable security. What I mean by that is that any exchange of information has associated security properties and unless the exchangers are in agreement about those properties the security of the information exchanged is not interoperable. Its entirely possible to exchange information that is fully interoperable in both a syntactic and semantic way but is completely useless because it does not satisfy minimally sufficient security properties. The root of trust for any higher level trust task by any definition becomes worthless to the degree it is compromised by weakened security properties. So what does security mean? For starters it includes the trust bases that include the roots-of-trust for each of the parties to that exchange. If one party cannot appraise the strength of the other parties trust basis then the security is not interoperable. Because the one party can't understand the security properties of the other in order to decide to trust that information for whatever higher level trust task the party wishes to accomplish. An API or protocols that semantically allows parties to exchange information but does not expose to them actionable information about each other's tust basis is antithetical to interoperable security. It weakesn true trust transitivity by hiding the most important trust properties. |
Beta Was this translation helpful? Give feedback.
-
I had assumed that metadata for context expressed in something that could be called a header goes without saying an any practical protocol discussion. Only a protocol that was NLP based would not be able to make that assumption. But given the fact that many protocols today are based on self-describing data structures (aka field maps of label value pairs). Assuming a conventional "header" structure could be problematic because syntactically the payload is just one big lumped together data structure. If that is what is the source of your discontent with my proposal is then I am quite surprised. As this diagram shows:
An authenticatable message must include within the verifiable payload all the information (metadata or otherwise) that must be authenticated. The inclusion is meant to hide the distinction between authenticatable data that is metadata and non metadata, or intent casting or destinations and all of that because those are all context-dependent with respect to what is being authenticated. But what is vitally important is that by inclusion they are all imbued with the property of being authenticatable. To elaborate, in order for any meaning to be conveyed with secure attribution by any item of information, that item of information must be included in the verifiable payload. The meaning of payload is with respect to its verifiability not with respect to headers or meta-data or any other segmentation of the message. The most important verifiable item of information that MUST always be included and is not context-dependent and the point of the diagram is the identifier. Unless the identifier which is used to look up the key state is included in the verifiable payload, then secure attribution to that identifier as well as anything else for whatever purpose that is also in that verifiable payload is not possible merely given the attached signature. Is there something I missing here? Why is it important to be all-inclusive without making distinctions for other purposes? Many protocols and I mean many, make the mistake of not being all-inclusive with respect to the "verifiable" portion of a message. they leave headers out of the verifiable payload subjecting the protocol to malleability attacks and ddos attacks. So the diagram of an authenticatable message as provided above is extremely accurate in what it intends to convey. For example, OSI protocols stacks that have a session or presentation layer that provides packet authentication may have an attached signature. If done securely that signature will sign all the headers and all the payloads of all the layers of that packet not just one layer or some layer but all layers. Many protocols do not do it well .And because IP has no such provision one would have to write some custom IP stack code to sign the IP header (unless its being tunneled) because the IP stack APIs don't expose the IP header. By generalizing the verifiable payload of the message to always include all metadata for any and all uses, contexts, purposes always we protect ourselves from all the malleability attacks. It becomes a non-issue. As soon as we even entertain the option of not including all metadata in the verifiable payload then we just repeat the same mistakes so many protocols make that they later have to patch because of not following this policy. So whenever I see a protocol that has any unprotected metadata in headers much less any unprotected content data then I am going to conclude that either its not well designed and needs to go back to the drawing board or its making a trade-off and that trade-off is fully explicated in the protocols justification for not protecting the meta-data including mitigations to the malleability and ddos attacks that will result. Even the worlds best cryptographers get it wrong. For example: Ed25519 has the property of SUF-CMA (strong unforgeability against chosen message attacks) while ECDSA only has EUF-CMA (existential unforgeability against chosen message attacks). see provable security properties of Ed15519. The reason why Ed25519 has SUF (which is stronger) is that in Ed15519 the public key is prefixed to the signed data. The public key is therefore part of the verifiable payload that is signed. This protects the signature itself from signature malleability attacks and key substitution attacks (another form of malleability attack). So this design weakness in ECDSA (by not key prefixing in the verifiable payload section) makes it vulnerable to these malleability attacks (which have already been exploited for bitcoin). As a side note (because Ed25519 also does private key clamping it is safe to use the birationally equivalent keypair (X25519) for an Ed25519 keypair for encryption (i.e., as I proposed) without exposing it to key leakage attacks. Now if I want to protect the correlatability of the Identifier in the in-band transmission I could choose to do one of the following.
Or I could send the message over a confidential channel with whatever setup that requires. The setup of the confidential channel is now surveillable but the now confidential identifier inside the verifiable payload is not. I have traded off a more complex setup and surviellablity of one identifier for more privacy of the original identifier, but not authenticity of the original message (if the setup of the confidential channel is done right) I have any number of combinations of these trade-offs at my disposal where I am trading off something but hopefully not authenticity of the original message. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW I agree that share is a better term than send. And if one defines communication channels to be any way that information is shared then we are in agreement. My main problem is that you have lost the distinciton of In Band and Out-of-Band when you combine all forms of sharing into one bucket. Each communication channel == form of sharing information has different properties with respect to authenticity, confidentiality, privacy. We can solve difficult trade-offs by combining those channles in judicious ways. We can't anticipate or control all the different combinations but we can facilitate some best practices. This is where we differ in approach. I want to start with minimalist core overlays that facilitate sharing using best practices without attempting to predict all the different combinations. You want to explicate much more the higher levels and constrain all sharings to carry more required minimal content. These can be compatible if you allow them to be. Best practices of profiles of how to use underlying primitives allows one to differentiate. You could have a richer specification in addition to a bare bones one but statements like the following where you label it dangerous seem to be overstated.
The is a saying that goes a difference that makes no difference is no difference. For the perspective of security, which is how I qualified my statement, other data in the payload is just another type of authenticatable data. It certainly has other purposes and I don't disagree or pretend that it doesn't. But as far as the authentication overlay is concerned, all that matters is what is inside the verifiable payload and what is not. If its inside, then whatever purpose that data has that purpose is now protected by the signature. In JWT palance, a JWT can have a protected header or an unprotected header. Unprotected headers are insecure. To elaborate,whatever information is meant to be conveyed, which you call intent, that intent is not authenticatable unless it is included in the verifiable payload. That does not mean that we are done. We have merely defined the authenticatiabilty overlay not anything else yet. But its something we can build on. Because no matter what as long as we include that intent inside the verifiable payload section we can convey that intent authentically (as in securely attributably). I see no reason to disagree, yet you find reasons to disagree. I frankly don't understand. It seems like you want to make a difference that in the context of the discussion of an authenticity overlay is not a difference. The overlay enables intent to be conveyed as a necessary but not sufficient property. Who said it was sufficient to convey intent? It only imbues information for whatever intent that information has with the property of authenticity. So if the information is not included in the verifiable payload than that payload can't convey that information. Of course that should go without saying.
Once again I feel like you are trying to make a distinction to prove a point that is not a distinction. I carefully in my presentation described the properties of "strong confidentiality". These I summarized with a concept I called end only or only at end viewabilty where the viewer is the controller of the decryption (private key). Its not Bob or Alice or any other euphimism but the controller which is usually going to be a natural person. But the destination is only secured upto but not more than controller of the private key absent some other mechanism. This we can build on. This is the dual of end verifiablity to the source which is merely the controller of the signing private key. Both end verifiability and end viewablity have implicit intentions with respect to the controllers of the key pairs as one with respect to other end. So the intentions of authentic data are intentions in the same way that confidential data has intentions. Or they don't. I don't much care but I am a least being consistent with respect to the controllers of the private keys. When some party encrypts data assymmetrically given a keypair, they creator of the keypair had an implicit intent, that is at the very least to povide a mechanism whereby some other party could make information un-viewable by anyone but the ontroller of the key pair who holds the private key. What purpose someone might want to make information unviewable is not specified merely by the creation of the key pair, The sharing of the key pair and how its shared by convey some other intent. But these are all contextual. Likewise when a party creates a signing key pair and then shares the public key so that some other party might verifya signature, it comes with intent, what intent the sharing of the public key provides is context dependent. So if authentic data which has a shared public key is not a communication then neigher is confidential data which likewise shares a public key. Or they both are. Please pick. There are use cases where a given controller may want to asymmetrically encrypt data meant only for themselves. There are other use cases where they would be better off symmetrically encrypting data meant for themselves. It has to do with key management. But if a public key is shared (for any purpose) then already we have intent casting. So by that defintion authentic messages with shared keystate are communications. The intent is ambiguous but it wouldn't be shared unless there was an intent to contextually address that ambiguity. One reason to leave it ambiguous is for privacy. The public key can be shared, but the intent of the authentic data can be conveyed independently in an OOB message or in a different in band message. The combination makes the intent unambiguous. But forcing all expression of "authentic data" to have unambiguous intent removes one of the most powerful tools we have for managing privacy or confidentiality of intent. So I am uneasy when, you seem to want to rule out one of our most powerful mechanisms for protecting privacy and confidentialy without compromising authenticity. Ambiguity of intent is a form of privacy.It the combined effect of sharring across some set of both IB and OOB channels removes ambiguity but makes correlatability harder, doesn't that remove your feeling of danger. Which means that some all sharings look like ambiguous intent authentic data. Its only in combination that the ambiguity is removed. And in my mind that is not just a good thing but an essential thing. I know you have advocated anonymous drop boxes as a valid mechanism for sharing "communications" but a really secure anonymous drop box by definition can't convey any intent in band to the drop box. At least no more than is conveyed by the fact that some public key or keys were shared (or not) somewhere to somebody. This includes a drop box to one's self which just time and place shifts the data without having another party be a receipient. And a time and place sifted party counts as a second party in a general definition of an authenticity, confidentiality, and privacy exploitation model. |
Beta Was this translation helpful? Give feedback.
-
|
I think the burden of reading and replying here is getting to hard to sustain. Thank you for your patience, Sam. I'll cherry-pick just a few things to respond to, here. Mostly I want to note convergence.
YES
YES
YES
I love this reformulation and embrace it with an emphatic YES -- if we're using the definition of authentic communication that I proposed. I think that's the case.
This is a fair critique, and one I accept as substantively true. It is a reason why, ever since our intense face-to-face discussion in Dec 2021, I have embraced authenticity as the most important of the PAC triad. The proposal that I made was not DIDComm v2; it was some constructs from DIDComm (threading, confidential envelopes, etc) atop authenticity from KERI. Re. DID methods: the level of assurance we want to achieve with our authenticity guarantees is important. From a theoretical perspective, there is no such thing as perfect assurance, because all techniques rely on the assumption that key state has not been compromised. But setting aside this caveat, KERI's assurances with respect to authenticity are dramatically better than most other DID methods, and are still significantly better than the few DID methods that guarantee self-certifying identifiers. Prerotation and witnesses [to detect duplicity] and the KEL are really, really valuable. Without them, the assurance of authenticity we can achieve has important flaws. But I don't think that is the same thing as saying that the authenticity we can achieve without KERI is useless. A peer DID is clumsier than a direct mode KERI identifier, but its authenticity isn't horrible, only somewhat weaker. Therefore, I could contemplate an assertion that we should support DID methods that support self-certifying identifiers, instead of supporting only KERI. I am not personally proposing that; I want to fix the fundamental problems once and for all, and I think we need a rising tide of respect for doing authenticity RIGHT. But I would not consider such a proposal to be crazy -- only suboptimal in that it defers too much to politics and introduces unnecessary complexity (and vulnerabilities we could kill). My point is that I get your concern, and I agree with it. I am slightly less hawkish -- but only slightly. I don't think you need to worry that I want to learn from DIDComm in a way that pollutes the authenticity guarantees.
In a sense, I do think you are missing something, because I have not been able to make the point well enough. The fact that we CAN have headers, and that by making them part of input to the signature, we make them authenticatable, isn't news to me. My point has been that we MUST have them, and that they MUST contain certain very specific things that I don't see in your examples. It is the difference between CAN and MUST that is the essence of my concern. If we CAN answer some questions that eliminate abuse, but we allow implementers to view these answers as an optional feature, then we will end up allowing authenticity attacks that are based on abuse of context. We'll know the origin of the data with 100% confidence, but we won't know how the data fits into a larger conversation, or half a dozen other important properties that are favorite manipulation targets. If people are going to communicate, then they MUST know they are communicating, not just producing authentic data, and they MUST answer ALL of the questions required for clear communication. They must not be allowed to answer just the subset of questions required for authentic data, and pat themselves on the back and think that because they used TSP, "authenticity" (carelessly imagined) is guaranteed. |
Beta Was this translation helpful? Give feedback.
-
TL;DRSam has emphasized the power of a general authenticity mechanism based on signing with properly managed keys, and has said that this mechanism can also protect metadata. I agree. But I want to get to the discussion about what metadata is required; until we do, I don't think our authenticity story is complete. The Longer VersionSam said:
WRT "overstated', he was referring to my statement:
Here is a story from the news that illustrates the "danger" I am concerned about: https://edition.cnn.com/2023/03/08/media/tucker-carlson-white-house/index.html. And here (I think) is the video from Tucker Carlson that triggered this angry critique: https://www.youtube.com/watch?v=Opy7MLGAPBk Now, without taking sides in the highly charged political landscape, and while acknowledging that CNN and Tucker Carlson are bitter enemies, let me point out a few things about the story:
Now, I get that context is just data, so if we can make data verifiable, we can make context verifiable. It's the comfortable use of the the word "can" that raises my hackles. No doubt either Carlson or CNN "can" prove their contextual claims, but because nobody is requiring them to do so, we have a frustrating mess. I also get that at a technical level, and from a purely theoretical perspective, our authenticity mechanism should be very general. At one level, all it needs to care about is the identifier of the data source, and an opaque payload that gets signed. Sam's formulation almost nails it: anything that needs to be made authentic can be added into that payload. ("Almost" is because I think we might need a nuance about whether the signer purports to be the creator or merely the sender, and whether all parts of the payload have the same relationship to the signer. To be discussed, but not vital here.) What I'm claiming -- the whole reason for my fuss -- is that it's still possible to lie with authentic (and verified) data, by abusing context. Therefore, if TSP wants to truly solve the authenticity problem on the internet, it needs to be hawkish about authentic context as well -- not just say that context "can" be made authentic, but insist that this happen in very concrete ways. This doesn't have to change the fact that a signature is an exceedingly simple operation over a stream of bytes. But we need to have an opinion about what MUST be in that stream of bytes (or at least about what the absence of things in that stream tells us), or else we are leaving vulnerabilities unaddressed. What I've understood from your responses so far, Sam, is that you agree that context is vital, but you don't want to talk about it in detail yet, because it's outside the scope of concerns of the base spanning layer (which properly concerns itself with opaque payloads). Maybe some context is always needed, but aside from the sender's identifier, it is all negotiable according to situational needs; we should embrace the powerful and flexible possibilities. Is this a misreading? Such a position feels to me like a mistake, because an architecture that treats content and context as separable concerns with no urgency to mandate their relationship is fundamentally misaligned with truth. The one (context) begets the other (content). Simple and dumb signing is not a mistake in a narrow technical algorithm, but the TSP needs to require (not just facilitate) something less primitive if it wants to deliver a human-quality trust basis. The standard for truth in the reporting of Carlson and CNN is not, IMO, very high. If they were having this argument in court rather than in the infotainment world, they would have been required to show their video clips with superimposed timecodes, and with careful notes about what came before and after. Any claims about whether the clips are representative would also require careful justification. I think that this is also what we need to aim for with trust tasks -- and that this tells us something about the features TSP should have. Anyone who sends a TSP message about consenting to terms and conditions, for example, should be forced to contextualize that message by referencing previous and subsequent messages, including those in co-protocols that represent other branches of a related workflow -- not just because it's a requirement for consent-giving, but because it's a general requirement of authentic communication. If TSP enforced this, arguments about consent could never abuse context by producing only a single authentic message (or worse still, authentic data that isn't even framed as a message). And so on, for other contextual issues and other trust tasks. Said another way: The whole Carlson-CNN argument arises from the fact that people with megaphones are publishing authentic data as if it were authentic communication, and the public is unable to evaluate the difference. That's dangerous. |
Beta Was this translation helpful? Give feedback.
-
|
It may help to try to answer this question with reference to some specific examples, so here are some examples plus my musings about them.
|
Beta Was this translation helpful? Give feedback.
-
I don't feel the need to resolve my argument one way or another, right now. However, I feel the need to articulate the argument clearly, now, so that everyone understands we are not in fact aligned on scoping/topicality. As long as we all acknowledge that and can hold in our minds the need for an eventual resolution, I'm content to let it play out. Letting it play out, IMO, means allowing this discussion to unfold without any clear resolution, while you continue to lay out your vision. I hope that doesn't mean that this discussion has to be paused.
This has not been my intent. I agree that there is value in spending time exploring from first principles. I thought we were having success in that process. My 40-slide deck had 1 slide about a DIDComm mapping, so people with that background would know how the mental models relate. That's it. I actually started a DIDComm v3 IETF RFC doc about 8 months ago. It is not something I've argued for or even mentioned, and I imagine I will mothball it. I have repeatedly acknowledged ways that you've taught me, and ways that your design is profound and necessary, as we've gone along. When I push back, it's because of a disagreement about first principles, not because the conversation has strayed far from DIDComm.
Fair enough. We'll leave a bookmark in that, then. |
Beta Was this translation helpful? Give feedback.
-
@SmithSamuelM Correction: The DID Communications protocol (DIDComm protocol) does, in fact, tick every single ToIP requirement for a ToIP Trust Spanning Layer Protocol as documented by @dhh1128 and Brian Richter...
Authentic discussions/conversations must be based on facts. |
Beta Was this translation helpful? Give feedback.
-
I totally agree. I refer folks to the Open to Innovation principle coined by @TelegramSam... |
Beta Was this translation helpful? Give feedback.
-
@talltree Signing a piece of data (or a message in which the data is embedded) is not an attestation of the autenticitity of the data. |
Beta Was this translation helpful? Give feedback.
-
@talltree Signing has absolutely nothing to do with "the signatory attesting to the authenticity of the data." The only attestation is who was in the "notary role" that signed the message and/or data; that is, whose keys were used to sign (notarize) the data. That's all. When a notary signs your passport, the notary doesn't care if you've lied in your application or not. They are only signing/verifying your signature and maybe your photo (another form of signature). |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 picking out a few phrases from your original post...
Agreed, it's about data embedded in communication(s).
This is an impossibility (as worded). ToIP has no role in the origination of data, it's storage, and processing of virtually all LOB data (aka producing data).
Authenticity is impossible to determine by most software (maybe ChatGPT is an exception). I refer you to the following article about facts, options, and folklore: Facts, Opinions, and Folklore: A Preliminary Taxonomy (https://hyperonomy.com/2022/11/19/facts-opinions-and-folklore-a-preliminary-taxonomy/) |
Beta Was this translation helpful? Give feedback.
-
You're right. Catching me with sloppy language again. :-) The logical possibility I was trying to highlight has a focus on data getting into an authenticatable state, and "nail down" was a way of saying that we might intend to specify that very carefully, and make it a centerpiece of our output. |
Beta Was this translation helpful? Give feedback.
-
This, also, is an impossibility. There is no way to get data into authenticatable state if it is inherently not authenticatable - one way or another - that is, the solution to the data authenticatability problem (using software) is inherenty indeterminant. It's subjective. Checkout the companion article: |
Beta Was this translation helpful? Give feedback.
-
You are correct, given you use a broad enough definition of authenticatable or authentication, that is why I go to great pains to use a very narrow definition. In general "authenticatable" can only be known with some degree of uncertainty. Typically the uncertainty is largely statistical as in the likelihood that the data is sourced from a given entity or natural person. Even for the narrow definition of authenticity which is a verfiably signed message, the likelihood of authentication is influenced by the incentivization structure governing that person or entity's motivations with respect to maintaining the security of their key state. Using asymmetric keys that NEVER require an entity to share the private key, in order to authenticate makes it possible to have a very high incentivization (as in legal recourse over fraudulent signatures) for mishandling keys. That only changes the likelihood but does not remove its inherent uncertaintly, but merely lessons it (albeit materially). Anyone engaging in a transaction must weight the inherent uncertainty as a risk factor in their decision to engage in that transaction. Transactions whose value are under a given threshold of risk for a given level of uncertainty can proceed in an automated fashion. Transactions whose value exceeds that given threshold should not proceed, thereby protecting the associated party. The point is that in any case one can argue that there is no such thing as true or complete authentication, which is a true arguement, but not a very useful one. |
Beta Was this translation helpful? Give feedback.
-
@SmithSamuelM Authenticatabiity, in addition, is not even within the reasonable realm of possibility. There is no way, in the general case which is the case we need to focus on in a specification, to determine if a sample of data is either authentic or authenticable. Here's some a preliminary taxonomy: https://hyperonomy.com/2022/11/19/facts-opinions-and-folklore-a-preliminary-taxonomy/ Here's some examples:
You can guess about the auth* of these. Some might be determinable by the context of a currently executing instance of a business process workflow, etc (e.g. a procurement/pruchasing business process workflow). But I believe these contexts are outside the scope for the Layer 2 Trust Spanning Layer Protocol discussion. As I describe in detail in Proposal 4 (https://hyperonomy.com/2023/02/22/proposal-4-to-toip-tsl-tf-web-7-0trust-spanning-layerframework/), auth* can at best be determinable at Layer 3 in the context of a specific Layer 3 Super Protocol Overlay (Specialization). See slides 46, 47, and 48 (73) in version 0.17 of the Proposal 4 presentation.
p.s. Truth always needs to prevail ...if not, why does it matter at all? |
Beta Was this translation helpful? Give feedback.
-
|
One of the most frustrating aspects of any discussion is that language is imprecise. Most words in the English language have multiple defintions. One recent measure stated there are over 1 million words in the English language, the OED has over 600,000 word forms each with multiple definitons. So millions of terms. Yet we find that in highly technical conversations there are not enough words or word meanings to precisely describe what we mean. This means that in most conversations, inadvertent equivocation is highly likely. But once identified we should refrain from equivocation otherwise discussion is not about understanding but about marketing to the audience. So when you use the word authentication, I honestly have no idea what you mean by that use of the the word. In a previoius comment I responded with how I meant to use the word and gave you a much more precise definition. I can't even know where to discuss unless we first agree on what it is you are talking about. When you state "authentication is impossible", as I have already said above, depending on how you define authentication, the statement is either true or false. In a broad sense of the word its true but in a narrow sense of the word is is false. We have "authentication" protocols that based on that protocol's definition of authenticate perform authentications by the millions successfully. So either you are using hyperbole or I don't understand what you are saying. |
Beta Was this translation helpful? Give feedback.
-
|
A lot of words @SmithSamuelM but I don't understand what the "takeaway" is supposed to be? |
Beta Was this translation helpful? Give feedback.
-
NOTE: We need to strive for defintions and contexts that have not been KERIzed. Here is a more basic set of definitions that do not include any KERIsms. I think this is very basic:
More specifically,
|
Beta Was this translation helpful? Give feedback.
-
|
Authentication or Authenticability of Data is a Layer 3 Super Protocol Issue - not A Layer 2 Trust Spanning Layer Protocol topic.
|
Beta Was this translation helpful? Give feedback.
-
|
@mwherman2000 If you read the full content of the threads in this discussion (which I admit is a big task), then I respectfully disagree. Sam's proposal is in fact that data that can be authenticated (what he calls However if your point is that using the term However — as you have pointed out elsewhere — usage of the term
Given that we can't change this ordinary English meaning — and if we agree that the concept we are trying to describe is "data that has been digitally signed by the keys associated with a cryptographically verifiable identifier" — then I am going to apply the lessons we've been learning in the Concepts and Terminology Working Group and suggest two options:
Example of option 1: call it Example of option 2: we could choose the same word used in the W3C DID and W3C Verifiable Credentials specs — verifiable — and make the term |
Beta Was this translation helpful? Give feedback.
-
|
OTOH - as Reiks Joosten (in the Mar 13 Concepts & Terminology WG pointed out - there is nothing stopping ToIP from specifying (overriding) the terms I would suggest that:
|
Beta Was this translation helpful? Give feedback.
-
|
TL;DR: Skip to the header SUGGESTION As I said yesterday in the CTWG meeting, different people have different conceptualizations (i.e., sets of related concepts/ideas they use in their mind to make sense) of the things they talk about. Often, such conceptualizations are valid, meaning that they actually make sense to those that use them. Lots of discussions and misunderstandings arise, AFAICT, because people mix their own conceptualization with that of others. It doesn't work like that. Even under pressure (of e.g., a deadline) it still doesn't work. The first step, as I see it, to coming to grips with this is to ask people to clarify their concepts such that we can learn what they are, and test whether or not we can agree that we have the same understanding. We do that by (temporarily) setting our own ideas, concepts, truths, etc. aside, and then stimulating and helping a person come up with a criterion for each such concept (which Merriam Webster says is: "an abstract or generic idea generalized from particular instances", i.e. a class of things, behaviors, etc. that have some commonalities that make them instances, or examples of that class). A criterion is simply a test to check whether or not something has these commonalities that make it an instance/example of the class (or not). Note that concepts are ideas, thoughts, intangible stuff. They are not terms. A term is just some text that refers to that particular concept. And one might say that the pair (term, criterion), where the term refers to a concept and the criterion can be evaluated to determine whether or not something is an instance of the term, might be called a definition. There is nothing intrinsically right or wrong about any such pair. But specific pairs may be more efficient when used to make sense (of a specific part) of the world. While in discussions like the above it is ok to start of with some term, the next thing we should do is come up with the criteria that different people have associated with such a term. They are going to be different and that is ok. We FIRST need to understand what they are about (and possibly also what the criteria are for the concepts that are related to them in a conceptualization of a person). I know this takes time - likely more time than people feel comfortable with. Fortunately, there's a choice: you can either do it this way (and experience what good - if any - comes from this), or do it in the way you have been using for the past decade(s) or so (and you will be able to predict what you'll end up with). Lawyers have been there. Over the years, at least in the Netherlands, it has come to pass that in one of the first Articles, they have a glossary, which is a list of (term, criteria) pairs. They do this because judges and other lawyers can then determine, for example, whether or not you qualify as a 'driver' or 'owner', or ..., which would have the implications that the laws state for 'drivers', 'owners', etc. Doing this makes it much easier to have the same understanding about what the law is about - even if you do not agree (because that's a different matter). Note that two different laws may have different definitions for the same name, or different names for the same criterion. They may also 'import' terminology from other laws, saying that terms X, Y, and Z are defined in article 1 of a particular other law. It's exactly what CTWG proposes that we do in governance frameworks, architecture documents, etc., etc.. This is how I think the conceptualizations of a community could be constructed. Individuals do not need to agree (I do not agree with every law in the Netherlands). Being part of a community means that you can deal with its conceptualizations, and since you're a 'party', that is autonomous (self-sovereign if you will), you still get to keep your personal conceptualizations. There are several things we can do. An obvious one is to come up with sets of criteria for concepts/ideas/classes of things, behaviors, etc. and find out which are relevant for the TSP. Don't bother about assigning them terms yet. Call them C1, C2, etc. or something similar. Continue until the set is more or less complete. Then choose names that seem useful, and continue as usual. SUGGESTION Another idea is to make a list of 'disputed terms', i.e. terms that we are arguing about. In this issue, terms such as 'authentic data', 'authentic communications', perhaps even also 'data' and 'communications' themselves, would go on the list. Then, make it a habit to NOT USE any such term in any text you write or speak (e.g.: in this very issue), but instead, use the criterion that enables others to make the same distinction as you do. For example, suppose I wrote the first post in this issue, which contains the phrase "authentic data is great", which contains the disputed term 'authentic data'. Since I should not use the term 'authentic data', I need to resort to something like "data that I have received from a party that I trust is great", if that is what I want to say. This does several things. First, it forces me to express what I want to say, rather than burdening my audience with figuring out what the hell I mean by 'authentic data'. It can be an insightful, sometimes also humbling experience. It may even resolve some problems that I had. Actually spending time on this is a real contribution to the community in which the dispute lives. Second, it helps others to better understand what my position is. I would consider "data that I have received from a party that I trust" much better to understand than "authentic data". This puts them in a better position to contribute to the resolution of the dispute. Third, it may become messy, e.g., if a new dispute is started over the term 'trust' that I used. If this were put on the list of disputed terms, I'd have to rephrase it again, and run the risk of (again) using words that will be disputed. We have to deal with this sensibly when it happens keeping in mind that we're not doing this to follow the procedure, but to come to a better understanding of each other, and create a conceptualization of the things we're talking about that we can all understand, yet may (not) totally agree on. |
Beta Was this translation helpful? Give feedback.
-
During the very brief Q&A at the end of my preso the other day, @SmithSamuelM pointed out that I was using the word "authentic" in a way that seemed odd. He was right, but my mistake was actually worse than his polite comment implied: I wasn't just using an unusual definition -- I was being inconsistent. Ugh. I have written a little bit more about that here; read down at least as far as @sawhitmire's comments if you want full context.
This new discussion is to frame a larger question which is at the heart of my inconsistency. It's the question in the discussion title, and I think it's vital that our TF explore and align around an answer to it. Doing so may lead to an obvious answer to any disagreements we have about layering.
Authentic data is great -- but I claim that it is very much not the same thing as authentic communication. This is not because I define "authentic" differently, but because of the noun that follows the adjective. Data is not communication. Astronomers analyze the chemical composition of a star using a spectrograph. A spectrograph is data. We may use some verbal sleight-of-hand to say that the data "speaks" to us, but this is only sleight of hand. Actual communication has the defining characteristic that it is the embodiment of intention to produce interpretive effects in an audience. This is true even when we talk to ourselves.
I have been under the assumption that it is the act of communicating authentically that ToIP should nail down. I think Sam has been under the assumption that it is the act of producing data authentically that ToIP should nail down.
Here is the argument for focusing on authentic data, as I understand it (and as I believe it):
More could be said, but I think this sums it up fairly, and I agree with all of it.
However, I think that authentic data is relevant to many use cases that are outside the scope of concerns of ToIP. Whether a spectrometer signs its spectrograph is an interesting authentic data question, but it is not at the heart of ToIP's raison d'être. Whether a particular block is part of Bitcoin is an interesting authentic data question, but it is not at the heart of ToIP's raison d'être.
This doesn't mean that ToIP is uninterested in such things; a scientific governance body in ToIP's layer 4 might well have something to say about whether spectrographs should be signed, and an ecosystem that uses Bitcoin might impose requirements about how long to wait before trusting a commit to the blockchain. This is, I believe, the kind of trust tool usage that we imagined in our Design Principles whitepaper when we said, "Parties can use all the facilities of the ToIP stack—DIDs, verifiable credentials, governance frameworks, trust registries—to accumulate the evidence necessary to make [a given] trust decision." [p. 13] But notice that statements about signed spectrographs or Bitcoin commits could also, easily, be made by entities that have no intention, need, or desire to fit into ToIP's model and don't care about the kind of trust we are trying to achieve here. In this sense, I would compare authentic data to something like multisig schemes. Yes, we totally want them, and we plan to use them -- but using them isn't a uniquely defining concern of ToIP. They are world support infrastructure to us, and we call on them as needed to suit our purposes.
On the other hand, I have thought that authentic communication IS a defining concern of ToIP. The very first principle in our Design Principles whitepaper is the end-to-end principle. Set aside Beck's ambivalence about its power to explain and guide (ambivalence which I think you share, Sam?), and just look at the language we use to justify its primacy. It tells you something about where our heads and hearts are. We say that this first of our design principles is all about "application-specific features resid[ing] in the communicating end nodes of the network." [p 11] A little later in the whitepaper, we explain our reliance on it again with communication in our minds: "The only way to deliver end-to-end security and end-to-end privacy to parties communicating over the Internet is with end-to-end protocols." [p 13] The point I'm making is not about whether we chose our principle wisely; it's that we justified our first principle with an argument about communication. Our 8th Design Principle, "Trust is human" and our 9th, "Trust is relational" are also suffused with communication paradigms.
I believe that the reason we did this is because it is when we change our mental frame from data to communication -- by postulating a message sender with intention toward another party -- that trust gets gnarly. I believe that ToIP passionately aspires to provide the definitive answer to the question of how trust is built and evaluated under that condition, not under the more general condition of how to decide the origin of data in the abstract.
If I am right, then the bottom of ToIP's trust spanning layer should be the weakest thing that is had in common by all higher-level constructs wanting to build on trusted communication. My clumsy attempts to explain why we needed to guarantee that intentions of a message sender are defined actually make sense, under that worldview: we can't afford to have people think it's optional to declare their intentions about messages. This doesn't mean that we combine layers and pollute the beautiful simplicity of what Sam has built for authenticity -- but it means that authentic data is a Layer 1 tool, not a layer 2 narrow neck/waist. Authentic data is not minimally sufficient for authentic communication, but it can certainly be the way we achieve it. In that view, if we found other supports that were capable of delivering the same things as KERI, they would all be alternatives that our spanning layer could use.
If I am wrong, then the bottom of ToIP's TSP is just authenticity as Sam proposed it. Authenticity is the ONLY characteristic that we guarantee to be shared by everything above it, and the scope of concerns for ToIP is anything that has that solution in common.
Beta Was this translation helpful? Give feedback.
All reactions