[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 best regards Konrad Lanz 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 prolog but one or more element s
that is to be transported inside a sign or verify request) has to be
independend.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 amp ,
lt ,
gt ,
apos ,
quot .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:
prolog
and hence no doctypedecl
and also no DTD and entity declarationscan 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 of amp ,
lt ,
gt ,
apos ,
quot only. If external entities should be allowed
needs 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"/>. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]