Closed wendellpiez closed 4 years ago
reverse chronological order
Would one of you turn the contents of your last two emails into an issue?
Thanks, Dave
From: Piez, Wendell A. (Fed) wendell.piez@nist.gov Sent: Friday, May 22, 2020 4:26 PM To: Brian Ruf brian.ruf@gsa.gov; Waltermire, David A. (Fed) david.waltermire@nist.gov Subject: RE: Strong Use Case for Assigning UUID to ID Flags
Hi,
Would it be too confusing to permit two different flags, with different semantics? A @uuid value that would be expected to be “fresh” every time, and an @id flag that would provide an identifier for specific local operations where a more stable ID would be wanted and where “clashing” is a feature not a bug?
IDs are usually overloaded and indeed I think it’s impossible to prevent this. It is just too tempting and too useful to hand “identity” on an ID, even without thinking through the scoping issues (or more realistically, putting them off for another day).
I am thinking in particular of things like cross-references. I would hate for one version of a document to have the same resources list including citations as last year’s version, but require every citation and every pointer to it to have a new ID, because the document was “new” (different from last year’s albeit only updated).
Having said this I have no firm ideas of what the criteria should be for using one or the other, or where a schema would permit or require one, the other, or both. I do think that controls, resources and other targets of cross-referencing (assessment objectives etc.) have need for IDs that are stable across document versions.
Just a thought – Wendell
From: Brian Ruf - QQC-C brian.ruf@gsa.gov Sent: Friday, May 22, 2020 4:08 PM To: Waltermire, David A. (Fed) david.waltermire@nist.gov; Piez, Wendell A. (Fed) wendell.piez@nist.gov Subject: Strong Use Case for Assigning UUID to ID Flags
Hi Dave and Wendell,
A few weeks back (maybe longer - it's a blur), Dave mentioned the possibility of moving to UUIDs for nearly all ID fields (except possibly roles).
I just realized a challenge with a feature of the assessment-results model that this would solve.
We've included the ability to reflect previous snapshot-in-time assessments in the current model, which supports both continuous monitoring goals as well as a requirement for FedRAMP tools to be able to compare current results to historic results. (The current SAR requires the assessor to manually duplicate past assessment results into a certain column of the test case workbook).
The challenge is in ensuring that when a previous year's results are imported, there are no ID conflicts.
There are a few approaches for addressing this.
Tools could check-for and de-dupe IDs as part of the import process. While they should do this anyway, it would be great to minimize the number of conflicts.
Tools could adopt an ID assignment convention for findings that incorporates the ID from the parent results ID.
Tools could treat the scope of finding IDs as limited to that results assembly.
Every ID could have a UUID and we don't have to worry about it further.
In fact, I may go so far as to recommend that finding IDs are assigned UUID values in the FedRMAP SAR guide, to get out in front of this problem.
This is all just an FYI for now - but I am always open to your thoughts.
Best Regards, Brian J. Ruf, CISSP, CCSP, PMP | FedRAMP PMO
Based on Friday's conversation (myself, @wendellpiez and @david-waltermire-nist):
Change ID to UUID
party
location
resource
party-id
location-id
objective: A local definition of an assessment objective The same objective-id must be able to cite objective IDs in either the catalog, profile, SAP, or SAR. Since I believe this should remain an ID in the catalog, it needs to remain an ID everywhere.
objective-id
method: A local definition of an assessment method. The same method-id must be able to cite method IDs in either the catalog, profile, SAP, or SAR. Since I believe this should have an ID in the catalog (it doesn't now, but we discussed doing so recently), it needs to remain an ID everywhere.
method-id
id-ref: Points to a component, inventory-item, location, interview-party, or user. All are expected to be converted to UUID
test-method: Identifies a test method
test-step: Identifies a test step
schedule: Identifies a
include-activity: Activity to include in the assessment scope
exclude-activity: Prohibited assessment activity
results: a collection of assessment findings
finding: an individual assessment finding
observation: an individual observation, contributing to a finding.
risk: an identified risk related to a finding.
tracking-entry: An individual entry that logs an action taken toward remediation.
required-resource: a resource required to perform the remediation activities.
mitigating-factor: a mitigating factor
remediation: an individual remediation assembly
implementation-id: Points to implementation ID in SSP
source-id: Points to the source of a finding (such as tool, interviewed person, examined config)
activity-id
compare-to
@brianrufgsa This is cool, but I would like to stress there is a difference between an ID (whether or not a UUID) and a reference to an ID.
I do not believe any references to UUIDs need to be validated as UUIDs. This is because while they may take the lexical form of UUIDs, they are not actually UUIDs, for example, they are not unique. The constraint they introduce for validation is not a constraint over the format, but rather over whether the link target exists and is addressable unambiguously.
Anything that is actually a reference, not an identifier, should not be a candidate for UUID validation in my view. This includes @ref-id
as well as @component-id
. We could define these so that as links they would resolve to (only or as an option) @uuid
(or any) flag targets, validated as UUIDs. But this is different from making them UUIDs; it is merely defining the linking semantics.
Let me know if this makes (no) sense!
User Story:
On #538 we are tracking the higher-level issue of developing an idea of "control identity" over and above simply marking a control's
id
flag, for example taking account of catalog of origin. Similar "object identity" issues apply -- at least -- to parameters, resources and possibly other kinds of objects. Related to this, more lately, we are finding more requirements that suggest a need for a more robust ID (such as a UUID) that can be relied on to distinguish between two similar objects (rather than assert or represent their identity).Since the
id
flag is envisioned as "robust" for given referenda (controls, parameters etc) across document versions, it is not suitable for this. But the requirement could be addressed by permitting some objects to haveuuid
flags in addition toid
flags. This would permit a distinction to be made in operation between identifiers deployed with respect to different constraint sets (expectations of uniqueness over different scopes). It would also ease the problem of control or object identity by offering another (tight) point of comparison between like objects. UUID semantics would also be useful for some (many) applications to have available.Not only would this hook enable new functionalities (for example, in document or object comparison); it would also ease (not entirely remove) the issue of determining control identity for purposes of profile resolution (for example).
Discussion and experiment is probably called for. See background copied into the comment.
Goals:
uuid
flag to objects that need it. (See notes below for a start.) Determine where and what those objects are. Push forward such a feature.Dependencies:
This depends on issue usnistgov/metaschema#32.
See email exchange below copied into a comment.
Also, see #538. This does not resolve that Issue but it helps address it.
Acceptance Criteria
One of the following (check one check all):