Askemos

Non-Repudiation

"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.


614 Request Dispatch Overview container member ## Request Coming In The following sketch outlines the first stage of request processing. Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. a
626 Request Dispatch Overview container member Once the protocol has consummated, changes are committed to permanent memory and additional messages may be sent out to trigger further processing and eventually a result will sent back to the client
650 Non-Repudiation 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-
1070 Notary (Askemos) is a dataset
1073 Notary (Askemos) description An Askemos peer is typically contained within directory in the file system of the host device. Usually a token of any size as part of a proof of identity.
1074 publicOID domain Notary (Askemos)
1079 replicates (Askemos) range Notary (Askemos)
1181 ## Request Coming In The following sketch outlines the first stage of request processing. Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. a see also revise
1238 about comment ## How The Idea Came To Be Askemos and BALL are two results of several years research and development. It all startet with a casual observation. The privilege handling in computer systems did so far
1240 about container member ## Applying Principles In Practice The challenge was to create a sound model, which is simple to verify independently and *not* to invent anything anew. To keep the system within bounds, just inalie
1428 ## Request Coming In The following sketch outlines the first stage of request processing. Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. a coverage (spatial or temporal) Current trusted system
1476 ## Request Coming In The following sketch outlines the first stage of request processing. Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. a subject (keyword) EntryPoint
1545 The Origin Of The Idea "Askemos" description ## Applying Principles In Practice The challenge was to create a sound model, which is simple to verify independently and *not* to invent anything anew. To keep the system within bounds, just inalie
1661 Representative (Askemos) is subclass of Notary (Askemos)
1669 ## Request Coming In The following sketch outlines the first stage of request processing. Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. a subject (keyword) Representative (Askemos)
1670 Notary (Askemos) ↑ ... is defined by Askemos
1674 Once the protocol has consummated, changes are committed to permanent memory and additional messages may be sent out to trigger further processing and eventually a result will sent back to the client see also Privacy
1676 ## How The Idea Came To Be Askemos and BALL are two results of several years research and development. It all startet with a casual observation. The privilege handling in computer systems did so far subject (keyword) Rights
1859 ## How The Idea Came To Be Askemos and BALL are two results of several years research and development. It all startet with a casual observation. The privilege handling in computer systems did so far label Summary
1863 ## Applying Principles In Practice The challenge was to create a sound model, which is simple to verify independently and *not* to invent anything anew. To keep the system within bounds, just inalie label Practice
2235 Once the protocol has consummated, changes are committed to permanent memory and additional messages may be sent out to trigger further processing and eventually a result will sent back to the client see also Booked signature
3063 Read [more on the front page's claim][1] "*for the future of due process and **finance***". [1]: ?_id=3057&_v=footnote description # A-Coin # Asset-based, fast & efficient alternative to Bitcoin > Alternative payment systems based on implementations compatible > with the principles of Askemos could be build and it had > several