linked-tags rel type 'comid-supplements' semantics

[nedmsmith]

The 'comid-supplements' relaltionship type, when used for CoMID to CoSWID, may need to define matching criteria. In comid to comid the comid tag MUST? have a claim with an element-name that matches the element-name of the linked tag. In comid the module-name includes element-name making this matching easy. In coswid there isn't a module-name. Instead, the concise-swid-tag has a set of attributes that need to be mapped to element-name to form the matching criteria.

[nedmsmith]

The other comid relationship types seems to not make sense for comid to coswid linking.

[nedmsmith]

If coswid tag-id can describe a single software item, then linking by tag-id only is sufficient. But if there could be multiple versions / packages referenced by the same tag-id. Then possibly more specific 'matching' semantics may be needed. We think mapping attributes of element-name to attributes in swid could solve this problem.

[thomas-fossati]

This is the certification use case that Yogesh has brought up: certification (e.g., Common Criteria, PSACertified, etc.) metadata associated with a HW module (CoMID) as well as SW module (CoSWID).

[thomas-fossati]

There seems to be agreement at this point in time that the certification use case can be solved by other means, for example introducing a "concise certification tag (concert)" - Henk's mint - to the $concise-tag-type-choice.

I don't remember whether we also concluded that the supplement semantics from CoMID to CoSWID is not supported by enough concrete use cases to be worth adding at this point. @nedmsmith @yogeshbdeshpande ?

[yogeshbdeshpande]

@thomas-fossati : We agreed to the extent as below: 1) As the CoMID to CoSWID supplements does not have a clean solution as far as Certification so as we better remove the use case from the specification. As far as I recollect no other use case requires the cross linking via supplements. 2) We can model the use case by minting two tag, one CoMID that links via Supplements to root CoMID which it certifies. Other is a new CoSWID tag which supplements the root CoSWID tag. The created CoMID tag and new CoSWID tag may contain identical claim set. 3) Follow a common con-cert-tag as suggested above. This may be adapted for specific profiles of standard, as this is not part of the common specifications.

[thomas-fossati]

1. As far as I recollect no other use case requires the cross linking via supplements.

So we could drop it altogether?

[yogeshbdeshpande]

Since the relationship is common between CoMID to CoM/SW/ID, it only needs an edit in the Endorsement Architecture document, unless I am missing something!

[nedmsmith]

The CoMID to CoSWID supplements case can be removed from the TCG spec.

[yogeshbdeshpande]

Thanks and Agree!, Once the edit is done, we can close this issue!

[nedmsmith]

Removed as of revision 15.

[nedmsmith]

Closed issue based on comments.