[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] suggestion for 3.3.2 (Action 05-07-25-1)
A small point, But no other optional inputs are part of basic processing. For consistency I suggest either: a) making this a typical optional input, i.e. not part of basic processing b) making this a fundamental part of the protocol, i.e. not an optional input Since you intend profiles to choose it or not, I suggest (a). I also suggest not deleting the current text about client-side splicing, but adding qualifications (e.g., that it can be used for <DocumentHash>, or with servers that do not normalize inputs). Trevor Konrad Lanz wrote: > Dear all, > > The problem with the current text is that client side splicing could > potentially lead to signatures not validating due to problems with > normalization and lost/inherited namespaces plus that the name > Enveloping signature does not reflect the fact that multiple such > objects can be included in a signature. > > An EnvelopingSignature is a Signature having <ds:Objects> which are > referenced by <ds:References> having a same-document Uri. > > Hence an <dss:Document> having a same-document Uri and an optional input > pointing at it is to be inserted as an <ds:Object> included/spliced in > the signature and returns the signature. > > The suggestion concerning EnvelopingSignature is to rename the optional > Input <dss:EnvelopingSignature> to <dss:IncludeObject> and modify it as > follows to replace current Section 3.3.1. > <xs:element name="IncludeObject"> > <xs:complexType> > <xs:attribute name="WhichDocument" type="xs:IDREF"/> > <xs:attribute name="hasObjectTagsAndAttributesSet" > type="xs:boolean" default="false"/> > <xs:attribute name="ObjId" type="xs:string" use="optional"/> > </xs:complexType> > </xs:element> > > And add the following normative text: > > The server splices the to-be-enveloped documents as <ds:Object>(s) into > the returned <ds:Signature>. (This step might be omitted in a Profile) > A client can use any server that implements basic processing to create > an enveloping XML signature by using this optional input. > To do this, the client refers to this object using a same-document URI > value for the RefURI attribute of the Document pointed at by WhichDocument. > The given URI should dereference the relevant parts of the included > Object to be included in the calculation for the corresponding reference. > > In the case of the Document pointed at by WhichDocument having > Base64Data, <ds:Object>('s) MIME Type is to be set to the value of > <dss:Base64Data>('s) MIME Type value and the Encoding is to be set to > http://www.w3.org/TR/xmlschema-2/#base64Binary. > > best regards > Konrad > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]