Standardize Nomenclature with Glossary

[sinui0]

This PR is to come to consensus on the various terms used when describing the TLSNotary protocol. I have created a file called GLOSSARY.md in the repo root.

Please review these definitions, add any terms I may have missed, and argue for distinctions where you see fit.

[themighty1]

I would prefer to not use the word "Note" because it will not be intuitive to the outsiders. We should have a name which we both can use internally and also if an outsiders encounters it, he would be able to perceive what it means.

I propose the word "Doc" capital D. The only ambiguity it can cause for an outsider is whether we are talking about some kind of HTTP document that has to be notarized.

[themighty1]

I think that Revelation should actually be called Proving of Proof phase The users of TLSNotary expect that the Prover will be proving things about the TLS transcript to the Verifier.

In light of this would be good to more carefully use the word prove in other contexts like e.g.:

Prover An entity which has Request(s) and wants to be able to prove particular > Response(s) are returned when processed by the Server

Here the better wording could be "wants to get an attestation from the Notary that particular Responses..."

Would be nice to get in the habit of saying that in the Notarization phase the Notary ~~attests~~ notarizes, rather than Prover proves. (Edit: no need to introduce a new term attest into this conversation). Then the word proves can be reserved for zkps.

[sinui0]

I would prefer to not use the word "Note" because it will not be intuitive to the outsiders. We should have a name which we both can use internally and also if an outsiders encounters it, he would be able to perceive what it means.

I propose the word "Doc" capital D. The only ambiguity it can cause for an outsider is whether we are talking about some kind of HTTP document that has to be notarized.

My feeling is that Doc is not very self explanatory either.

Instead of Doc I would accept conceding there isn't a descriptive succinct word for it and simply calling it Notarization (as a noun not a verb). The alternative could be Attestation, but then we get into the semantic differences between Notarization and Attestation and why isn't the protocol called TLSAttestant? :slightly_smiling_face:

---

I agree that Revelation perhaps isn't the best term for the second phase. It may confuse someone into thinking that the plaintext of the Session is being revealed, which could be true in some cases but not all.

Would be nice to get in the habit of saying that in the Notarization phase the Notary attests

Does the Notary attest, or notarize, or both? I feel like we need to assert that those words are used interchangably even though they do have semantic differences in law.

That aside, and to your point, I agree that the subject of the verb in the Notarization phase should be the Notary.

---

Is there a better term than Prover for the first phase? Not Client... but perhaps Claimer? Now I'm just spitballing. Language is messy.

My reasoning is that the Claimer isn't necessarily the same entity as the Prover, and that term is likely going to be the primary cause for context confusion between the two phases.

[themighty1]

Does the Notary attest, or notarize, or both? I feel like we need to assert that those words are used interchangably even though they do have semantic differences in law.

I realized that I was wrong bringing up attest. We already have notarize and it is enough to just stick to notarize. I only wanted to emphasize that if we stear clear from saying that the Prover proves (in the Notarization phase), then this frees up the word prove to be used exclusively for the Proving phase.

My reasoning is that the Claimer isn't necessarily the same entity as the Prover, and that term is likely going to be the primary cause for context confusion between the two phases.

how do you mean Claimer != Prover ?

[rozbb]

Thank you for making this doc! My thoughts (suggested terms are bolded):

I agree with the consistency arguments for phase 1. Let's leverage the name of our thing as much as possible. It should be the Notarization phase, and the parties involved should be the Notary and the Requester (Prover is way overloaded at this point, and also not descriptive). At the end of the phase, the Requester obtains the Notarized TLS Payload (more descriptive than Note IMO, and it also uses the thing in our name, so people can see the story here; we can abbreviate to NTP when necessary). The rest of the terms are less important right now IMO, since they are internal to the protocol.

Phase 2 is a little harder. To borrow from anonymous credentials terminology, I think it could be called the Selective Disclosure phase. There's the Discloser and the Verifier. To fill in the smaller terms, I'd say the Discloser proves a Predicate over the Notarized TLS Payload, and the Verifier verifies it.

What do y'all think? I'm trying for the most descriptive terms possible.

[sinui0]

it is enough to just stick to notarize

Agreed.

how do you mean Claimer != Prover ?

I mean that the Prover in the second phase isn't always going to be the same entity as the first phase.

the parties involved should be the Notary and the Requester

I'm in favor of Requester, that is a good name for it.

Notarized TLS Payload

This is still a mouthful and I'm not sure I'm in favor of calling it a payload. Perhaps Notarized Transcript?

Selective Disclosure phase Discloser Predicate

I'm in favor of these terms as well.

[rozbb]

Notarized TLS Payload

This is still a mouthful and I'm not sure I'm in favor of calling it a payload. Perhaps Notarized Transcript?

Yeah, not in love with NTP either. No better options come to mind rn. Notarized Transcript is vague because it's unclear which transcript it is. As a cryptographer I'd reasonably believe that it referred to the MPC transcript. It's be nice if "TLS" appeared in the name here, because that's what's being notarized (and "payload", "data", "note", "response", "transcript", "answer", etc. are all too vague without talking about which protocol they belong to).

[sinui0]

because it's unclear which transcript it is

What other transcript would be getting notarized? I think we can assume some context has been established. We don't want to have to fully qualify the term everywhere and I'm not a fan of abbreviations. Full qualification can be used where appropriate.

This effort should be standardizing the terms we use internally, and to make sure our internal lingo is consistent with how we talk about it externally. Our documentation can include this glossary which people can refer to in the case where they are not familiar.

[rozbb]

What other transcript would be getting notarized? I think we can assume some context has been established. We don't want to have to fully qualify the term everywhere and I'm not a fan of abbreviations. Full qualification can be used where appropriate.

Ok agreed. I don't love Transcript because transcripts normally contain every message sent in both directions, from beginning to end. So, synthesizing some stuff we already have, what about Notarized Response?

[sinui0]

transcripts normally contain every message sent in both directions, from beginning to end

We are including every message sent in both directions (minus the handshake messages, but keeping the signed ephemeral key from the server). The requests are required to establish the context of the responses. The Notarized Transcript will include a signed and ordered list of commitments to the plaintext requests and responses. If you still want to veto Transcript, perhaps Notarized Session? Fully qualified to Notarized TLS Session

[rozbb]

Oh I see, I didn't realize it was a full transcript. In that case yeah I'm fine with Notarized Transcript. That covers all the terms, right? @themighty1 what do you think?

[themighty1]

I mean that the Prover in the second phase isn't always going to be the same entity as the first phase.

Could you give a specific scenario?

I think the word Requester could be used only when there is ambiguity and a need to emphasize the Prover's role in the Notarization rather than the Proving phase.

[sinui0]

Could you give a specific scenario?

There can be use cases where someone wants to distribute the Notarized Transcript and plaintext to another party so they can use it as well. It's hard to be specific off the top of my head, but we shouldn't presume otherwise.

The reason I favor Requester is because they aren't actually proving anything during Notarization. They are just querying a server and generating a commitment to a Transcript. When we first arrived at the term Prover we hadn't really spent much time distinguishing between the two phases.

[sinui0]

In our weekly meeting we discussed this and concluded some things:

• We will use the term User to refer to the Requester and Prover when talking about the protocol at a high level
• We reached consensus on the terms Requester and Prover for the Notarization and Selective Disclosure phases, respectively.
• We more-or-less agreed on using Notarized Transcript, though there are still some reservations about it colliding with other crypto terminology.

I will update the glossary this week with these things settled.