Issue 14968: We currently do not require any particular time or event that the authentication be done (rms-ftf) Source: TethersEnd Consulting (Mr. Daryll Prescott, drp(at)tethersend.com) Nature: Uncategorized Issue Severity: Summary: We need to require that it be done on capture. Should we require other events like retrieval? (This would get into the business process of the organization Resolution: Revised Text: Actions taken: January 14, 2010: received issue Discussion: End of Annotations:===== s is issue # 14968 drp@tethersend.com We currently do not require any particular time or event that the authentication be done We need to require that it be done on capture. Should we require other events like retrieval? (This would get into the business process of the organization From: "PrescottD" To: "'RMS-FTF@omg.org'" Subject: Issue 14968: Date: Thu, 4 Mar 2010 18:46:12 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-03-05_01:2010-02-06,2010-03-04,2010-03-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003040245 "We currently do not require any particular time or event that the authentication be done" IN 14133 I address this issue but will restate it here. Authentication should be mandatory at the event of set aside. Other events that warrant authentication 1. A copy of a record is requested. Authentication is necessary to prove the record that is going to be copied for a requestor has not been corrupted, made incomplete, or is now a forgery. 2. Update of authentication method. When an authentication method is updated, the record must be authenticated (see 1 above for reasons) and then the new authentication method applied. 3. Transfer. Before make a transfer, records should be authenticated (see 1 above for reasons). The receiver should get the authentication method n order to test the records before accessioning them, or rather accepting them because this is a change in legal custody for preservation purposes. 4. Move. Although 44 U.S.C., and 36 C.F.R. indicate records going from an agency to a Federal Records Center (FRC) are a "transfer" in point of fact, literally, this is a move function. The reason it is a move function and not a transfer function is because the records remain under the legal authority of the agency not the Archives. In point the only thing that changes in a move from the agency to the FRC is the recordkeeper changes. If the records are physically moved probably don't need to authenticate them. If not, then authentication needs to be done. In any event, the authentication method must be shared be the receiver in the move function. The receiver will then be performing the authentication if a copy of a record is requested (See 1 above). 5. Donation. The records need to be authenticated before they are given to the donated organization. The authentication method should be provided to the receiving organization. 6. Change in provenance. If the records remain with the recordkeeper then no. If the records are going to be moved, that is physically moved, then the type of move will determine if authentication is necessary. If the environments the records are in are physical being moved, probably not, if they are being streamed, or copied, or some such then yes. The authentication method must go with the records to the new organization of provenance. 7. Destruction. I am not sure records need to be authenticated before they are destroyed, except that you might want to know your records are authentic and haven't been tampered with, this would trigger an audit or security review - The last might be up for discussion. From: "Larry L. Johnson" To: "'RMS-FTF@omg.org'" Subject: RE: Issue 14968: We currently do not require any particular time or event that the authentication be done Date: Sun, 7 Mar 2010 11:11:36 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acq79Q/NsWAuI9eBRbWWKAlO1IPZfQCGottA X-ACL-Warn: { X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - capricorn.lunarpages.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - TethersEnd.com X-Source: X-Source-Args: X-Source-Dir: Under the principle of not dictating business process: I balk at requiring authentication at set-aside, but could be convinced. But the laundry list of events is unsettling. OTOH... most of the events are fundamental operations documented in our DispositionInstruction model which could make a case for it. Daryll has asserted that Authentication is one of the primary distinctions between Records Management and Document Management. Perhaps we do need to make Authentication part of the behavior of our fundamental operations. I think the below list needs to be distilled to minimalistic fundamentals if we are going to take this course. Regards, Larry -------------------------------------------------------------------------------- From: PrescottD [mailto:drp@tethersend.com] Sent: Thursday, March 04, 2010 6:46 PM To: 'RMS-FTF@omg.org' Subject: Issue 14968: "We currently do not require any particular time or event that the authentication be done" IN 14133 I address this issue but will restate it here. Authentication should be mandatory at the event of set aside. Other events that warrant authentication 1. A copy of a record is requested. Authentication is necessary to prove the record that is going to be copied for a requestor has not been corrupted, made incomplete, or is now a forgery. 2. Update of authentication method. When an authentication method is updated, the record must be authenticated (see 1 above for reasons) and then the new authentication method applied. 3. Transfer. Before make a transfer, records should be authenticated (see 1 above for reasons). The receiver should get the authentication method n order to test the records before accessioning them, or rather accepting them because this is a change in legal custody for preservation purposes. 4. Move. Although 44 U.S.C., and 36 C.F.R. indicate records going from an agency to a Federal Records Center (FRC) are a "transfer" in point of fact, literally, this is a move function. The reason it is a move function and not a transfer function is because the records remain under the legal authority of the agency not the Archives. In point the only thing that changes in a move from the agency to the FRC is the recordkeeper changes. If the records are physically moved probably don't need to authenticate them. If not, then authentication needs to be done. In any event, the authentication method must be shared be the receiver in the move function. The receiver will then be performing the authentication if a copy of a record is requested (See 1 above). 5. Donation. The records need to be authenticated before they are given to the donated organization. The authentication method should be provided to the receiving organization. 6. Change in provenance. If the records remain with the recordkeeper then no. If the records are going to be moved, that is physically moved, then the type of move will determine if authentication is necessary. If the environments the records are in are physical being moved, probably not, if they are being streamed, or copied, or some such then yes. The authentication method must go with the records to the new organization of provenance. 7. Destruction. I am not sure records need to be authenticated before they are destroyed, except that you might want to know your records are authentic and haven't been tampered with, this would trigger an audit or security review - The last might be up for discussion.