[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Rewriting of imported schemes
Hi Andreas,Because we are using DSS Core over Browser POST in our DSS implementation, we really need message-level security by means of an XML signature.
Hence our SignRequest looks as follows:<dss:SignRequest xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" xmlns:my="urn:dss:myextension" xmlns:sec="urn:dss:security" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" RequestID="request-id-is-just-a-string" wsu:Id="uuid-5ce88924-a565-452a-aadd-f8068f49348f">
<dss:OptionalInputs> <dsb:Other> <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value> </dsb:Other> <my:Test> <my:Value>hello world</my:Value> </my:Test> <sec:Security> <wsa:MessageID>message-identifier</wsa:MessageID> <wsu:Timestamp> <wsu:Created>created-value</wsu:Created> <wsu:Expires>expires-value</wsu:Expires> </wsu:Timestamp> <wsa:ReplyTo> <wsa:Address>https://relying.party/landing-page</wsa:Address> </wsa:ReplyTo> <ds:Signature> <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#uuid-5ce88924-a565-452a-aadd-f8068f49348f"> <ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>5W8u9z3+OfORMX1eyBtXZwnl3lU=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:KeyName>key-name</ds:KeyName> </ds:KeyInfo> </ds:Signature> </sec:Security> </dss:OptionalInputs> </dss:SignRequest>Notice that we also had to redefine dss:SignRequest to have an Id of type xs:ID so we can ds:Reference it properly.
So our redefine XML schema becomes: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:sec="urn:dss:security"elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/><xs:import namespace="urn:dss:security" schemaLocation="dss-security.xsd"/>
<xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"> <xs:complexType name="SignRequestType"> <xs:complexContent> <xs:extension base="dss:SignRequestType"> <xs:attributeGroup ref="sec:SecurityAttributeGroup"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="OptionalInputsSignType"> <xs:complexContent> <xs:extension base="dss:OptionalInputsSignType"> <xs:group ref="sec:SecurityGroup"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> </xs:schema> And the extension XML schema itself: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:dss:security" xmlns:sec="urn:dss:security" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2005/08/addressing" schemaLocation="ws-addr.xsd" /><xs:import namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
schemaLocation="oasis-200401-wss-wssecurity-utility-1.0.xsd"/><xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
<xs:group name="SecurityGroup"> <xs:choice> <xs:element name="Security" type="sec:SecurityType"> <xs:annotation> <xs:documentation> Defines message-level security. </xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:group> <xs:complexType name="SecurityType"> <xs:sequence> <xs:element ref="wsa:MessageID"> <xs:annotation> <xs:documentation> A unique identifier for this message. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="wsu:Timestamp"> <xs:annotation> <xs:documentation> Message should only be used within this time frame. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="wsa:ReplyTo"> <xs:annotation> <xs:documentation>The URL to which the DSS should send a response message.
</xs:documentation> </xs:annotation> </xs:element> <xs:element ref="ds:Signature"> <xs:annotation> <xs:documentation> The message signature. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:attributeGroup name="SecurityAttributeGroup"> <xs:attribute ref="wsu:Id" use="required"/> </xs:attributeGroup> </xs:schema> Kind Regards, Frank. On 02/03/2018 08:08 PM, Andreas Kuehne wrote:
Hi Frank,There seems to be an error in your rewritten xmldsig-core-schema. It can no longer validate XML signatures: cvc-complex-type.2.4.a: Invalid content was found starting with element 'ds:SignedInfo'. One of '{"http://www.w3.org/2000/09/xmldsig#":SignatureValue}' is expected.the ds:SignedInfo MUST NOT show up. An XMLDSig signature is expected to be contained within a dss:SignatureObject element. Where did you manage to insert the signature? Greetings, AndreasKind Regards, Frank. On 02/02/2018 01:33 PM, Andreas Kuehne wrote:Hi all, as agreed on the last call I did some research regarding the volume of imported structures. XMLDSig & SAML: The blobification of signatures and timestamps in the core limits the core's references to external types significantly. There are the SAML schemes and XMLDSig. The latter provides especially CanonicalizationMethodType and TransformType. Both contain all major non-XML-syntax incompatibilities: xs:any, mixed content and a XPath expression. The 're-creation' of these types in a compatible way within DSS-X core could be an option. The same is true for SAML. XAdES: Considering the AdES or the Verification profile the XAdES schema is included. It contains many structures and types that do not fit into the multi-syntax approach. It even defines the most evil AnyType (sequence of xs:any and mixed content and an arbitrary set of attributes). It also makes intensive use of the '<xs:choice maxOccurs="unbounded">' pattern that does not fit very well with Java's schema-to-code compiler. This pattern produces non-typesafe code like an xs:any. So the version 2.0 design goals cannot be achieved with an unmodified XAdES schema. A quick check with the code coverage of my DSS-X tests shows that at least 50% (25 out of 50) of the structures defined in XAdES are used so cherrypicking of the 'useful few' does not work out. Applying the blobification approach to the verification report sounds promising for the verification report if it will restricted to be 'XML-syntax only'. This could be acceptable and the JSON syntax problem do not apply. But the verification report itself is not a autonomous artifact but uses the core schema. So we would introduce a mix of multi-syntax-enabled types and XML-only parts. To me this sounds like a concept that wiil be hard to understand for any DSS-X user. My recommendation would be to keep things easy to use and consistent: Support the multi-syntax paradigm everywhere and don't introduce XML-only profiles! But this comes with price of rewriting of external schemes. Let's see what's Peter's view on JSON support for the verification report. I wouldn't be surprised that team working with Javascript in the browser and / or node.js in the server side would appreciate to see a verification report in JSON. Greetings, Andreas
-- Frank Cornelis e-Contract.be BVBA https://www.e-contract.be
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]