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: 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]