OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] Is a single <Schema> element adequate?


Tommy Lindberg wrote:
> I whipped up, and attach, an example in an attempt to further
> illustrate my point with the <Schema> element.
> 
> I can't see how a single <Schema> element could provide the server
> with information about both ID attributes;  I can see how to do it
> with more than one .

Agreed.


> On 5/6/05, Edward Shallow <ed.shallow@rogers.com> wrote:
> 
>>Agree with Trevor,
>>
>>In the following snip either the client (inline) or the server (after
>>receive) could add the 3 DTD lines below.
>>
>>This may again create angst for some implementations. Furthermore the 1st
>>declaration line would not be allowed in XMLData as is. No amount of
>>namespace provisioning will allow support for declaration and PI lines.
>>
>>Ed
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><!DOCTYPE Document [
>><!ATTLIST Object Id ID #IMPLIED>
>>]>
>><Document>
>>        <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#";>

Before we had <Schema>, we had a <DTD> element that was base64 encoded. 
     The DTD wasn't sent as part of the Input Document.

I think the possible solutions are:
1) go back to using <DTD>
2) add multiple <Schema>
3) not support server resolving <ds:Reference>s

I'd vote for 3.

Trevor


>>
>>.
>>.
>>.
>>
>>-----Original Message-----
>>From: Trevor Perrin [mailto:trevp@trevp.net]
>>Sent: May 6, 2005 1:57 AM
>>To: Tommy Lindberg
>>Cc: dss@lists.oasis-open.org
>>Subject: Re: [dss] Is a single <Schema> element adequate?
>>
>>Tommy Lindberg wrote:
>>
>>>Hi Trevor -
>>>
>>>I had accepted bloated payloads as a result of transfering schemas
>>>inline :) I even wrote the code to do it, but based on what you are
>>>saying it looks like I may have misunderstood the intended usage of
>>>the <Schema> element.
>>>
>>>
>>>
>>>>I think it's possible to chop down such a schema into a single one
>>>>that contains everything needed?
>>>
>>>
>>>I have never had to that. You wouldn't have an example handy?
>>
>>No - and I may be wrong.  It might not be possible to define things in
>>different namespaces with a single schema.
>>
>>Earlier, we used DTDs for this, which may be more flexible.  See
>>http://www.aleksey.com/xmlsec/faq.html, section 3.2, for an example.
>>
>>The server only needs to identify ID attributes in the situation where a
>><ds:Reference> uses a null URI and an XPointer expression, and the client
>>doesn't pass the server the exact Input Documents that match the
>><ds:Reference>s (so the server has to resolve the <ds:Reference>s by
>>itself).
>>
>>We could decide not to support that case, and require the client to always
>>send Input Documents that match all the <ds:Reference>s.  That may be more
>>work for the client, and may result in larger protocol messages.
>>
>>Trevor
>>
>>
>>>Regards,
>>>Tommy
>>>
>>>
>>>On 5/5/05, Trevor Perrin <trevp@trevp.net> wrote:
>>>
>>>
>>>>Tommy Lindberg wrote:
>>>>
>>>>
>>>>>The <Schema> element in DocumentBaseType and SignatureObject allows
>>>>>for the optional transfer of a single XML Schema. This seems
>>>>>inadequate
>>>>
>>>>>for some use cases such as verifying a signed XML instance that
>>>>>pertains to a schema that in turn imports additional schemas.
>>>>
>>>>Hi Tommy,
>>>>
>>>>note that the schema is only needed in certain usage scenarios.  In
>>>>these scenarios, the schema identifies ID attributes so as to help the
>>>>server resolve <ds:Reference>s.  The schema doesn't have to be the
>>>>full schema for the document.  So even if the full schema imports
>>>>other schemas, I think it's possible to chop down such a schema into a
>>>>single one that contains everything needed?
>>>>
>>>>Trevor
>>>>
>>>>ps: When the <Schema> element is described in the core spec, it refers
>>>>to "section 4.3, step 2".  Those references should be changed to
>>>>"section 4.3, step 1".
>>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail.  You may a link to this group and all your TCs in OASIS
>>at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>><?xml version="1.0" encoding="utf-8"?>
>><doc:Document xmlns:doc="urn:example:doc">
>>  <a:A xmlns:a="urn:example:a" AttrA="I1">
>>    This is A's text.
>>  </a:A>
>>  <b:B xmlns:b="urn:example:b" AttrB="I2">
>>    This is B's text.
>>  </b:B>
>>  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>>    <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="#I1">
>>        <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>zsV7fmljCZIITeBuCLtMrPabKB4=</ds:DigestValue>
>>      </ds:Reference>
>>      <ds:Reference URI="#I2">
>>        <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>HnREmeKcx9tIdsY80rLgutN1GlA=</ds:DigestValue>
>>      </ds:Reference>
>>    </ds:SignedInfo>
>>    <ds:SignatureValue>
>>      T7D556ne6HuH2hF9YtO7U6j0FbE2Em0GX6XnRUsz3l8vt9VhL9930kRddlbhIZBKDJtA
>>      6naNL/0ObD5QM+FHAbEKhhx9JtPh95RUpCMwd1BB8QyvsQXuPW144iUvaYwPYMKx6fQC
>>      4h67M7WhhqzJ6M7pFACqsxM59Lo1g5313xA=
>>    </ds:SignatureValue>
>>    <ds:KeyInfo>
>>      <ds:X509Data>
>>        <ds:X509Certificate>
>>          MIIERDCCAyygAwIBAgIBATANBgkqhkiG9w0BAQUFADCB3jELMAkGA1UEBhMCQ0gxDjAMBgNVBAgT
>>          BUJlcm5lMQ4wDAYDVQQHEwVCZXJuZTEfMB0GA1UEChMWVW5pdmVyc2FsIFBvc3RhbCBVbmlvbjEa
>>          MBgGA1UEChMRRm9yIFRlc3QgVXNlIE9ubHkxHTAbBgNVBAsTFEVsZWN0cm9uaWMgUG9zdCBNYXJr
>>          MTMwMQYDVQQDEypVbml2ZXJzYWwgUG9zdGFsIFVuaW9uIFBpbG90IEVQTSBBdXRob3JpdHkxHjAc
>>          BgkqhkiG9w0BCQEWD0NBQWRtaW5AdXB1LmludDAeFw0wNTAxMjUxOTU3MTFaFw0xMDAxMjQxOTU3
>>          MTFaMIHeMQswCQYDVQQGEwJDSDEOMAwGA1UECBMFQmVybmUxDjAMBgNVBAcTBUJlcm5lMR8wHQYD
>>          VQQKExZVbml2ZXJzYWwgUG9zdGFsIFVuaW9uMRowGAYDVQQKExFGb3IgVGVzdCBVc2UgT25seTEd
>>          MBsGA1UECxMURWxlY3Ryb25pYyBQb3N0IE1hcmsxMzAxBgNVBAMTKlVuaXZlcnNhbCBQb3N0YWwg
>>          VW5pb24gUGlsb3QgRVBNIFNpZ25hdHVyZTEeMBwGCSqGSIb3DQEJARYPQ0FBZG1pbkB1cHUuaW50
>>          MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCt76rxkdwCDldyW0xpWgVEhmJPfxmovAWOhkZm
>>          iaTaRU2j83gOhVlhqL4/CIfuVMy2CNx3CNN5XomVknvt1/VyB4p9qpfUDQ9b3IRZk8gTSbMe+41s
>>          RnggqHadIizMkRN1p/VA8MWsJu8dPlBhCE0DsBaF3zptV2GIy3saM7cPPwIDAQABo4GOMIGLMAwG
>>          A1UdEwQFMAMCAQAwHQYDVR0OBBYEFHTznwFYH6CS8xuZZlvo+6p3eWWaMB8GA1UdIwQYMBaAFO0V
>>          ydJTZFy9p5n9OT6icSir2KhQMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jYTEudXB1LmludC9t
>>          YXN0ZXIuY3JsMAsGA1UdDwQEAwIHgDANBgkqhkiG9w0BAQUFAAOCAQEAMp2qzlZOxIU1LKV8mKb0
>>          pjVgfVbSLFmCgPJPxRnZciLY+P5sMhpdAkGQdhm67dvwBNPisz3XlnC7U/JH6mFeXDhat9mMg5LO
>>          +9KlsKqZWmT9riMvCGKJeibMSyzM1sgwv3ib5/kSswDDMcEaOW5QjoytluZWt7cR4ice7aow1EF5
>>          XdEqNYkTErFM6rhfqO1lwg5V3Oc8SrqwnznUaXhjjTTHnsiWGtP0ip++UwKH0T0NE3CYHIkakGtg
>>          Pd5q6LsIp4so3+cMpQGWKngf+/Dj2vag24QG7ohcXYM2y7hGhdbY34m5QzlJQr0r2H9MUsg3cne6
>>          Z+X4hcmhG67sIX1yxA==
>>        </ds:X509Certificate>
>>      </ds:X509Data>
>>    </ds:KeyInfo>
>>  </ds:Signature>
>></doc:Document>
>>
>>
>>------------------------------------------------------------------------
>>
>><?xml version="1.0"?>
>><schema targetNamespace="urn:example:a" xmlns:a="urn:example:a" xmlns="http://www.w3.org/2001/XMLSchema";
>>  elementFormDefault="qualified" attributeFormDefault="unqualified">
>>
>>  <element name="A" type="a:AType"/>
>>  <complexType name="AType">
>>    <simpleContent>
>>      <extension base="string">
>>        <attribute name="AttrA" type="ID" use="required"/>
>>      </extension>
>>    </simpleContent>
>>  </complexType>
>></schema>
>>
>>
>>------------------------------------------------------------------------
>>
>><?xml version="1.0"?>
>><schema targetNamespace="urn:example:b" xmlns:b="urn:example:b" xmlns="http://www.w3.org/2001/XMLSchema";
>>  elementFormDefault="qualified" attributeFormDefault="unqualified">
>>
>>  <element name="B" type="b:BType"/>
>>  <complexType name="BType">
>>    <simpleContent>
>>      <extension base="string">
>>        <attribute name="AttrB" type="ID" use="required"/>
>>      </extension>
>>    </simpleContent>
>>  </complexType>
>></schema>
>>
>>
>>------------------------------------------------------------------------
>>
>><?xml version="1.0"?>
>><schema targetNamespace="urn:example:doc" xmlns:doc="urn:example:doc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
>>    xmlns="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" attributeFormDefault="unqualified">
>>  
>>  <import namespace="http://www.w3.org/2000/09/xmldsig#"; schemaLocation="xmldsig-core-schema.xsd"/>
>>  <import namespace="urn:example:a" schemaLocation="a.xsd"/>
>>  <import namespace="urn:example:b" schemaLocation="b.xsd"/>
>>
>>  <element name="Document" type="doc:DocumentType"/>
>>  <complexType name="DocumentType">
>>    <sequence>
>>      <element ref="a:A"/>
>>      <element ref="b:B"/>
>>      <element ref="ds:Signature"/>
>>    </sequence>
>>  </complexType>
>></schema>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]