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: FW: ProcessingOptions example and discussion

Forwarding on behalf of Ed:

  Based partly on Trevor's feedback on the timestamp types post, as well as
the need to start getting down to examples, here is a mock-up of how to take
advantage of the ProcessingOptions request structure. I will follow this up
(soon I hope) with some response structure samples that get impacted.
Additonally I have shown how it might be extended for the EPM profile.
Please treat as a sample for now, and not an official EPM profile

  This approach allows for defaulting and easy profile extension. As stated
in my previous post which discussed timestamp requesting, a clearer
separation and prority is given to "What you want done ?" versus "What you
want returned and where to put it". Requesting a timestamp belongs in the
former. Deciding what it looks like and where it goes is the responsibility
of the DSS implementation. This will avoid incorrect specification of
timestamp details and simplifies the request structure. Other uses beyond
compound operations are also shown below. This is consistent with the more
general definition I have submitted. There is a loose categorization shown
below which could be formalized into the schema if people prefer. However if
it confuses rather than clarifies, then I see no need. Options could also be
separated by primitive if desired (e.g. Sign options, Verify options, etc
...). Again, this is a subjective "clarity and succinctness" question.


P.S. It was agreed that primitives outside the scope of DSS will never find
there way into any DSS profile (e.g. Encrypt, Decrypt, StartLifecycle, etc
..). However, if an implementation wishes to extend an existing primitive
(e.g. Sign, Verify), it is free to do so within the implementation-specifc
profile extensions. This is evident in the examples below.

<xs:element name="ProcessingOptions" type="ProcessingOptionsType"

<!-- This is the base type upon which core is built -->

<xs:complexType name="ProcessingOptionsType">

	<xs:element name="UtilizeDefaults" type="xs:boolean" minOccurs="0"/>
<!-- explicitly stated, mutually exclusive with all other options -->

	<xs:element name="IncludeContentTimeStamp" type="xs:boolean"
minOccurs="0"/>    <!-- PKCS7/CMS and XML -->
	<xs:element name="IncludeSignatureTimeStamp" type="xs:boolean"
minOccurs="0"/>  <!-- XML only, essentially an XAdES-T -->
          ...  <!-- could be more, TBD -->

<!-- This is a draft sample of the EPM profile extension which inherits then
extends the base -->

<xs:complexType name="EPMProcessingOptionsType">
    <xs:extension base=ProcessingOptionsType>

	  <xs:element name="UtilizeProfileDefaults" type="xs:boolean"

	  <!-- TimeStamping Options -->
        <xs:element name="IncludeTimeStampXAdES-X" type="xs:boolean"
        <xs:element name="IncludeTimeStampXAdES-X-L" type="xs:boolean"
        <xs:element name="IncludeTimeStampXAdES-A" type="xs:boolean"
        <xs:element name="ReturnDetachedTimeStampToken" type="xs:boolean"
minOccurs="0"/>  <!-- Applies to PKCS7/CMS only, could also be in core -->
	  <!-- Additional Crypto Operations Options -->
        <xs:element name="VerifyCertificate" type="xs:boolean"
minOccurs="0"/>  <!-- Normally True, but can be used to suppress CRL/OCSP
check -->
        <xs:element name="EncryptThenSign" type="xs:boolean" minOccurs="0"/>
<!-- For confidentiality, encrypt content to be signed -->
        <xs:element name="DecryptIncomingEnvelope" type="xs:boolean"
minOccurs="0"/>  <!-- Used on Verify only -->
	  <!-- Receipting Options -->
        <xs:element name="IssueProofOfPossessionReceipt" type="xs:boolean"
        <xs:element name="IssueProofOfSubmissionReceipt" type="xs:boolean"
        <xs:element name="IssueProofOfDeliveryReceipt" type="xs:boolean"
        <xs:element name="IssueCertificateOfVerificationReceipt"
type="xs:boolean" minOccurs="0"/>
        <xs:element name="IssueCombinedReceipt" type="xs:boolean"
	  <!-- Lifecycle Control Options -->
        <xs:element name="StartLifecycle" type="xs:boolean" minOccurs="0"/>
        <xs:element name="EndLifecycle" type="xs:boolean" minOccurs="0"/>
	  <!-- Return Additional Info Options -->
        <xs:element name="ReturnExtendedStatusInfo" type="xs:boolean"
minOccurs="0"/>  <!-- Returns extended status info and info from TSA,
        <xs:element name="ReturnValidationDataAsText" type="xs:boolean"
minOccurs="0"/>  <!-- Returns human readable OCSP response -->
        <xs:element name="ReturnSignatureInfo" type="xs:boolean"
minOccurs="0"/>  <!-- Returns selected signature attributes separately  -->
        <xs:element name="ReturnCertificateInfo" type="xs:boolean"
minOccurs="0"/>  <!-- Returns selected cert attributes separately-->

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]