ism:classification=TS ism:classification=S ism:classification=C ism:classification=U Role maps to ntk:access=Roles|Group”

26 Copyright © 2016 Open Geospatial Consortium. should be filtered from being sent to the client based upon the “ism:classification” attribute for that tag. The most restrictive classification was TS Top Secret, followed in order by, S Secret, C Confidential, and followed lastly with the least restrictive classification of Clearance being: U Unclassified. An example of a tdf:StructuredPayload is shown below. Notice that the classification attribute in the mda:noticeofarrival tag is equal to C line 9. This is the roll-up from the entire payload. Any Classification markings anywhere below this tag lines 12 and on should be identified and filtered based upon the user attributes. If the user is Unclassified, lines 26 through 36 should be stripped, but line 37 would remain.

4.5.1.2.3 ism:classification=TS

In filtering a document based on the “Clearance” attribute, the user with a user attribute of Clearance equal to TS can see all tags and information that are contained in a document that is not filtered out by any of the other filters. Copyright © 2016 Open Geospatial Consortium. 27

4.5.1.2.4 ism:classification=S

A user with a user attribute of Clearance equal to “S” can see all tags and information that are contained in a document, after all ism:classification=”TS” tags have been removed, and that are not filtered out by any of the other filters.

4.5.1.2.5 ism:classification=C

A user with a user attribute of Clearance equal to “C” can see all tags and information that are contained in a document, after all ism:classification=”TS” and ism:classification=”S” tags have been removed, and that are not filtered out by any of the other filters.

4.5.1.2.6 ism:classification=U

A user with a user attribute of Clearance equal to “U” can see all tags and information that are contained in a document, after all ism:classification=”TS”, ism:classification=”S”, and ism:classification=”C” tags have been removed, and that are not filtered out by any of the other filters. 4.5.1.2.7 Role maps to ntk:access=Roles|Group” Roles in the OGC Attribute Store were one-to-one. Each user only had at most one role. Each document included an ntk:Access tag and various ntk:AccessGroup and ntk:AccessGroupValue information in the TDO headers, as well as nested in various tags throughout the document. Any tag in the document payload, and all of its children tags, should be filtered from being sent to the client based upon the ntk:access=Roles|Group{role list} attribute for that tag. These role attributes are specific and need exact pattern match to allow the tag and its children to pass. More specifically, if a tag has a ntk:access attribute that does not match exactly the user attribute Role, then that information should not be sent to the client.

4.5.1.2.8 EntityTypes