Friendlier intro/discussion for the Claimant Model

[mhutchinson]

I've referred to it as a book in a tongue-in-cheek way. It isn't intended to be as long as a book, but there are similarities in that it is intended to be read in order, and should favour accessibility over being absolutely technically correct from the offset.

[haydentherapper]

I see later you define the Verifier role, but would it be worth specifying what "verify the Claim" means here? This was something confusing initially, thinking that verifying = signature verification, not accuracy of the claim

[phbnf]

+1

[haydentherapper]

Did you want to expand on this? Provide a non-technical example of a Believer and Claimant?

[mhutchinson]

I've added an example but I think I backed out of doing this in the first place because I could foresee the objection that an implicit unsigned claim isn't technically a claim according to the claimant model. This is valid, but hopefully the example still provides an onramp for people to relate to the model even if it isn't perfect.

I'm open to replacing this with other examples, or deleting entirely.

[haydentherapper]

Maybe a concrete example here, falsifying the TLS certificate claim?

[mhutchinson]

I'm glad I left this for a day after returning from leave because I think yesterday I would have followed the easy path and written down that verifying the TLS chain was falsifying the claim. And it isn't. And this is the trap.

I've addressed this comment by writing a lot more text here that I think sows the seed. PTAL?

[haydentherapper]

Either in this section or somewhere, is it worth explicitly stating that this expects that claims are present/discoverable in a transparency log? That's something that wasn't immediately obvious to me learning the model.

[mhutchinson]

I've added a TODO in the Verification section to continue the narrative there and introduce discoverability. Logs are a mechanism to achieve discoverability for verifiers, so that's the appropriate place to talk about logs IMO.

Does that address your comment, or is there some deeper connection with logs that you think that Claimant Model requires discussing?

[haydentherapper]

This part about the motivation of transparency might be useful higher up.

[mhutchinson]

I understand why you think that as the operator of a log. I have tried to stage this doc in a way that leads from the symptoms, to the underlying problem, and then on to the solution. Given that logs are the solution, it feels natural that they should appear later in the doc. Perhaps this is a fallacy though and the majority of readers will be familiar with the concept of logs and delaying introduction of them is unsatisfying.

I'll leave this comment open to reconsider the narrative structure. Perhaps instead of A-B-C-D this should be something more like A-c-B-C-D, i.e. tease the ending near the beginning but without going full https://en.wikipedia.org/wiki/Reverse_chronology.

[mhutchinson]

I've since added a TODO to consider adding something like this at the end of the Introduction section. WDYT?

[phbnf]

+1

[phbnf]

I wonder whether this section could be stripped out entirely. I think these are two examples of systems where transparency log would not really add anything. While it might seems clear to someone familiar with transparency ecosystems and logs, other people less familiar with these systems should realise this going through the exercise of writing the claimant model.

[mhutchinson]

It could be stripped out, but it was added to set the idea for very eager people that there is a limit to where mapping to CM is useful. For example, I saw someone get overly excited about the claimant model and start to define asymmetric key usage using it. You can do it, but it makes things more complicated instead of reducing complexity.

[phbnf]

I get what you mean, but I find this quite negative. It seems like the Claimant model is incomplete, and allows for exploit, when in really it gives you the framework to think about these exploits.

How about something like "Claims made by the Claimant can be true of false. Since they are trusted by the Believers, a false Claim made under the identity of the Claimant would be believed by a Believer, and they would
perform some trusted action based on this false Claim.
The claimant model describes clarifies the relationship and incentives between Actors such that Believers can safely perform actions based on Claims."

[mhutchinson]

I'm glad that this sentence was provocative. I think a little spice is required at points through long text to keep the interest and prompt alertness. That said, I don't want the takeaway from this to be "claimant model = bad".

I've added some more text here that I think turns this bold statement about exploitation into a motivation for using the claimant model instead of running away from it. PTAL?

[mhutchinson]

Great comments, thanks for the engagement. I'm feeling that this is still miles away from done, but hopefully the latest changes take it a step in the right direction.

[mhutchinson]

I've added an example but I think I backed out of doing this in the first place because I could foresee the objection that an implicit unsigned claim isn't technically a claim according to the claimant model. This is valid, but hopefully the example still provides an onramp for people to relate to the model even if it isn't perfect.

I'm open to replacing this with other examples, or deleting entirely.

[mhutchinson]

I'm glad I left this for a day after returning from leave because I think yesterday I would have followed the easy path and written down that verifying the TLS chain was falsifying the claim. And it isn't. And this is the trap.

I've addressed this comment by writing a lot more text here that I think sows the seed. PTAL?

[mhutchinson]

It could be stripped out, but it was added to set the idea for very eager people that there is a limit to where mapping to CM is useful. For example, I saw someone get overly excited about the claimant model and start to define asymmetric key usage using it. You can do it, but it makes things more complicated instead of reducing complexity.

[mhutchinson]

I've added a TODO in the Verification section to continue the narrative there and introduce discoverability. Logs are a mechanism to achieve discoverability for verifiers, so that's the appropriate place to talk about logs IMO.

Does that address your comment, or is there some deeper connection with logs that you think that Claimant Model requires discussing?

[mhutchinson]

I understand why you think that as the operator of a log. I have tried to stage this doc in a way that leads from the symptoms, to the underlying problem, and then on to the solution. Given that logs are the solution, it feels natural that they should appear later in the doc. Perhaps this is a fallacy though and the majority of readers will be familiar with the concept of logs and delaying introduction of them is unsatisfying.

I'll leave this comment open to reconsider the narrative structure. Perhaps instead of A-B-C-D this should be something more like A-c-B-C-D, i.e. tease the ending near the beginning but without going full https://en.wikipedia.org/wiki/Reverse_chronology.

[mhutchinson]

I've since added a TODO to consider adding something like this at the end of the Introduction section. WDYT?