Personal tools

Ace:Ace IMS System

From Adapt

Revision as of 19:22, 9 September 2008 by Toaster (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

---+IMS Documentation

The ACE Integrity Management Server is responsible for aggregating token requests into rounds. For each of these rounds, a merkel tree of all hashes plus previous round is constructed. The IMS stores the root hash from this tree, called the Cryptographic Summary Information (CSI). From this tree, the client receives a proof containing all necessary tree hashes to regenerate the CSI (not including it's own leaf of course)

Requesting Hashes

The IMS provides three ways to register hashes.

  * Asynchronous.  A clients deposits tokens on the IMS. These requests are stored until the current round ends, at which time a set list or response tokens is generated and made available to the client. As this is out-of-band, the client is required to call back to the IMS to retrieve issued tokens. To do this, a client is given a receipt upon that can be used to pick up tokens after they have been generated.
  * Synchronous. A client sends a request and causes the currently open round to conclude. The round is constructed using any previous async requests and tokens supplied in the current request.
  * Link. A client may insert round hash/CSI directly into the IMS. This will close any previous round, generate certificates, insert the supplied linking hash and start a new round. This is designed to be used by sites requiring massive throughput.

Documentation

  * Java API
  * WebService calls
  * Internal Structure