The Trust and Identity Document Repository is found here.
Internet2 Trust and Identity's document stewardship process formalizes the management of documents as they are drafted, proposed, vetted, and approved for use, and published for open access. It is intended to address any documents that are products of work sponsored by Trust and Identity or one of its community advisory groups. Examples of such products include:
Note that any software documentation for developers and end users that is related to a specific release of the software, and is distributed with software, is vetted as part of the quality assurance process for the software release and is out of scope for Trust and Identity Document Stewardship. Documents describing software lifecycle management, overall system architecture, etc., however, are in scope.
CACTI (Community Architecture Committee for Trust and Identity) is charged with oversight of the document stewardship processes.
The foundational document establishing and governing the Document Stewardship process is found here (click on the link to the PDF).
Submissions to the Document Repository must be approved by a Sponsor. The authorized Sponsors are::
In the case of a document or report sponsored by InCommon TAC or by CTAB, the document is only considered final and ready to be added to the document repository after approval by the sponsoring body and also by InCommon Steering. This is because InCommon TAC and CTAB are advisory to InCommon Steering.
For a document that will eventually go into the repository, it is recommended to get a document ID and format the document with the needed components during the time that you are developing the document, prior to it being finalized. (You will submit the document to go into the repository later when it has been finalized and approved.)
To prepare a document to go into the Document Repository:
1. The cover page should include this info below, though only the Title, copyright and the licensing info are strictly required
Authors provide authors names in all cases and their ORCID where possible - e.g.,
David Walker https://orcid.org/0000-0003-2540-0644
Note: You obtain the Repository ID and Persistent URL from the librarian. The authorized Sponsors are listed in Trust and Identity Document Stewardship. See Document Repository Metadata Element Definitions for more information.
https://share-my-id.orcid.org/ is a useful tool for collecting ORCIDs for a group of authors.
2. This copyright and licensing info must be on the first page of the document (where <year> is the current year).
© <year> Internet2
This work is licensed under a Creative Commons Attribution 4.0 International License.
See example HERE
These steps must be completed before a document is ready to go into the repository.
Once these steps are done, send the document to firstname.lastname@example.org in both of these formats:
text (preferred) or HTML
PDF, unless that is not appropriate for the specific document
You may also submit the revisable (e.g., MS Word) document that was used to create the PDF/text/HTML documents for inclusion in the Development Location metadata element. (See below.) This is recommended if future revisions may be made.
At this time, you may also propose the following metadata elements to the librarian, as appropriate:
See Document Repository Metadata Element Definitions for more information about these optional items.
After you submit the document in two formats of the document to the librarian, the librarian will attach them to the corresponding page in the repository and those will become the authoritative copies.
Here is an example of a repository page that has the attachment of the authoritative doc.
An updated document is a new document with its own new row in the document repository, even though much of its content may be the same as the original document.
Just as with the original document, the update is subject to review and approval, as specified by its sponsor.
There are a few things to note:
The "Deprecated" field of a document's repository metadata page will be set to "yes" when its content should no longer be trusted to reflect current practice or thinking on its topic. As noted above, this occurs when a document is superseded by another, but it can also occur without a superseding document
Here is an example of a document that is an update to an earlier document in the repository. http://doi.org/10.26869/TI.105.2
Note the change log at the end of the document, which is a helpful feature to add to any such document. http://doi.org/10.26869/TI.105.2
In order to maintain a historical record, documents are never removed from the repository, unless they were placed in error. Documents that no longer have anything other than historical interest are deprecated.
Here is an example of a deprecated document http://doi.org/10.26869/TI.105.1
Typically, references to documents in the repository should link to the documents' metadata pages via their DOI URL (e.g., http://doi.org/10.26869/TI.105.1).
There are times, however, when a document should be presented in a manner that is consistent with the context of the referring page, or when multiple references to the document make link maintenance difficult as new versions of the document are published. This alternative presentation is usually accomplished by creating a copy of the document's text, images, etc. within the platform used to present the referring page (e.g., WordPress for http://www.incommon.org).
See this example.
When a document in the repository is also presented on a webpage, the content "owner" (note July 1, 2019: we may want to link from here a list of content owners and these pages) of the referring page should:
Working group chair and flywheel guidelines with regard to the Document Stewardship process are found here.
Please contact David Walker <email@example.com> or Emily Eisbruch <firstname.lastname@example.org> for more information.
Document Stewardship Process - Framework Docs
Trust and Identity Document Repository Index
Blog on Document Stewardship (Sept. 2018)
Community Review of the Doc Stewardship plans
Guidelines for Trust and Identity Working Group Chairs and Flywheels