Ace:Ace IMS System: Difference between revisions
From Adapt
No edit summary |
m (Ace IMS System moved to Ace:Ace IMS System) |
||
| (One intermediate revision by the same user not shown) | |||
| 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. | |||
* 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== | ==Documentation== | ||
* [[ACE Ims API|Java API]] | |||
* [[ACE Ims Webservice|WebService calls]] | |||
* Internal Structure | |||
Latest revision as of 17:53, 10 September 2008
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
