Ace:Ace IMS System - Revision history

Toaster: Ace IMS System moved to Ace:Ace IMS System

2008-09-10T17:53:23Z

Ace IMS System moved to Ace:Ace IMS System

← Older revision	Revision as of 17:53, 10 September 2008
(No difference)

Toaster at 19:22, 9 September 2008

2008-09-09T19:22:53Z

← Older revision		Revision as of 19:22, 9 September 2008
Line 1:		Line 1:

	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)		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)

Line 6:		Line 5:
	The IMS provides three ways to register 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.		* 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.		* 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.		* 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==		==Documentation==

	* [[ACE Ims API\|Java API]]		* [[ACE Ims API\|Java API]]
	* [[ACE Ims Webservice\|WebService calls]]		* [[ACE Ims Webservice\|WebService calls]]
	* Internal Structure		* Internal Structure

Toaster at 19:22, 9 September 2008

2008-09-09T19:22:36Z

← Older revision		Revision as of 19:22, 9 September 2008
Line 1:		Line 1:
	~~---+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)		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)

Toaster at 19:22, 9 September 2008

2008-09-09T19:22:18Z

New page

---+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==

* [[ACE Ims API|Java API]]
* [[ACE Ims Webservice|WebService calls]]
* Internal Structure