[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: status of core
Here's the current status of core. Discussions with Ed and Gregor have settled on a bunch of changes we'd like to make, and some open issues. I'm just batching the changes for now, so other people can review, and so we can add any other changes to the list and apply them all at once. Now that we're at a Committee Draft, we probably don't want to rev the document too many more times. Functionality Changes: 1) Lines 278-282, 370-376, 937-943: Replace use of transmitted DTDs with XML Schema. Probably doesn't need to be base64 encoded any more. 2) Line 834-841, Change <DocumentWithSignature> to contain a <Document>. Add text stating that if neither XPathAfter nor XPathFirstChildOf are present, the server is being asked to decide where to place the signature. 3) Line 842-851, add 'ObjId' to <EnvelopingSignature> to set the 'Id' attribute in the created <ds:Object> (Gregor's suggestion was 'IdAttr', but 'ObjId' mirrors 'RefId') 4) Line 920-931, add another sentence or two explaining that if <SignaturePtr> points to multiple signatures, they should all be verified. 5) Line 1132 - 1134, if no signing time could be found, the output element may be omitted 6) Line 1334, use application/xml instead of text/xml for the binding. Text Changes: - Line 570 - 571: clarify somehow - Line 975, "Upon receiving this >>>result<<< code" - Line 1018 - 1019, "Otherwise, if the CMS signature is enveloping, it contains its own input data>>>, and there MUST NOT be an input document present<<<." Outstanding: 1) Mention that a DSS "Input Document" could be a signature to be counter-signed or timestamped, or a Manifest. Probably can be done with a sentence or two in 2.4. Profiles can offer more detail. 2) How to handle manifests? - right now we don't do much special for them, except clients can specify manifest verification with the <VerifyManifests> optional input. For creating manifests, or using custom verification logic (such as ignoring verification errors), clients are on their own (i.e., a client can prepare a Manifest, and send it or its hash as an Input Document). Gregor has proposed: - Client can instruct the server to create a single, first-level Manifest and add references inside it with an AddToManifest attribute on SignedReference. - Change <VerifyManifests> processing to have server ignore errors, and just return more sophisticated error details, so the client can see what happened. - Change <ReturnTransformedDocument> so it can reference a document within a first-level Manifest. 3) Should we have more specific <ProcessingDetails>, to return in a structured form exactly which signature failed, or which Reference failed, or how it failed? Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]