Ace:TokenStore: Difference between revisions
From Adapt
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
*UNDER DEVELOPMENT* | *UNDER DEVELOPMENT* | ||
=Token Store Format= | |||
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 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. | ||
| Line 9: | Line 11: | ||
<pre> | <pre> | ||
[token-store] ::= [token-entry] | [token-store] | [token-store] ::= [token-entry] | [token-store] | ||
[token-entry] ::= [entry-header] [identifier-list] [newline] [proof-list] | [token-entry] ::= [entry-header] [identifier-list] [newline] [proof-list] [newline] | ||
[entry-header] ::= [digest-algorithm] [whitespace] [ims] [whitespace] [token-class] [whitespace] [round] [whitespace] [timestamp] [whitespace] [length] [whitespace] [newline] | [entry-header] ::= [digest-algorithm] [whitespace] [ims] [whitespace] [token-class] [whitespace] [round] [whitespace] [timestamp] [whitespace] [length] [whitespace] [newline] | ||
[identifier-list] ::= [file-identifier] [newline]| [identifier-list] | [identifier-list] ::= [file-identifier] [newline]| [identifier-list] | ||
| Line 25: | Line 27: | ||
* timestamp[1] - from IMS token result, timestamp token was issues, formated according to http://www.w3.org/TR/xmlschema-2/#dateTime-order | * timestamp[1] - from IMS token result, timestamp token was issues, formated according to http://www.w3.org/TR/xmlschema-2/#dateTime-order | ||
* 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. There may be multiple identifiers, on per line in case a file has multiple references. | ||
* digest - hex-encoded proof element digest, length is dictated by the specified digest algorithm. | * digest - hex-encoded proof element digest, length is dictated by the specified digest algorithm. | ||
Sample Entry | Sample Entry | ||
<pre> | <pre> | ||
SHA-256 ims.umiacs.umd.edu SHA-256-0 953886 2009-04-28T11:18:49.570-0400 | SHA-256 ims.umiacs.umd.edu SHA-256-0 953886 2009-04-28T11:18:49.570-0400 318 | ||
/fatcat.jpg | /fatcat.jpg | ||
http://www.myserver.com/fatcat.jpg | http://www.myserver.com/fatcat.jpg | ||
2770181de2b2a2ecf1de4c6c472401fcc8798f7542025764f94de1b99492e258:X | 2770181de2b2a2ecf1de4c6c472401fcc8798f7542025764f94de1b99492e258:X | ||
08c5fe43499eeaa3426d4b5c31524393b01209796014cab00c7591fe8497a49b:X | 08c5fe43499eeaa3426d4b5c31524393b01209796014cab00c7591fe8497a49b:X | ||
X:61c97995995935e60aa5bdeeff3a0ebb16cf1b694f03a0bfb991ac6bc15321d7 | X:61c97995995935e60aa5bdeeff3a0ebb16cf1b694f03a0bfb991ac6bc15321d7 | ||
aa91ea42b4e4b850275ce8d0ebcca74a1d4dde6f1731bcb61adc1bd8d7e8302b:X | aa91ea42b4e4b850275ce8d0ebcca74a1d4dde6f1731bcb61adc1bd8d7e8302b:X | ||
</pre> | </pre> | ||
The above sample shows a token generated using the SHA-256 hash algorithm, generated by the sha-256-0 token service running on the server ims.umiacs.umd.edu. The token was issued on 4-28-2009 as part of round 953886. It identifies an object with two locations, the unix file '/fatcat.jpg' and a url 'http://www.myserver.com/fatcat.jpg'. | The above sample shows a token generated using the SHA-256 hash algorithm, generated by the sha-256-0 token service running on the server ims.umiacs.umd.edu. The token was issued on 4-28-2009 as part of round 953886. It identifies an object with two locations, the unix file '/fatcat.jpg' and a url 'http://www.myserver.com/fatcat.jpg'. | ||
=Checkm Interop= | |||
* http://www.cdlib.org/uc3/docs/checkmspec.html | |||
Possible ways to integrate with checkm. | |||
# Require checkm filename match at least one identifier listed for a token | |||
# Create a checkm profile which allows ACE tokenstores to be labeled in a checkm manifest. | |||
'''Notes''' | |||
[1] Please note, the timestamp is just for metadata purposes and should not be trusted as it is not cryptographically linked to the proof. To assert the date of a token, you must show a link to a trusted witness value | [1] Please note, the timestamp is just for metadata purposes and should not be trusted as it is not cryptographically linked to the proof. To assert the date of a token, you must show a link to a trusted witness value | ||
Latest revision as of 17:55, 14 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*
Token Store Format
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-list] [newline] [entry-header] ::= [digest-algorithm] [whitespace] [ims] [whitespace] [token-class] [whitespace] [round] [whitespace] [timestamp] [whitespace] [length] [whitespace] [newline] [identifier-list] ::= [file-identifier] [newline]| [identifier-list] [proof-list] ::= [proof] [newline]| [proof-list] [proof] ::= [proof-element] | [proof-element] ':' [proof] [proof-element] ::= [digest] | X
- newline - carriage return \n
- whitespace - space ' ' or tab \t charactor (TODO, specify hex)
- 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.
- ims - ims server which issued the token.
- token-class - from IMS token result, name of token service on IMS which issued this token
- timestamp[1] - from IMS token result, timestamp token was issues, formated according to http://www.w3.org/TR/xmlschema-2/#dateTime-order
- 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. There may be multiple identifiers, on per line in case a file has multiple references.
- digest - hex-encoded proof element digest, length is dictated by the specified digest algorithm.
Sample Entry
SHA-256 ims.umiacs.umd.edu SHA-256-0 953886 2009-04-28T11:18:49.570-0400 318 /fatcat.jpg http://www.myserver.com/fatcat.jpg 2770181de2b2a2ecf1de4c6c472401fcc8798f7542025764f94de1b99492e258:X 08c5fe43499eeaa3426d4b5c31524393b01209796014cab00c7591fe8497a49b:X X:61c97995995935e60aa5bdeeff3a0ebb16cf1b694f03a0bfb991ac6bc15321d7 aa91ea42b4e4b850275ce8d0ebcca74a1d4dde6f1731bcb61adc1bd8d7e8302b:X
The above sample shows a token generated using the SHA-256 hash algorithm, generated by the sha-256-0 token service running on the server ims.umiacs.umd.edu. The token was issued on 4-28-2009 as part of round 953886. It identifies an object with two locations, the unix file '/fatcat.jpg' and a url 'http://www.myserver.com/fatcat.jpg'.
Checkm Interop
Possible ways to integrate with checkm.
- Require checkm filename match at least one identifier listed for a token
- Create a checkm profile which allows ACE tokenstores to be labeled in a checkm manifest.
Notes
[1] Please note, the timestamp is just for metadata purposes and should not be trusted as it is not cryptographically linked to the proof. To assert the date of a token, you must show a link to a trusted witness value
