Adding 'uuid' flag to objects in addition to 'id' flag?

[wendellpiez]

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 have uuid flags in addition to id 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:

• Consider adding a 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.
• Update specs, documents and examples to demonstrate such usage.

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):

• Issues have been agreed on and created, reflecting the goals and any spinoff goals we discover
• Or a (quick/dirty) PR is submitted that adds this flag, as needed, with documentation, and builds successfully
• Or, after discussion it is decided not to act on this idea

[wendellpiez]

History

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.

1. 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.

2. Tools could adopt an ID assignment convention for findings that incorporates the ID from the parent results ID.

3. Tools could treat the scope of finding IDs as limited to that results assembly.

4. 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

---

[brian-ruf]

Based on Friday's conversation (myself, @wendellpiez and @david-waltermire-nist):

Guidelines

• Public domain / re-use is ID. Everything else is UUID.
• URI Fragments will be allowed to point to resources using their UUID value.
• ID references:
  • The names should be modified to reflect they are pointing to UUIDs, in other words party-id becomes party-uuid
  • The datatype for the party-uuid flag will be set to UUID
• Role IDs will be prescribed by framework authors (NIST, FedRAMP, etc.)
• Locally defined Role IDs will be some prefix followed by a tool-defined value, such as:
  x_Value (enforced through metadata constraints)

Root Element

Change ID to UUID

Metadata & Backmatter

Keep as ID

• role

Change ID to UUID

• party

• location

• resource

• party-id

• location-id

---

SSP

• capability-id: Exists in meatashcema, but does not appear to be used anywhere. I did not look at component model. This may be related to that.

Keep as ID

• information-type
• leveraged-authorization
• control-id - keep as ID (points to profile/catalog controls)
• statement-id - keep as ID (points to profile/catalog statements)

Change ID to UUID

• diagram
• user
• component
• service
• protocol
• interconnection
• inventory-item
• implemented-requirement
• component-id

Add to Metaschema:

• Add UUID to statement
• Add UUID to by-component

---

ASSESSMENT LAYERS

Keep as 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

Change ID to UUID

• 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

[wendellpiez]

@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!