Ace:TokenStore: Difference between revisions
From Adapt
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
*UNDER DEVELOPMENT* | *UNDER DEVELOPMENT* | ||
The token store | The token store serves two purposes, first it stores a list of tokens which can used to certify the integrity of an object. Second it stores linking information that links some external identifier to a token. While the token issued by an IMS contains a name used by token requesters in order to identify token responses, this may not be adequate to identify token/file pairing as files move between systems. | ||
The proposed format is based on a modification of the arc file format. | |||
<pre> | |||
[token-store] ::= [token-entry] | [token-store] | |||
[token-entry] ::= [entry-header] [identifier-list] [newline] [proof] | |||
[entry-header] ::= [type] [class] [round] [timestamp] [length] [newline] | |||
[identifier-list] ::= [file-identifier] [newline]| [identifier-list] | |||
[proof] ::= | |||
</pre> | |||
* newline - carriage return \n | |||
* round - from IMS token result, round number in which this token was generated | |||
* type - from IMS token result, | |||
* class - from IMS token result | |||
* timestamp - from IMS token result | |||
* length - length of entry starting after newline containing identifiers and proof. Users should be able to seek(length) and be positioned at the next token-entry | |||
* file identifier - url, unix pathname, windows structure, PURL, which an external system may refer to this file as. When packaging token stores for inclusion in a zip or tar-like package, the identifier should the path to the file relative to the token store. | |||
Sample Entry | |||
<pre> | |||
</pre> | |||
Revision as of 19:41, 8 December 2010
Several versions of the ACE token store format exist to allow the export and interchange of tokens between the ACE Audit Manager and command line tools.
- UNDER DEVELOPMENT*
The token store serves two purposes, first it stores a list of tokens which can used to certify the integrity of an object. Second it stores linking information that links some external identifier to a token. While the token issued by an IMS contains a name used by token requesters in order to identify token responses, this may not be adequate to identify token/file pairing as files move between systems.
The proposed format is based on a modification of the arc file format.
[token-store] ::= [token-entry] | [token-store] [token-entry] ::= [entry-header] [identifier-list] [newline] [proof] [entry-header] ::= [type] [class] [round] [timestamp] [length] [newline] [identifier-list] ::= [file-identifier] [newline]| [identifier-list] [proof] ::=
- newline - carriage return \n
- round - from IMS token result, round number in which this token was generated
- type - from IMS token result,
- class - from IMS token result
- timestamp - from IMS token result
- length - length of entry starting after newline containing identifiers and proof. Users should be able to seek(length) and be positioned at the next token-entry
- file identifier - url, unix pathname, windows structure, PURL, which an external system may refer to this file as. When packaging token stores for inclusion in a zip or tar-like package, the identifier should the path to the file relative to the token store.
Sample Entry
