The types of implementations that need to conform need be clearly identified, preferably at the beginning of the spect - or else as appropriate in the spec body. For example,  section 5 (processing model for signing) does not give any hint of what is supposed to conform to it. (is that a machine? or a process implementation? or yet a document representing this process?) See 4.2 in the conformance guideline http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html . In this case, various implementations seem to be: a DSS Client , a DSS server, a signature object, and more  (?)In other words , what kinds of thing can we claim to be conforming to this spec? Then ideally, normative statements can refer to this type ("a DSS client MUST....", a signature object SHOULD...") Then such implementation becomes a "conformance target" in a conformance clause. The conformance clause must refer to the implementation type (see sec 5.2 in conf clause guideline): "a server implementation satisfies "DSS server" conformance profile if...". The 2 first conf clauses (JSON and XML) are lacking conformance targets. The two next are better (yet DSS Client never defined as an implementation type! )