Crypto-less assertions defined

Following up on my intro to crypto-less assertions, let’s define what they look like. Here is an example:

---

  Alice is skilled
  ---
  http://bob.example.com/alice.txt
  https://dave.example.com/alicia.txt
  http://mallory.example.com/alice_skills.txt

---

It looks really simple. And it is. A crypto-less assertion has only two parts:

1. The assertion. This is any statement, in any text form. In our example this is “Alice is skilled”.
2. The asserters. This is the set of URLs of asserters that presumably agree with the statement. In our example this set contains three URLs.

In other words, the crypto-less assertion follows this form:

---

  [statement]
  ---
  [asserters]

---

When Carol has an assertion she wishes to verify, she would go through the set of asserters, decide which (if any) of the asserters she trusts to make the assertion.

She then HTTP GETs on the given URLs and compares what she gets back. When she gets enough responses with the exact same assertion, she can form an opinion whether the assertion is valid.

The nice thing about this scheme, apart from it being really simple (which is always good!), is that anyone can decides on their own which set of asserters they trust. The trust is not binary, either. In the example above, Carol may put more weight on Dave’s assessment than Bob’s. She probably would reject Mallory’s.

Note that in (1.) that the assertion can be in any form. This means the assertion can be anything from simple unstructured text, as in the example above, through structured syntax, all the way to full-blown XML (even existing SAML assertions).

There are still some issues with how you maintain the set of assertions or how you propagate changes to assertions, but I think this is a good start for discussion.