[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend)
Hi Frederick, I didn't make myself clear. I agree that we should allow an embedded policy statement - whether its WS-Policy, XACML?, or simply a collection of those elements currently allowed in OptionalInputs signed by some external authority. Paul >-----Original Message----- >From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] >Sent: Tuesday, February 10, 2004 11:15 AM >To: p.madsen@entrust.com; dss@lists.oasis-open.org >Subject: RE: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend) > > >Paul > >I thought it might make sense to embed a policy statement >rather than only allowing a URI reference, hence my question. > >I've looked at WS-Policy in the past, so was considering how >that might fit, >if at all, but admit I haven't thought about this much at all. > >The "probably not" was since I thought we might want to avoid >additional complexity, but I really think we should allow an >embedded policy as an alternative to a URI. > >regards, > >Frederick > >-----Original Message----- >From: ext Paul Madsen [mailto:p.madsen@entrust.com] >Sent: Tuesday, February 10, 2004 11:04 AM >To: Hirsch Frederick (Nokia-TP/Boston); dss@lists.oasis-open.org >Subject: RE: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend) > > >Hi Frederick, wrt 11) below, why do you feel it would not make sense to >allow the client to include an embedded (and presumably signed) policy >statement rather than simply a URI in <ServicePolicy>? > >I am currently trying to model this within policy-wiser server >profile as a ><ds:Signature> object within <OptionalInputs> but placing it within ><Serviceprofile> would be more consistent. > >Thanks > >Paul > >>-----Original Message----- >>From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] >>Sent: Saturday, February 07, 2004 10:32 AM >>To: trevp@trevp.net; dss@lists.oasis-open.org >>Subject: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend) >> >> >>Comments and proposals for Draft 11 of DSS Core, 3 Feb 04. >> >>Line numbers refer to pdf: >>http://www.oasis-open.org/apps/org/workgroup/dss/download.php/5 >>292/oasis-dss-1.0-core-spec-wd-11.pdf >> >>(1). I propose we switch from QNames to URLs for consistency and to >>avoid various known issues with QNames used as values (e.g. >>canonicalization if signed) >> >> Properties/Identifier, section 3.4.6, line 685-7, schema line 713 >> Change from QName to anyURI >> >> (2) I propose we use URL(s) for the dss namespace(s). This has the >>advantage that optionally the schema can be retrieved from the URL. >>OASIS is defining a standard for defining such persistent URLs, other >>TCs like WSS have adopted this approach. >> >>(3) Editorial comments on overview (section 1.3, line 163) >> >>Might help reader to add subsections: >>1.3.1 Signing and Verifying Protocol (before line 163) >>1.3.2 XML TimestampToken (break line 197, before First...) >>1.3.3 RequesterIdentity XML Element (break line 199, before >Second...) >> >>Update line 180: >>bandwidth and protect the privacy of the document content. >> >>(The input documents to be signed or verified can be transferred in >>their entirety, or the client can hash the documents itself and only >>send the hash values, to save bandwidth and protect the privacy of the >>document content. ) >> >> Change line 190 from "data to use in verifying" to: >> >> data necessary to verify the signature (such as certificates and >>CRLs)... >> >>(4) Since Document and DocumentHash share common document >structure, it >>might make sense to derive them from a common type, something like >>follows: >> >><xs:complexType name="DocumentBaseType" abstract="true"> >> <xs:sequence> >> <xs:element ref="ds:Transforms" minOccurs="0"/> >> </xs:sequence> >> <xs:attribute name="ID" type="xs:ID" use="optional"/> >> <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> >> <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> >> </xs:complexType> >></xs:element> >> >><xs:element name="Document" type="DocumentType" /> >><xs:complexType name="DocumentType"> >> <xs:complexContent> >> <xs:extension base="DocumentBaseType"> >> <xs:choice> >> <xs:element ref="dss:XMLData"/> >> <xs:element ref="dss:Base64Data"/> >> </xs:choice> >> </xs:extension> >> </xs:complexContent> >></xs:complexType> >> >> >><xs:element name="DocumentHash" type="DocumentHashType" /> >><xs:complexType name="DocumentHashType"> >> <xs:complexContent> >> <xs:extension base="DocumentBaseType"> >> <xs:sequence> >> <xs:element ref="ds:DigestMethod"/> >> <xs:element ref="ds:DigestValue"/> >> </xs:sequence> >> </xs:extension> >> </xs:complexContent> >></xs:complexType> >> >>(5) Add text to RefURI definition, line 272: >> >> "The RefURI attribute SHOULD be specified, no more than one RefURI >>attribute may be omitted in a single signing request." >> >>(6) Add clarification to Document element description before line 291: >> >>"The document hash for signing is created from the element content of >>XMLData (i.e. the <XMLData> tags are not included), or from >the content >>of the <Base64Data> element after it is base64 decoded. " >> >>(yes this reinforces the processing rules here for the reader) >> >>Do we need to say something about spaces in the XMLData >>element content? >> >>(7) Why can't a SignaturePtr point outside the document and hence have >>type anyURI instead of IDREF? >>(Schema, line 390) >> >>(8) Editorial - it may make sense to put the non-optional >>result section >>before the optional input sections (e.g 2.8 before 2.6) >> >>(9) Why is resultMajor a string instead of a URI? Seems URI would be >>consistent with minorCode and better defined? (schema, line 462) >> >>(10) Editorial >>section 2.7.1 ine 428, replace "the client thinks he does" with "the >>client expects" >> >>section 2.7.2, same change, line 435 >> >>(11) Does it ever make sense to include an embedded policy statement >>rather than a policy URI? Probably not. >> >>(12) Editorial, 2.7.3 ClaimedIdentity, change "MUST further" to "MUST" >> >>(13) SignResponse, line 525 section 3.2 >>Why must a SignResponse not include a SignaturePointer? If such a >>pointer used a URI then the client could retrieve the signature later >>from a server via HTTPS GET and the URI? >> >>(14) Add to processing rule step 2a at end, line 562: >> >>"A signature MUST NOT be created if more than one RefURI is omitted in >>the set of input documents." >> >>(this is explicit in ds:Signature rules, but probably worth making >>explicit here) >> >>(15) IntendedAudience, section 3.4.3 line 611 >> >>Presumably this does not have the same meaning as a SAML >>AudienceRestriction, ie. the signature may be passed to other >audiences >>later. >> >>(16) SignedReferences processing rule implication is not clear >>At 3.4.5 line 638-640, this is not clear. Which second step >is referred >>to? Is a mixture of SignedReferences and non-SignedReferences >possible? >> >>(17) Properties, Value. Can a Property have more than one Value? >>Should schema have maxOccurs="1" (line 715) >> >>(18) Editorial, VerifyRequest, section 4.1, line 771 >> >>remove "(i.e. deleting the signature)" - the signature isn't actually >>deleted, but the signature processing rules must exclude the >>signature - >>this parenthetical might make it more confusing. >> >>(19) Editorial, line 773, replace "A list of" with "The" >> >>(20) Would it make processing of SignaturePtrs easier if >InputDocuments >>were first in VerifyRequests? >> >>If so, move InputDocuments element first in schema sequence, lines >>777-779 >> >>(21) Basic Processing, step 3, line 815, it isn't clear how the >>transform verification will work if some transforms are added >>transparently by a signing server. If the verification is done at a >>different server with different rules, how are transforms known other >>than trusting the list? >> >>(22) Why aren't ReturnTimestampTime and Output TimestampTime >defined in >>the Timestamp profile instead of core? Sec 4.5.6, line 971 >> >>(23) Clarify that a signature may only be updated by adding unsigned >>attributes. Otherwise a new signature must be created to apply the key >>to changed content. Section 4.5.8, line 991 >> >>(24) Transformed Document line 4.5.9 >>Might a client want to see the result of applying combinations (1 or >>more of the transforms)? >> >>Is use of an index fragile for references - is order always >guaranteed? >>Should XPath be considered? >> >>Should the result include the Transform(s) used, to confirm >correctness >>of operation? >> >>(25) 5.1.1 , line 1081, XMLTimeStampToken >>Shouldn't Reference for "this document" contain "" for URI? This would >>Sign entire XMLTimeStampToken, excluding enveloped signature. Is this >>what is wanted and being said here? >> >>(26), Creation Time ins section 5.1.2, line 1099 >> >>Shouldn't we replace "was started" with "completed". Ie time is from >>when entire request has been received (effective start) until entire >>operation done. >> >>(27) SAML reference should be updated to SAML 1.1, line 1355 >>http://www.oasis-open.org/committees/download.php/3405/oasis-s >stc-saml- >>bindings-1.1.pdf >> >> >>(28) Draft 11 is missing revision history entry >> >>regards, >> >>Frederick >> >>Frederick Hirsch >>Nokia >> >> >> >> >>To unsubscribe from this mailing list (and be removed from the >>roster of the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_ >workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]