[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] RE: Public comment, namespace inheritance
Hi Trevor and all,|
please see below
Trevor Perrin wrote:
I agree and I think its worth the effort to make a clear distinction between what is payload and what belongs to dss.
I agree and would use a formulation that clearly expresses that xml payload (i.e. well-formed like xml without
but one or more
Hence it can be extracted free of any ancestry context and can be retrieved as it is. This implies not only that the
namespace context has to be removed on extraction, but also that entity references (and the like) have to be
resolved by the client already during compilation of a request.
So a first attempt to give a formulation for dss-xml-payload in using the syntax of grammar of the
XML specification could be as follows:
For XML 1.0:
any namespaces or allowing any entity references but
For XML 1.1 one should additionally specify that any association of the prefix with a namespace
name has to be removed by empty values as indicated in namespaces for xml 1.1 section namespace scoping:
can reside inside a DssXmlPayload if the whole request should be well formed xml.
Hence EntityRef has to have the additional restriction that a valid EntityRef is one
some further thought, but it might be dangerous not to resolve them during compilation
of a request.
The reverse implies that as soon as these restrictions are not met the payload should be base64 encoded or
another kind of opaqueness has to be achieved by any means in both directions.
First <dss:XMLSignature> is somewhat similar to <dss:XMLData>. However inside <dss:XMLSignature> only
a <ds:Signature> is allowed whereas inside <dss:XMLData> DssXmlPayload is allowed, which is a lot less restrictive.
However <ds:XMLSignature> is also a kind of payload that has to be treated free of ancestry context as in the
case of an Enveloping or Detached signature the modification of the Signature element would break the signature.
So if the ds:Signature inherits the xmlns:dss=".....xsd" declaration, it is broken.
Second it allows to solve the violation of the "Unique Particle Attribution" constraint mentioned in one of
my last postings as now <xs:any namespace="##other" processContents="lax"/> can be used instead of
<xs:any processContents="lax"/> as <dss:XMLSignature> does not match namespace="##other" any more.
In the original version either all elements <ds:Signature>, <dss:XMLSignature>, <dss:Timestamp>,
<dss:Base64Signature>, <dss:SignaturePtr> would have matched namespace="##any"
when using <xs:any processContents="lax"/>.
Or <ds:Signature> would have matched namespace="##other"
when using <xs:any namespace="##other" processContents="lax"/>.