[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: start of schema
I didn't have time to do much, but here's the beginning of a schema for SignRequest. http://www.oasis-open.org/apps/org/workgroup/dss/download.php/3123/dss-core-schema-00.xsd To briefly summarize: ServerGuidance - Contains inputs that don't correspond 1-to-1 with any aspect of the signature, but are things the server can take under advisement. InputDocuments - At the end cause it might be long. A list of Documents, DocumentHashes, or DocumentURIs. These derive from a DocumentBase which is similar to ds:Reference - it gives a list of transforms and a Type and URI. The Transforms inform the server what transforms have already been applied, the Type and URI will be used when the server constructs ds:References to these documents. SignatureContents - A list of DocumentSelectors. Each DocumentSelector refers to an InputDocument, and specifies what transforms should be applied to it, and whether it should be enveloped or not. Each DocumentSelector will result in a single ds:Reference. SignatureOptions - If the client wants fine-grained control over the key used, the properties added, and perhaps other things. SignaturePlacement - Left blank! This should refer to where an enveloped signature should be inserted. But how should we express this? Juan Carlos had a ds:Transforms, but I couldn't understand how that would work. OutputOptions - What the client wants to get back, these are all orthogonal - the client could receive - the signature by itself, - the signature inserted in the enveloping document, - any of the documents after transforms have been applied (the values here refer to DocumentSelectors) - any of the initial "input" documents (the values here refer to InputDocuments) I know we're missing things. Also, I stuck a couple of pet ideas in, cause they seemed to make sense: - Separated InputDocuments from DocumentSelectors. This lets you, say, send a single input document and then sign it multiple times, with different transforms applied. Also, if we consider stacked/batched operations, this would let us issue multiple operations against a single set of input documents. - The ability to always request a standalone signature. This seemed natural and easy to express, so I put it in, even though people were skeptical about it. Profiles could remove it if they don't want to support it. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]