I think that "who" is a little misleading.
The problem with listing group members is that you end up with an ACL system (identity based access control, for those who like the fancy terms). This is only manageable if the data controller (and this is likely to be the analyst or administrator configuring the IDS) knows all the identities involved. In practise, whoever is defining that label will be considering properties of the data and how those compare to (perceived, desirable) properties of the audience.
By way of a concrete example, a label might look like this, in JSON:
{
"policy": "Surevine",
"classification": "tlp:amber",
"jurisdiction": ["eu", "safe harbour"],
"anonymize": true,
"proposal": true
}
Note that the classification here is using TLP, but you're right in that TLP is pretty useless beyond giving a human a high-level indicator of sensitivity. We can create rules for how to render this as a textual string, but the problem is that it's pretty hard to translate between policies without having to have a lot more cooperation than is reasonable to expect.
In an X.841 style, still represented in a made-up JSON format, it might look more like this - I apologise for the OIDs involved; I really do:
{
"policy_id": "1.2.826.0.1.6726289.0.1",
"classification": 12,
"categories": [
{
"type": "permissive",
"id": "1.2.826.0.1.6726289.0.1.1",
"values": [0, 1]
},
{
"type": "restrictive",
"id": "1.2.826.0.1.6726289.0.1.2",
"values": [0]
},
{
"type": "informative",
"id": "1.2.826.0.1.6726289.0.1.3",
"values": [0]
}
]
}
I think it's best left as an exercise for the reader on how the clearances might look, but it's important to state that while I've made up the JSON syntax itself, the data within it (the use of those OIDs, "permissive" and "restrictive" category types, etc) are all very well established, and well understood.
This JSON syntax could (and other syntaxes can be) used with this policy (here in XML-SPIF format; that's an XML variant of SDN.801c's ASN.1 SPIF format):
<SPIF xmlns="http://www.xmlspif.org/spif"
creationDate="2015-09-24 09:23:00"
rbacId="2.16.840.1.101.2.1.8.3"
privilegeId="2.16.840.1.101.2.1.8.3"
originatorDN="cn=Dave Cridland,o=Survine,c=GB"
schemaVersion="2.0"
keyIdentifier="">
<defaultSecurityPolicyId name="Default" id="1.1"/>
<securityPolicyId name="TLPX" id="1.2.826.0.1.6726289.0.1"/>
<equivalentPolicies>
<equivalentPolicy name="TLP" id="1.2.826.0.1.6726289.0.2"/>
</equivalentPolicies>
<securityClassifications>
<securityClassification name="WHITE" lacv="10" hierarchy="1">
<equivalentClassification policyRef="TLP" lacv="10" applied="both"/>
</securityClassification>
<securityClassification name="GREEN" lacv="11" hierarchy="2">
<equivalentClassification policyRef="TLP" lacv="11" applied="both"/>
</securityClassification>
<securityClassification name="AMBER" lacv="12" hierarchy="3">
<equivalentClassification policyRef="TLP" lacv="12" applied="both"/>
</securityClassification>
<securityClassification name="RED" lacv="13" hierarchy="4">
<equivalentClassification policyRef="TLP" lacv="13" applied="both"/>
</securityClassification>
<markingQualifier>
<qualifier markingQualifier="TLP:" qualifierCode="prefix"/>
</markingQualifier>
</securityClassifications>
<securityCategoryTagSets>
<securityCategoryTagSet name="Jurisdiction" id="1.2.826.0.1.6726289.0.1.1">
<securityCategoryTag tagType="permissive">
<tagCategory name="EU" lacv="0"/>
<tagCategory name="SafeHarbour" lacv="1"/>
<tagCategory name="US" lacv="2"/>
<markingQualifier>
<qualifier markingQualifier="," qualifierCode="separator"/>
<qualifier markingQualifier="J:" qualifierCode="prefix"/>
</markingQualifier>
</securityCategoryTag>
</securityCategoryTagSet>
<securityCategoryTagSet name="Mandatory Data Manipulation" id="1.2.826.0.1.6726289.0.1.2">
<securityCategoryTag tagType="restrictive">
<tagCategory name="Anonymize" lacv="0"/>
<tagCategory name="Aggregate" lacv="1"/>
<markingQualifier>
<qualifier markingQualifier="," qualifierCode="separator"/>
<qualifier markingQualifier="MUST:" qualifierCode="prefix"/>
</markingQualifier>
</securityCategoryTag>
</securityCategoryTagSet>
<securityCategoryTagSet name="Data Status" id="1.2.826.0.1.6726289.0.1.3">
<securityCategoryTag tagType="tagType7" tag7Encoding="bitSetAttributes" singleSelection="true">
<tagCategory name="Analysis" lacv="0"/>
<tagCategory name="Concrete" lacv="1"/>
<markingQualifier>
<qualifier markingQualifier="," qualifierCode="separator"/>
</markingQualifier>
</securityCategoryTag>
</securityCategoryTagSet>
</securityCategoryTagSets>
</SPIF>
You'll see that the policy file I've sketched out here has mention of conversion to another, plain TLP policy, but it could offer equivalence rules to a number of others (including national classification policies). I've also not put in support for, for example, mandatory tags, and I'm clearly flailing about to find reasonable examples for the categories. But this is concrete code, at least.
I'd be very interested in what properties at this level would be useful to practitioners - jurisdiction seems like one, but I'm sure there's a slew of others. What these are will vary, I'm sure, but the benefit of this kind of system is that variances can be handled in a stable manner.