Help: This page shows how the referencing vocabulary definitions are maintained and interlinked for controlled consistency of documentation. Click on the hyperlinks to see how the terms are defined within the Askemos architecture. more… Tip: Remember the back-button!

This page has three main sections. (Note that the listings could be empty.)

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
1402 see also > Mission-oriented Resilient Cloud
1579 see also > There ought to be two rules about. One: Avatars ought to exist independent of any individual social contract put forward by any particular space. And two: Social contracts ought to be available in a machine readable form which allows the avatar projection intelligence to know exactly what the rules are and to allow you set effective guidelines about I don’t go to spaces where people don’t treat me in ways that I consider to be crucial in my treatment.
1652 see also > replicates (Askemos)
1902 comment > Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract. The term is often seen in a legal setting wherein the authenticity of a signature is being challenged. In such an instance, the authenticity is being "repudiated".
648 is a > wiki page
664 subject (keyword) > intrusion-resistant
1234 subject (keyword) > Logical Attribution of Warrants (LAW)
2227 subject (keyword) > Data integrity
650 description >

"Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract." [wikipedia]

Non-repudiation is an essential component of any digital transaction system that involve the changeover of money or property.

Askemos applications enable the human users to exchange information – contracts, images, money, etc – in such a way so as to guarantee all transitions can not be repudiated. Askemos accomplishes non-repudiation by using networks of computers called notary device, or notary for short.

Each user has (normally and at least) one notary they alone operate. A notary device in this role is termed a representative. The owner of a representative gets to choose which applications (scripts a.k.a. contracts, e.g. wallets, diaries and so on) it may run and for each of those to choose additional notaries that are collectively trusted to officiate the operation. This makes it so no one can cheat.

A wallet to manage funds – as documented here – would be a typical example application that requires such assurance. Though any kind of "software agent" could be used that way.

Repudiation in Askemos

If a user needs to repudiate the authenticity of a signature for a transaction in Askemos, we resort to human intervention. Users need to physically "pull the plug" by disconnecting their personal representative from the notary network. This preserves their evidence of the state of affairs, which they can present to the legal authorities or arbiters of the network. Arbiters are typically the owners of the notaries who are commissioned to audit the repudiated object.

Non-repudiation in digital security

Citing wikipedia with minor edits:

Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean:

  • A service that provides proof of the integrity and origin (provenance) of data.
  • An authentication that can be asserted to be genuine with high assurance.

Proof of data integrity is typically the easiest of these requirements to accomplish. A data hash is usually sufficient to establish that the likelihood of data being undetectably changed is extremely low.

This "easiest" requirement is accomplished by the implementation: every object and every change is identified by a canonical hash. (see also OID)

Trusted third parties (TTPs)

Citing wikipedia again:

The ways in which a party may attempt to repudiate a signature present a challenge to the trustworthiness of the signatures themselves. The standard approach to mitigating these risks is to involve a trusted third party.

The two most common TTPs are forensic analysts and notaries.

To aid forensic analysis, users keep their own representative and switch it off to preserve all evidence in case of doubt. (See "Repudiation in Askemos" above.)

Otherwise there is little to add to wikipedia when it comes to the duty of notaries:

A notary provides a witness whose job is to verify the identity of an individual by checking other credentials and affixing their certification that the party signing is who they claim to be. Further, a notary provides the extra benefit of maintaining independent logs of their transactions, complete with the type of credential checked and another signature that can independently be verified by the preceding forensic analyst. For this double security, notaries are the preferred form of verification.

Askemos's "notary devices") operate in a similar fashion, only translated into a digital space:

A notary device is essentially an "electronic witness" whose job is to verify the identity of a representative by checking other credentials and affixing their independent certification that the representative signing is what they claim to be. Further, a notary maintains independent copies of their transactions, complete with the current state of the contract, a time-stamp, and the type of credential checked.

Importantly, only when enough independent notaries have approved an identical transaction, is the transaction allowed to take place. A human analogy would be having not only one, but 2 or more independent certified notaries check every datum pertaining to the transaction plus verify each other correctly doing so. This provides additional assurance to both business people that the credentials and veracity of each are "doubly verified". For this double (or triple) security, notaries are the preferred form of verification. In Askemos one can have more than 2 or 3 third parties – and, its software can perform multiple independent checks much, much more swiftly than any human agent.

Note that just one notary is still a trusted third party in the strict sense of "trusted" meaning being able to fail, possibly due to malice, thereby being able to break the specific security policy. By commissioning multiple notary devices from different operators, users create their "trustworthy network" according to their personal preferences.

Currently the Askemos implementations use byzantine agreement to implement consensus on active replication among notaries.

Side-note: A popular consensus protocol these days is the Bitcoin "block-chain". This "block-chain" is a Merkle tree just like the versions of places in our implementation. Therefore it seems to be a viable alternative and maybe we'll see an implementation of Askemos on top it. The Ethereum project is working on something like this. The Bitcoin protocol however requires a proof-of-work instead of our commissioned notaries majority vote. This makes Bitcoin much lower and resource hungry, while I fail to see an advantage over the notary concept. I expect it to be too slow for any practical purpose. I might be wrong at that. Time will tell.

1904 see URL >
2206 best practice > Consensus protocol

InCorruptible subject (keyword)
keywords&details subject (keyword)
Cryptography subject (keyword)
Signature subject (keyword)