Need to define the namespace scoping for Environment

[yogeshbdeshpande]

An Attester can be from multiple vendors though, the Elements of Class Identifier are Optional Elements like
Vendor, Model, Class-ID etc.

This leaves the scope for a user to only add a Model, which could collide with other Vendor Models.

Need to define the usage of Class Identifier that should be unique across Multiple Vendors and Multiple Attesters belonging to the same Vendor. Specification needs some clarification about usage on Class Identifier, been how to mint it as a Unique Identifier!

[andrew-draper]

My assumption is that the attester and/or the evidence collection protocol defines the environment-map. During ACS initialization the evidence entries with this environment map are added to the ACS.
CoMID triples intending to interact with this evidence should use the same environment-map as appears in evidence.
CoMID triples can add Endorsements with a new environment-map and can select a unique value for the vendor field if they want a new namespace.
We have added a free-format instance field which can be used to identify different device instances, is any more work needed to close this issue?

[nedmsmith]

My assumption is that the attester and/or the evidence collection protocol defines the environment-map.

Do you mean "the attester and/or the evidence collection protocol developer defines the environment-map scope?

The consideration is that these values have to be defined at manufacturing time so that Ref Vals use the same environment identifiers. If the identifiers are not globally unique values, there is potential for collision from an unrelated supplier which could confuse verifiers (unless there is some other scoping context).

The other issues having to do with groups potentially are impacted because an environment-map within a group could have non-globally-unique identifiers due to the grouping context (which can be used to safely limit scope).

is any more work needed to close this issue?

Requiring use of instance-id where an RVP is only prepared to use class-map seems onerous. Even if a device asserts an instance name, the matching rules allow subset matching. RVP-A using class-map (without instance-id/group-id) could be confused by an RVP-B that uses the same class-map value. If RVP-B is authorized based on a Verifier trust anchor, the Verifier still doesn't know which set of RVs to apply.

If the schema constrains the environment-map values to be globally unique (in some fashion) then the possibility of environment-map collision goes away.

[nedmsmith]

Environment includes both environment-map and stateful-environment-record as various triples may use both to identify Target Environments (TE).

The existing prose for environment-map doesn't explicitly state namespace scope expectations. In the case of instance-id the types of instance values suggest global namespace scope (as a $crypto-key-type-choice implies cryptographic identifiers have global uniqueness. class-id forms include uuid and oid which also imply global scope. However, it also supports int and bytes variants that don't necessarily imply global scope. Additionally, use of class-id is optional leaving various combinations of 'vendor', 'model', 'layer', 'index' that have no implied scoping.

If Environments are required to have global scope, then it is impossible (absent malicious intent) for environment-A to be confused with environment-B due to name collision. If it is impractical to expect environments will have global scope, the rules for local scoping need to be defined.

At one point, there was wording in a PR that suggested namespace scope could be localized by placing an environment inside a grouping construct such as a 'domain' or 'bundle'. This may be a reasonable approach to support locally scoped namespaces, but is there a use case that motivates it?

If the spec mandates environments to have global scope, and there happen to be namespace collisions (e.g.: vendor-X and vendor-Y choose the same vendor string "Solutions-R-us" then Verifiers may give incorrect results unknowingly (as there is not test that can be applied to determine if a combination of attributes is indeed globally unique and I presume CoRIM doesn't intended to require use of a registry that guarantees global uniqueness.

If environments are presumed globally unique, then grouping for the purpose of making something become globally unique doesn't make sense. This may simplify the grouping context discussions.

[yogeshbdeshpande]

part of the requirement addressed via currently open #227

[nedmsmith]

fixed by #227