This repository is obsolete. Current work is happening here
- Authors: Sam Smith -- email is optional
- Deliverable Type: Spec - Technical
- Status: PROPOSED
- Since: 2021-02-15
- Status Note: (explanation of current status)
- Supersedes: (link to anything this ToIP Deliverable supersedes)
- Start Date: 2020-12-07
- Tags: #spec, #tswg, #acdc
The purpose of the Authentic Chained Data Container (ACDC) Task Force is to draft a TSS (ToIP Standard Specification) that defines the standard requirements for the semantics of Authentic Provenance Chaining of Authentic Data Containers. This semantics include both source provenance and authorization provenance or delegation. The hypothesis is that the W3C Verifiable Credential standard may be expanded to serve as an Authentic Data Container (ADC) and that the semantics of a VC may be expanded to support an authentic provenance chains (APC) as a super semantic. This may be further expanded to support both a source provenance sub-semantic and a delegated authorization sub-semantic.
Todo
Briefly describe the scope of this document – how it presents the architecture of this particular enabler. Include an explanation of how this architecture relates to Organization Name activity. If it adds clarity, also describe what is not in the scope of this architecture. DELETE THIS COMMENT
TodoThe policy for reference lists is:
1. 'ORG_NAME' documents listed should have at least one approved version – draft-only docs should not be referenced.
Exception exists for documents that will be approved with or after the referenced doc is approved (may be
part of same enabler package). In short – approved docs should not reference unapproved docs.
2. When a reference is made to an 'ORG_NAME' specification, then Organization Name with the TM symbol (™) should
be used in the description.
3. The name + version (no date) for 'ORG_NAME' specifications are generally sufficient – dates should be used only
if there is a specific reason to limit the usage.
4. For references to WAP Forum docs, dates should not be included as DID's for the old WAP Forum specifications
are enough and the reference description should refer to WAP Forum™.
5. References to other affiliate docs should similarly provide sufficient information to uniquely determine the
needed document and should provide the appropriate source information.
6. The URL for 'ORG_NAME' material (new 'ORG_NAME' and affiliate) should always be http://www.org_name.org (an exception is Registry that is reached through http://www.org_name.org/tech/)
Models to use
[REFLABEL] <General Model> "Ref Title", Ref information (source, date, id), URL:http//<ref-source>/
['ORG_NAME'DOC] <'ORG_NAME' Model> "'ORG_NAME' Document Title",{ Version x.y,} Organization Name™, 'ORG_NAME' <docname>{ <version>},
URL:http//www.org_name.org/
If there are no entries in the table – enter ‘none’ to be clear.
ToDo
| [RFC2119] | "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997, URL:http://www.ietf.org/rfc/rfc2119.txt |
| [RFC4234] | "Augmented BNF for Syntax Specifications: ABNF", D. Crocker, Ed., P. Overell, October 2005, URL:http://www.ietf.org/rfc/rfc4234.txt |
| [SCRRULES] | "SCR Rules and Procedures", Organization Name™, 'ORG_NAME'-ORG-SCR_Rules_and_Procedures, URL:http://www.org_name.org/ |
Add/Remove reference rows as needed - DELETE This Row
Check the version of the Dictionary you are using and update the reference below. Delete the ['ORG_NAME'DICT] entry if
the dictionary is not used. In general, use the latest available version unless seeking alignment with an
existing set of specifications.
ToDo
| ['ORG_NAME'DICT] | "Dictionary for 'ORG_NAME' Specifications", Version x.y, Organization Name™, 'ORG_NAME'-ORG-Dictionary-Vx_y, URL:http://www.org_name.org/ |
Add/Remove references as needed - DELETE This Row
ToDoThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
All sections and appendixes, except "Scope" and "Introduction", are normative, unless they are explicitly indicated to be informative.
If needed, describe or declare using appropriate normative references the additional conventions that are used. DELETE THIS COMMENT
Add definitions in new rows of the following table as needed. The following examples show how dictionary references should be made
as well as locally defined terms. This table should be maintained in sorted alphabetic order based on the labels of the terms.
Examples:
Entity Use definition #1 from ['ORG_NAME'DICT]
Interactive Service Use definition from ['ORG_NAME'DICT]
Local Term The definition description would be presented directly
DELETE THIS COMMENT
| LWM2M Bootstrap Server Account | LWM2M Security Object Instance with Bootstrap Server Resource true |
| LWM2M Server Account | LWM2M Security Object Instance with Bootstrap Server Resource false and associated LWM2M Server Object Instance |
Add/Remove definition rows as needed - DELETE This Row
Kindly consult ['ORG_NAME'DICT] for more definitions used in this document.
Add abbreviations as needed. No special notation should be made regarding terms copied from the Dictionary.
The list should be maintained in alphabetic order. DELETE This Row
| 'ORG_NAME' | Organization Name |
From a market perspective...
* What can you do with this specification?
* What problem does this solve?
* How can this specification be applied?
* Consider the target audience and provide deployment examples as possible.
ToDo
This section provides a high level, concise and informative description of the main functionality supported in the initial version of the specification. The description should be brief, target length should be a few paragraphs.
When the enabler or reference release is finished, this description should be aligned with the final functionality.
ToDo
This section should be included for each new major or minor version of the specification.
It should provide a high level, concise and informative description of the new or modified functionality introduced in this version of the specification, compared to the previous version. The description should be brief, target length should be a few paragraphs. When the enabler or reference release is finished, this description should be aligned with the final functionality differences.
ToDo
This section should be included for each new service release of the specification. It should describe at a high level the main changes made to the specification compared to the previous version. The description should be brief, target length should be one paragraph.
ToDo
Sections for the normative specification text. Fill in as needed. The following validates the styles used for the headers. DELETE THIS COMMENT
(Add text here.)
(Add text here.)
(Add text here.)
- Gating Criteria requirement
- URL to be defined.
| Item | Function | Reference |
|---|---|---|
| Row 1 | Grid 1,1 data | Grid 1,2 data |
| Row 2 | Grid 2,1 data | Grid 2,2 data |
- Gating Criteria
- URL to be defined| Reference | Date | Description |
|---|---|---|
| n/a | n/a | No prior version |
The notation used in this appendix is specified in [SCRRULES].Add link
The following is an optional model of a set of SCR tables. DELETE THIS COMMENT
| Item | Function | Reference | Requirement |
|---|---|---|---|
| XYZ-C-001-M | Something mandatory | Section x.y | (XYZ-C-004-O OR XYZ-C-003-M) AND XYZ-C-002-O |
| XYZ-C-002-O | Something optional | Section x.y | |
| XYZ-C-003-M | Dependencies on ZYX | Section x.y | ZYX:MCF |
| XYZ-C-004-O | Dependencies on ZYX | Section x.y | ZYX:OCF |
| Item | Function | Reference | Requirement |
|---|---|---|---|
| XYZ-S-001-M | Something mandatory | Section x.y | XYZ-S-004-O OR XYZ-S-002-O OR XYZ-S-003-M |
| XYZ-S-002-O | Something optional | Section x.y | |
| XYZ-S-003-M | Dependencies on ZYX | Section x.y | ZYX:MCF |
| XYZ-S-004-O | Dependencies on ZYX | Section x.y | ZYX:OCF |