Why doesn't CoSERV query use CoMID environment map as the environment selector?

[DhanusML]

CoSERV query uses either class-map or instance-id or group-id to identify the attester's environment. It cannot use a combination of these. However, the CoRIM specification does not enforce the global uniqueness of any of these identifiers individually, but the combination of these (the environment map) must be globally unique. So, a CoSERV query can only encode partial details of the environment, even when complete details of the environment might be available.

For example, it is possible for a CoRIM profile to have the instance-ids namespaced by class-ids. In that case, the desired result cannot be obtained directly from a CoSERV query, without further processing of the result set.

eg: Four valid attester environments, where the combination of class-map and instance-id uniquely identifies the environment

E1 = {
	class: {id: X},
	instance: A
}

E2 = {
	class: {id: X},
	instance: B
}

E3 = {
	class: {id: Y},
	instance: A
}

E4 = {
	class: {id: Y},
	instance: B
}

In this case, it might be possible to identify the attester's environment from the evidence. But the CoSERV query can only contain partial information. So, one has to make a choice of whether to use a class based selector or instance based selector and then filter out the result to obtain the desired values. Another approach would be to make both class based and instance based queries and then take an intersection of the results. If the environment selector had been a 'stateful environment selector', then the query could have included all the information available about the environment.

[paulhowardarm]

Thanks for raising this.

Would you say that this is largely a theoretical concern, or are you looking at a use case where such name collisions would be a genuine hazard in practice?

In the real world, I would expect all of these values to be highly entropic and unique. For instance-id and group-id, the risk would be for profiles that use tagged-bytes with no uniqueness guarantees. But things like tagged-uuid or tagged-ueid are more likely in practice - such as in the Arm CCA profile. Other profiles might use things like public keys or digests of keys.

The current query structure makes it quite easy to build a query to get artifacts for multiple instances, multiple groups or multiple classes. Not only that, but the semantic transformation to something like a SQL DB query is fairly straightforward (as we illustrate in the draft).

Remember also that the CoSERV endpoints themselves can be scoped such that they only need to worry about one kind of profile or one family of product, for example.

I'd like to keep the data model easy to use for the majority of realistic use cases. Using pure comid environment queries would make the typical use cases more fiddly, only to cater for marginal cases that might not occur in practice. So I lean towards leaving it as it is. However, if you are handling a genuine use case where identity collisions are proving to be a real problem, we can certainly reconsider this.

[DhanusML]

Would you say that this is largely a theoretical concern, or are you looking at a use case where such name collisions would be a genuine hazard in practice?

Yes, this is purely a theoretical concern. There are no consistency issues regarding this, because CoSERV query does not claim to have the ability to uniquely describe an environment. But the expectation would be that it could. So I feel like a comment in the draft about profiles where uniqueness cannot be achieved would be useful. Otherwise, this issue can be closed.

[thomas-fossati]

So I feel like a comment in the draft about profiles where uniqueness cannot be achieved would be useful.

👍

[paulhowardarm]

Thanks, both, that all makes sense. I will see about putting a PR into the draft.