Ace:TokenStore: Difference between revisions
From Adapt
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
[token-store] ::= [token-entry] | [token-store] | [token-store] ::= [token-entry] | [token-store] | ||
[token-entry] ::= [entry-header] [identifier-list] [newline] [proof] | [token-entry] ::= [entry-header] [identifier-list] [newline] [proof] | ||
[entry-header] ::= [ | [entry-header] ::= [digest-algorithm] [token-class] [round] [timestamp] [length] [newline] | ||
[identifier-list] ::= [file-identifier] [newline]| [identifier-list] | [identifier-list] ::= [file-identifier] [newline]| [identifier-list] | ||
[proof] ::= | [proof] ::= | ||
| Line 17: | Line 17: | ||
* newline - carriage return \n | * newline - carriage return \n | ||
* round - from IMS token result, round number in which this token was generated | * round - from IMS token result, round number in which this token was generated | ||
* | * digest-algorithm - from IMS token result, algorithm used to calculate hash tree. | ||
* class - from IMS token result | * token-class - from IMS token result, name of token service on IMS which issued this token | ||
* timestamp - from IMS token result | * timestamp - from IMS token result, timestamp token was issues | ||
* 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 | * 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. | * 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. | ||
| Line 25: | Line 25: | ||
Sample Entry | Sample Entry | ||
<pre> | <pre> | ||
SHA-256 SHA-256-0 953886 2009-04-28T11:18:49.570-0400 555 | |||
/fatcat.jpg | |||
http://www.myserver.com/fatcat.jpg | |||
</pre> | </pre> | ||
Please note, the timestamp is just for metadata purposes and should be considered trusted as it is not cryptographically linked to the proof. | |||
Revision as of 20:02, 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] ::= [digest-algorithm] [token-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
- digest-algorithm - from IMS token result, algorithm used to calculate hash tree.
- token-class - from IMS token result, name of token service on IMS which issued this token
- timestamp - from IMS token result, timestamp token was issues
- 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
SHA-256 SHA-256-0 953886 2009-04-28T11:18:49.570-0400 555 /fatcat.jpg http://www.myserver.com/fatcat.jpg
Please note, the timestamp is just for metadata purposes and should be considered trusted as it is not cryptographically linked to the proof.
