Digital Signature Service Core Protocols and Elements · oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 4 of 31 97 1 Introduction

oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 1 of 31

1

Digital Signature Service Core 2

Protocols and Elements 3

Working Draft 06, 12 November 2003 4

Document identifier: 5 oasis-dss-1.0-core-spec-wd-06 6

Location: 7 http://www.oasis-open.org/committees/dss 8

Editor: 9 Trevor Perrin, individual <[email protected]> 10

Contributors: 11 Dimitri Andivahis, Surety 12 Juan Carlos Cruellas, individual 13 Frederick Hirsch, Nokia 14 Pieter Kasselman, Baltimore 15 Andreas Kuehne, individual 16 John Messing, individual 17 Tim Moses, Entrust 18 Nick Pope, individual 19 Rich Salz, DataPower 20 Ed Shallow, Universal Postal Union 21

Abstract: 22 This draft defines XML request/response protocols for signing, verifying, and time-23 stamping of XML documents and other data. It also defines an XML time-stamp format, 24 and an XML signature property through which a signature server can represent the 25 client’s identity. 26

Status: 27 This is a Working Draft produced by the OASIS Digital Signature Service Technical 28 Committee. Committee members should send comments on this draft to 29 [email protected]. 30

For information on whether any patents have been disclosed that may be essential to 31 implementing this specification, and any offers of patent licensing terms, please refer to 32 the Intellectual Property Rights section of the Digital Signature Service TC web page at 33 http://www.oasis-open.org/committees/dss/ipr.php. 34

35

36


Table of Contents 36

1 Introduction ........................................................................................................................ 4 37 1.1 Notation............................................................................................................................ 4 38

1.2 Schema Organization and Namespaces ........................................................................... 4 39 1.3 DSS Overview (Non-normative)........................................................................................ 5 40

2 Common Protocol Structures.............................................................................................. 6 41

2.1 Schema Header and Namespace Declarations ................................................................. 6 42 2.2 Type <AnyType> .............................................................................................................. 6 43

2.3 Type <NameType>........................................................................................................... 6 44 2.4 Element <InputDocuments>.............................................................................................. 7 45

2.4.1 Commonality between <Document> and <DocumentHash>....................................... 7 46 2.4.2 Element <Document>................................................................................................ 7 47 2.4.3 Element <DocumentHash>........................................................................................ 8 48

2.5 Element <Signature>........................................................................................................ 9 49 2.6 Elements <Options> and <Outputs> ................................................................................10 50

2.7 Element <Result>............................................................................................................10 51 3 The DSS Signing Protocol.................................................................................................12 52

3.1 Element <SignRequest> ..................................................................................................12 53

3.2 Element <SignResponse> ...............................................................................................12 54 3.3 Basic Processing.............................................................................................................13 55

3.3.1 Enveloping Signatures..............................................................................................13 56 3.3.2 Enveloped Signatures...............................................................................................13 57

3.4 Options and Outputs........................................................................................................13 58

3.4.1 Option <ServiceProfile>............................................................................................13 59 3.4.2 Option <ServicePolicy> ............................................................................................14 60

3.4.3 Option <ClaimedIdentity> .........................................................................................14 61 3.4.4 Options <SignatureTimestamp> and <ContentTimestamp> ......................................14 62

3.4.5 Option <IntendedAudience> .....................................................................................14 63 3.4.6 Option <KeySelector>...............................................................................................14 64 3.4.7 Option <SignedReferences>.....................................................................................15 65

3.4.8 Option <Properties> .................................................................................................15 66 3.4.9 Option <SignaturePlacement> and Output <OutputDocument>.................................16 67

4 The DSS Verifying Protocol ...............................................................................................18 68 4.1 Element <VerifyRequest> ................................................................................................18 69 4.2 Element <VerifyResponse> .............................................................................................18 70

4.3 Basic Processing.............................................................................................................19 71 4.4 Result Codes...................................................................................................................19 72

4.5 Options and Outputs........................................................................................................20 73 4.5.1 Option <ServiceProfile>............................................................................................20 74

4.5.2 Option <ServicePolicy> ............................................................................................20 75


4.5.3 Option <ClaimedIdentity> .........................................................................................20 76 4.5.4 Option <IgnoreMissingInputDocuments> ..................................................................20 77

4.5.5 Option <VerifyManifests>..........................................................................................20 78 4.5.6 Option <VerificationTime> ........................................................................................21 79

4.5.7 Option <AdditionalKeyInfo> ......................................................................................21 80 4.5.8 Option <ReturnProcessingDetails> and Output <ProcessingDetails> ........................21 81 4.5.9 Option <ReturnSigningTime> and Output <SigningTime> .........................................22 82

4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> ...................................22 83 4.5.11 Option <ReturnUpdatedSignature> and Output <UpdatedSignature>......................22 84

5 Timestamp token...............................................................................................................24 85 5.1 Schema Header and Namespace Declarations ................................................................24 86

5.2 Element <Tst> .................................................................................................................24 87 5.3 Element <TstInfo> ...........................................................................................................24 88 5.4 ComplexType TstInfoType...............................................................................................25 89

5.5 Timestamp verification procedure ....................................................................................25 90 6 Editorial Issues..................................................................................................................27 91

7 References .......................................................................................................................28 92 7.1 Normative........................................................................................................................28 93

Appendix A. Revision History.....................................................................................................30 94

Appendix B. Notices ..................................................................................................................31 95

96


1 Introduction 97

This specification defines the XML syntax and semantics for the Digital Signature Service core 98 protocols, and for some associated core elements. The core protocols support signing, verifying, 99 and time-stamping of XML documents and other data. The core elements extend XML 100 Signatures [XMLSig] to contain time-stamps and representations of the client’s identity. 101

The core protocol messages are typically bound into other structures for transport, such as XML-102 encoded SOAP messages. The core protocols are also typically profiled to constrain optional 103 features and add additional features. A companion document provides an initial set of bindings 104 and profiles [DSSBind]. A file containing just the core schema [Core-XSD] is also available. 105

The following sections describe how to understand the rest of this specification. 106

1.1 Notation 107

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 108 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be 109 interpreted as described in IETF RFC 2119 [RFC2119]. These keywords are capitalized when 110 used to unambiguously specify requirements over protocol and application features and 111 behaviour that affect the interoperability and security of implementations. When these words are 112 not capitalized, they are meant in their natural-language sense. 113

Listings of DSS schemas appear like this. 114 115

Example code listings appear like this. 116

In cases of disagreement between the the DSS schema file [Core-XSD] and this specification, 117 the schema file takes precedence. 118

Conventional XML namespace prefixes are used throughout the listings in this specification to 119 stand for their respective namespaces (see Section 1.2) as follows, whether or not a namespace 120 declaration is present in the example: 121

• The prefix dss: stands for the DSS namespace. 122

• The prefix ds: stands for the W3C XML Signature namespace [XMLSig-XSD]. 123

• The prefix xs: stands for the W3C XML Schema namespace [Schema1]. 124

This specification uses the following typographical conventions in text: <DSSElement>, 125 <ns:ForeignElement>, Attribute, Datatype, OtherCode. 126

1.2 Schema Organization and Namespaces 127

The DSS core structures are defined in a schema [Core-XSD] associated with the following XML 128 namespace: 129

http://www.oasis-open.org/tc/DSS/1.0/core/schema 130

Imported into this schema is the schema for XML Signature [XMLSig-XSD], which is associated 131 with the following XML namespace: 132

http://www.w3.org/2000/09/xmldsig# 133

134

135


1.3 DSS Overview (Non-normative) 136

[This text will be revised as the document matures] 137

This specification outlines an XML based protocol and common XML schema structures 138 necessary to support a delegated XML signing and verification service, as well as a time 139 stamping service. One of the goals is to define an XML-based protocol that can support a variety 140 of signature and timestamp server implementations, supporting both XML signature and non-XML 141 signature services, for example, with a single XML-based protocol. Application profiles and 142 server implementations may constrain what is supported in a specific deployment. The protocol 143 and core elements are designed to be flexible and extensible through the use of an open XML 144 schema. 145

There are two major services supported by this specification – signature and time stamp 146 services. Signature services include signing and verification and may include time mark attributes 147 in signatures. Time mark signature attributes may include the time of signing, for example. The 148 time stamp service is different in that it defines requests, responses and XML schema formats to 149 support authoritative timestamps analogous to the TimeStampToken defined in RFC 3161, 150 supporting proof that a datum existed before a specific point in time. 151

Options are used to allow a variety of complex choices to be uniformly expressed and managed. 152 Signing options include the kind of signature to be returned (e.g. CMS, XML Signature), how an 153 XML signature is to be delivered (detached, enveloped, enveloping), where it is to be placed in a 154 document when not detached, and which signature attributes are to be generated by the server, 155 for example. It is expected that this specification will be profiled to constrain the options and 156 define necessary extensions to support specific applications in an interoperable manner. This 157 specification assumes that protocol requests either succeed or fail, avoiding the complexity of 158 partial success when some options are not met. It is anticipated that application profiles will 159 define meaningful sets of supported options and appropriate defaults. 160

One example of a possible profile is a DSS Web Service Security Profile, defining how the DSS 161 protocol may be used to request SOAP Message security headers containing XML Signatures 162 and the supporting tokens used to convey the corresponding keys. Another example would be a 163 “Corporate Seal” profile, defining how the protocol and structures may be used to support an 164 application that uses a single corporate key to sign documents for data origin authentication. 165

One of the specific goals of this specification is to support interoperation between DSS server 166 implementations as well as interoperability of the signatures and timestamps between DSS-based 167 and non-DSS aware signature and timestamp implementations. 168

How this protocol is used with an underlying protocols is defined by the appropriate protocol 169 bindings document. Use with SOAP, for example, will be defined in the DSS SOAP Bindings 170 specification. 171

This specification does not define general policy mechanisms, but does define interoperable 172 means to specify policies in requests and signatures, using policy QNames that can also be used 173 to specify OIDs. Explicit processing steps may be specified in requests such as “verify an 174 existing signature” before countersigning. 175

Return options include the ability to return supporting information (such as OCSP responses) as 176 well as the information on processing steps followed enabling a client to verify correct operation. 177 A DSS server ultimately determines what actions are taken according to an application profile. 178

179

180

181

182


2 Common Protocol Structures 183

2.1 Schema Header and Namespace Declarations 184

The following schema fragment defines the XML namespaces and other header information for 185 the DSS schema: 186

<xs:schema 187 targetNamespace="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 188 xmlns:dss="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 189 xmlns:xs="http://www.w3.org/2001/XMLSchema" 190 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 191 elementFormDefault="qualified" 192 attributeFormDefault="unqualified"> 193

2.2 Type <AnyType> 194

The AnyType complex type allows arbitrary XML content within an element: 195

<xs:complexType name="AnyType"> 196 <xs:sequence> 197 <xs:any processContents="lax" maxOccurs="unbounded"/> 198 </xs:sequence> 199 </xs:complexType> 200

2.3 Type <NameType> 201

The NameType complex type is used where different types of names are needed: 202

<xs:complexType name="NameType"> 203 <xs:simpleContent> 204 <xs:extension base="xs:string"> 205 <xs:attribute name="Format" type="xs:QName"/> 206 </xs:extension> 207 </xs:simpleContent> 208 </xs:complexType> 209

The Format attribute contains an XML Schema QName which determines how the string content 210 is interpreted. A namespace prefix for the QName MUST be provided. The QName may be a 211 value defined by this specification, or a value defined by some other specification, in some other 212 namespace. The values defined by this specification are: 213

EmailAddress 214

Indicates that the string content is in the form of an email address, specifically “addr-spec” as 215 defined in [RFC 2822]. An addr-spec has the form local-part@domain. 216

X509SubjectName 217

Indicates that the string content is in the form specified for the contents of the 218 <ds:X509SubjectName> element in [XMLSig]. 219

URI 220

Indicates that the string content is in the form of a URI as defined in [RFC 2396]. The URI 221 MUST be absolute, and MAY have a fragment identifier (i.e., it may be a URI Reference). 222


2.4 Element <InputDocuments> 223

The <InputDocuments> element is used to send documents to a DSS server, whether for 224 signing, verifying, or time-stamping. It consists of any number of the following elements: 225

<Document> [Any Number] 226

An XML document or some other data. 227

<DocumentHash> [Any Number] 228

A hash value of an XML document or some other data. 229

The following schema fragment defines the <InputDocuments> element: 230

<xs:element name="InputDocuments"> 231 <xs:complexType> 232 <xs:sequence> 233 <xs:choice maxOccurs="unbounded"> 234 <xs:element ref="dss:Document"/> 235 <xs:element ref="dss:DocumentHash"/> 236

<xs:any processContents="lax"/> 237 </xs:choice> 238 </xs:sequence> 239 </xs:complexType> 240 </xs:element> 241

2.4.1 Commonality between <Document> and <DocumentHash> 242

Both the <Document> and <DocumentHash> elements contain the following attributes and child 243 elements: 244

ID [Optional] 245

The identifier used to refer to this input document within the protocol message. 246

RefURI [Optional] 247

This specifies the value for the <ds:Reference> element’s URI attribute when referring to 248 this input document. 249

RefType [Optional] 250

This specifies the value for the <ds:Reference> element’s Type attribute when referring to 251 this input document. 252

<ds:Transforms> [Optional] 253

This specifies the value for the <ds:Reference> element’s <ds:Transforms> child 254 element when referring to this input document. 255

2.4.2 Element <Document> 256

The <Document> element may contain the following elements (in addition to the common ones 257 listed in 2.2.1): 258

<XMLData> [Optional] 259

This contains arbitrary XML content. 260

<Base64Data> [Optional] 261

This contains a base64 encoding of an XML document or some other data. The type of data is 262 specified by its MimeType attribute. 263


The following schema fragment defines the <Document>, <XMLData>, and <Base64Data> 264 elements: 265

<xs:element name="Document"> 266 <xs:complexType> 267 <xs:sequence> 268 <xs:choice> 269 <xs:element ref="dss:XMLData"/> 270 <xs:element ref="dss:Base64Data"/> 271 </xs:choice> 272 <xs:element ref="ds:Transforms" minOccurs="0"/> 273 </xs:sequence> 274 <xs:attribute name="ID" type="xs:ID" use="optional"/> 275 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 276 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 277 </xs:complexType> 278 </xs:element> 279 280 <xs:element name="XMLData" type="dss:AnyType"/> 281 282 <xs:element name="Base64Data"> 283 <xs:complexType> 284 <xs:simpleContent> 285 <xs:extension base="xs:base64Binary"> 286 <xs:attribute name="MimeType" type="xs:string"> 287 </xs:extension> 288 </xs:simpleContent> 289 </xs:complexType> 290 </xs:element> 291

2.4.3 Element <DocumentHash> 292

The <DocumentHash> element contains the following elements (in addition to the common ones 293 listed in 2.2.1): 294

<ds:DigestMethod> [Required] 295

This identifies the digest algorithm used to hash the document. 296

<ds:DigestValue> [Required] 297

This gives the document’s hash value. 298

The following schema fragment defines the <DocumentHash> element: 299

<xs:element name="Document"> 300 <xs:complexType> 301 <xs:sequence> 302 <xs:element ref="ds:DigestMethod"/> 303 <xs:element ref="ds:DigestValue"/> 304 <xs:element ref="ds:Transforms" minOccurs="0"/> 305 </xs:sequence> 306 <xs:attribute name="ID" type="xs:ID" use="optional"/> 307 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 308 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 309 </xs:complexType> 310 </xs:element> 311


2.5 Element <Signature> 312

The <Signature> element is returned in a sign response, and sent in a verify request. It may 313 contain one of the following elements: 314

<ds:Signature> [Optional] 315

An XML Signature [XMLSig]. 316

<Base64Signature> [Optional] 317

A base64 encoding of some non-XML signature, such as a PGP [PGP] or CMS [CMS] 318 signature. The type of signature is specified by its MimeType attribute. 319

<SignaturePtr> [Optional] 320

This points to an XML Signature that may be in one of the input documents, or one of the 321 outputs. 322

A <SignaturePtr> contains the following elements: 323

WhichDocument [Required] 324

This identifies the document being pointed at. 325

XPath [Optional] 326

This identifies the element being pointed at. It may be omitted if there is only a single 327 <ds:Signature> element in the pointed-to document. 328

The following schema fragment defines the <Signature>, <Base64Signature>, and 329 <SignaturePtr> elements: 330

<xs:element name="Signature"> 331 <xs:complexType> 332 <xs:choice> 333 <xs:element ref="ds:Signature"/> 334 <xs:element ref="dss:Base64Signature"/> 335 <xs:element ref="dss:SignaturePtr"/> 336 <xs:any processContents="lax"/> 337 </xs:choice> 338 </xs:complexType> 339 </xs:element> 340 341 <xs:element name="Base64Signature"> 342 <xs:complexType> 343 <xs:simpleContent> 344 <xs:extension base="xs:base64Binary"> 345 <xs:attribute name="MimeType" type="xs:string"/> 346 </xs:extension> 347 </xs:simpleContent> 348 </xs:complexType> 349 </xs:element> 350 351 <xs:element name="SignaturePtr"> 352 <xs:complexType> 353 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 354 <xs:attribute name="XPath" type="xs:string"/> 355 </xs:complexType> 356 </xs:element> 357


2.6 Elements <Options> and <Outputs> 358

All request messages can contain an <Options> element, and all response messages can 359 contain an <Outputs> element. The <Options> contains all options about the request. 360 Profiles will specify which options are allowed and what their default values are. All options 361 SHOULD have some default value, so that a client may omit the <Options> element yet still get 362 service from any DSS server. If a server doesn’t recognize or can’t handle any option, it MUST 363 reject the request outright. Options can appear in any order within the <Options> element. 364

The <Outputs> element contains additional protocol outputs. The client MAY request the server 365 to respond with certain outputs by sending certain options. The server MAY also respond with 366 outputs the client didn’t request, depending on the server’s profile and policy. Outputs can 367 appear in any order within the <Outputs> element. 368

The following schema fragment defines the <Options> and <Outputs> elements: 369

<xs:element name="Options" type="dss:AnyType"/> 370 371 <xs:element name="Outputs" type="dss:AnyType"/> 372

2.7 Element <Result> 373

The <Result> element is returned with every response message. It contains the following 374 elements: 375

<ResultMajor> [Required] 376

The most significant component of the result code. 377

<ResultMinor> [Optional] 378

The least significant component of the result code. 379

<ResultMessage> [Optional] 380

A message which MAY be returned to an operator. 381

The following schema fragment defines the <Result> element: 382

<xs:element name="Result"> 383 <xs:complexType> 384 <xs:sequence> 385 <xs:element name="ResultMajor" type="xs:QName"/> 386 <xs:element name="ResultMinor" type="xs:QName" 387 minOccurs="0"/> 388 <xs:element name="ResultMessage" type="xs:string" 389 minOccurs="0"/> 390 </xs:sequence> 391 </xs:complexType> 392 </xs:element> 393

394

The <ResultMajor> and <ResultMinor> elements each contain an XML Schema QName. A 395 namespace prefix MUST be provided. The <ResultMajor> QName MUST be one of these 396 values: 397

Success 398

The protocol executed succesfully. 399 Requester 400

The request could not be performed due to an error on the part of the requester. 401


Responder 402

The request could not be performed due to an error on the part of the responder. 403

The <ResultMinor> QName may be a value defined by this specification, or a value defined by 404 some other specification, in some other namespace. 405

The Requester <ResultMajor> code may be followed by: 406

NotAuthorized 407

The client is not authorized to perform the request. 408 NotSupported 409

The server didn’t recognize or doesn’t support some aspect of the request. 410

The Success <ResultMajor> code on a verify response message SHALL be followed by a 411 <ResultMinor> code which indicates the status of the signature. See section 4 for details. 412


3 The DSS Signing Protocol 413

3.1 Element <SignRequest> 414

The <SignRequest> element is sent by the client to request a signature on some input 415 documents. It contains the following elements and attributes: 416

<Options> [Optional] 417

This element contains all options about the request. 418

<InputDocuments> [Required] 419

A lists of input documents which the signature will be calculated over. 420

RequestID [Optional] 421

This attribute is used to correlate requests with responses. When present in a request, the 422 server MUST return it in the response. 423

The following schema fragment defines the <SignRequest> element: 424

<xs:element name="SignRequest"> 425 <xs:complexType> 426 <xs:sequence> 427 <xs:element ref="dss:Options" minOccurs="0"/> 428 <xs:element ref="dss:InputDocuments"/> 429 </xs:sequence> 430 <xs:attribute name="RequestID" type="xs:string" 431 use="optional"/> 432 </xs:complexType> 433 </xs:element> 434

3.2 Element <SignResponse> 435

The <SignResponse> element contains: 436

<Result> [Required] 437

A code representing the status of the request. 438

<Signature> [Optional] 439

The resultant signature, if the request succeeds. 440

<Outputs> [Optional] 441

Any additional outputs returned by the server. 442



The following schema fragment defines the <SignResponse> element: 446

447

448

449

450


<xs:element name="SignResponse"> 451 <xs:complexType> 452 <xs:sequence> 453 <xs:element ref="dss:Result"/> 454 <xs:element ref="dss:Signature" minOccurs="0"/> 455 <xs:element ref="dss:Outputs" minOccurs="0"/> 456 </xs:sequence> 457 <xs:attribute name="RequestID" type="xs:string" 458 use="optional"/> 459 </xs:complexType> 460 </xs:element> 461

3.3 Basic Processing 462

With no options, a server receiving a <SignRequest> proceeds as follows: 463

1. The server hashes each input <Document>. 464

2. The server forms a <ds:Reference> for each input document out of its RefURI, RefType, 465 <ds:Transforms>, and hash value. 466

3. The server forms a <ds:SignedInfo> out of the <ds:Reference> elements. 467

4. The server forms a <ds:Signature> by signing the <ds:SignedInfo>. 468

5. The server returns the <ds:Signature>. 469

Additional processing may be carried out as specified by the options, or as implied by the profile 470 the server is operating under. 471

3.3.1 Enveloping Signatures 472

To create an XML Signature that envelopes one or more of the input documents, the client simply 473 splices the appropriate input document(s) into the returned <ds:Signature>. 474

3.3.2 Enveloped Signatures 475

To create an XML Signature that is enveloped by one of the input documents, the client simply 476 indicates an Enveloped Signature Transform [XMLSig] on the appropriate input document, and 477 splices the returned <ds:Signature> into the Input Document. 478

3.4 Options and Outputs 479

This document defines some options and outputs that might be useful in multiple profiles. 480 Profiles can define their own options and outputs, as well. Handling of these is discussed in 2.5. 481

3.4.1 Option <ServiceProfile> 482

The <ServiceProfile> element indicates a particular profile. This may be used to select a 483 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 484 implements the profile the client thinks he does. 485

The following schema fragment defines the <ServiceProfile> element: 486

<xs:element name="ServiceProfile" type="xs:anyURI"/> 487


3.4.2 Option <ServicePolicy> 488

The <ServicePolicy> element indicates a particular policy associated with the DSS service. 489 The policy may include information on the characteristics of the server that are not necessarily 490 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 491 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 492 server implements the policy the client thinks he does. 493

The following schema fragment defines the <ServicePolicy> element: 494

<xs:element name="ServicePolicy" type="xs:anyURI"/> 495

3.4.3 Option <ClaimedIdentity> 496

The <ClaimedIdentity> element indicates the identity of the client who is requesting the 497 signature. The server should check this against the client’s authentication credentials, and then 498 may use this to parameterize any aspect of its processing. 499

The following schema fragment defines the <ClaimedIdentity> element: 500

<xs:element name="ClaimedIdentity" type="dss:NameType"/> 501

3.4.4 Options <SignatureTimestamp> and <ContentTimestamp> 502

The <SignatureTimestamp> and <ContentTimestamp> elements are boolean flags that 503 indicate the client wishes the server to provide the appropriate type of timestamp as a signature 504 attribute. Both flags may be present simultaneously. 505

The following schema fragment defines both elements: 506

<xs:element name="SignatureTimestamp"/> 507 <xs:element name="ContentTimestamp"/> 508

3.4.5 Option <IntendedAudience> 509

The <IntendedAudience> element tells the server who the signature is meant for. 510

The following schema fragment defines the <IntendedAudience> element: 511

<xs:element name="IntendedAudience"> 512 <xs:complexType> 513 <xs:sequence> 514 <xs:element name="Recipient" type="dss:NameType" 515 maxOccurs="unbounded"/> 516 </xs:sequence> 517 </xs:complexType> 518 </xs:element> 519

3.4.6 Option <KeySelector> 520

The <KeySelector> element tells the server which key to use. 521

The following schema fragment defines the <KeySelector> element: 522

<xs:element name="KeySelector"> 523 <xs:complexType> 524 <xs:sequence> 525 <xs:element ref="ds:KeyInfo"/> 526 </xs:sequence> 527


</xs:complexType> 528 </xs:element> 529

3.4.7 Option <SignedReferences> 530

The <SignedReferences> element gives the client greater control over how the 531 <ds:Reference> elements are formed. When this element is present, the second step of 532 “Basic Processing” is overridden, and instead each <SignedReference> element within 533 <SignedReferences> controls the creation of a corresponding <ds:Reference>. Each 534 <SignedReference> element contains: 535


Which input document this reference refers to. 537

<RefId> [Optional] 538

Sets the Id attribute on the corresponding <ds:Reference>. 539

<ds:Transforms> [Optional] 540

Requests the server to perform additional transforms on this reference. 541

The following schema fragment defines the <SignedReferences> element: 542

<xs:element name="SignedReferences"> 543 <xs:complexType> 544 <xs:sequence> 545 <xs:element ref="dss:SignedReference" minOccurs="0"/> 546 </xs:sequence> 547 </xs:complexType> 548 </xs:element> 549 550 <xs:element name="SignedReference"> 551 <xs:complexType> 552 <xs:sequence> 553 <xs:element ref="ds:Transforms" minOccurs="0"/> 554 </xs:sequence> 555 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 556 <xs:attribute name="RefId" type="xs:string" use="optional"/> 557 </xs:complexType> 558 </xs:element> 559

3.4.8 Option <Properties> 560

The <Properties> element is used to request that the server add certain signed or unsigned 561 properties (aka “attributes”) into the signature. The client can send the server a particular value 562 to use for each property, or leave that up to the server to determine. The <Properties> 563 element contains: 564

<SignedProperties> [Optional] 565

These properties will be covered by the signature. 566

<UnsignedProperties> [Optional] 567

These properties will not be covered by the signature. 568

569

570

571


Each <Property> element contains: 572

<Identifier> [Required] 573

A QName identifying the property. 574

<Value> [Optional] 575

If present, the value the server should use for the property. 576

The following schema fragment defines the <Properties> element: 577

<xs:element name="Properties"> 578 <xs:complexType> 579 <xs:sequence> 580 <xs:element name="SignedProperties" 581 type="dss:PropertiesType" minOccurs="0"/> 582 <xs:element name="UnsignedProperties" 583 type="dss: PropertiesType" minOccurs="0"/> 584 </xs:sequence> 585 </xs:complexType> 586 </xs:element> 587 588 <xs:complexType name="PropertiesType"> 589 <xs:sequence> 590 <xs:element ref="dss:Property" maxOccurs="unbounded"/> 591 </xs:sequence> 592 </xs:complexType> 593 594 <xs:element name="Property"> 595 <xs:complexType> 596 <xs:sequence> 597 <xs:element name="Identifier" type="xs:QName"/> 598 <xs:element name="Value" type="dss:AnyType"/> 599 </xs:sequence> 600 </xs:complexType> 601 </xs:element> 602

3.4.9 Option <SignaturePlacement> and Output <OutputDocument> 603

The <SignaturePlacement> element instructs the server to place the signature inside one of 604 the input documents, and return the resulting document. The <SignaturePlacement> element 605 contains the following attributes and elements: 606


Identifies the input document which the signature will be inserted into. 608

<XPathAfter> [Optional] 609

Identifies an element, in the input document, which the signature will be inserted after. 610

<XPathFirstChildOf> [Optional] 611

Identifies an element, in the input document, which the signature will be inserted as the first 612 child of. 613

The <OutputDocument> element contains the XML input document with the signature inserted. 614 It has one child element: 615

<XMLData> [Optional] 616

This contains arbitrary XML content. 617

618


The following schema fragment defines the <SignaturePlacement> and <OutputDocument> 619 elements: 620

<xs:element name="SignaturePlacement"> 621 <xs:complexType> 622 <xs:choice> 623 <xs:element name="XPathAfter" type="xs:string"/> 624 <xs:element name="XPathFirstChildOf" type="xs:string"/> 625 </xs:choice> 626 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 627 </xs:complexType> 628 </xs:element> 629 630 <xs:element name="OutputDocument"> 631 <xs:complexType> 632 <xs:sequence> 633 <xs:element ref="XMLData"/> 634 <xs:sequence> 635 </xs:complexType> 636 </xs:element> 637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652


4 The DSS Verifying Protocol 653

4.1 Element <VerifyRequest> 654

The <VerifyRequest> element is sent by the client to verify a signature on some input 655 documents. It contains the following elements and attributes: 656

<Options> [Optional] 657

This element contains all options about the request. 658

<Signature> [Required] 659

This element contains a signature or points to an XML Signature in one of the Input 660 Documents. 661

<InputDocuments> [Required] 662

A lists of input documents which the signature was calculated over. 663



The following schema fragment defines the <VerifyRequest> element: 667

<xs:element name="VerifyRequest"> 668 <xs:complexType> 669 <xs:sequence> 670 <xs:element ref="dss:Options" minOccurs="0"/> 671 <xs:element ref="dss:Signature" minOccurs="0"/> 672 <xs:element ref="dss:InputDocuments"/> 673 </xs:sequence> 674 <xs:attribute name="RequestID" type="xs:string" 675 use="optional"/> 676 </xs:complexType> 677 </xs:element> 678

4.2 Element <VerifyResponse> 679

The <VerifyResponse> element contains: 680

<Result> [Required] 681

A code representing the status of the corresponding request. 682

<Outputs> [Optional] 683

Any outputs that were requested by the presence of a corresponding option in the 684 <VerifyRequest> message. 685



The following schema fragment defines the <VerifyResponse> element: 689

690

691


<xs:element name="VerifyResponse"> 692 <xs:complexType> 693 <xs:sequence> 694 <xs:element ref="dss:Result"/> 695 <xs:element ref="dss:Outputs" minOccurs="0"/> 696 </xs:sequence> 697 <xs:attribute name="RequestID" type="xs:string" 698 use="optional"/> 699 </xs:complexType> 700 </xs:element> 701

4.3 Basic Processing 702

With no options, a server receiving a <VerifyRequest> proceeds as follows: 703

1. The server dereferences the <Signature> element to retrieve the [XMLSig] signature. 704

2. For each <ds:Reference> in the signature, the server finds the input document with 705 matching RefURI and RefType values. 706

3. If the input document is a <DocumentHash>, the server checks that the 707 <ds:Transforms>, <ds:DigestMethod>, and <ds:DigestValue> elements match 708 between the <DocumentHash> and the <ds:Reference>. 709

4. If the input document is a <Document>, the server applies any transforms specified by the 710 <ds:Reference>, and then hashes the resultant data object according to 711 <ds:DigestMethod>, and checks that the result matches <ds:DigestValue>. 712

5. The server then validates the signature according to section 3.2.2 in [XMLSig]. 713

Additional processing may be carried out as specified by the options, or as implied by the profile 714 the server is operating under. 715

4.4 Result Codes 716

Whether the signature succeeds or fails to verify, the server will return the Success 717 <ResultMajor> code. The <ResultMinor> QName must be one of the following values, or 718 some other value defined by some profile of this specification: 719

ValidSignature 720

The signature is valid. 721

IndeterminateKey 722

The server could not determine whether the signing key is valid. For example, the server 723 might not have been able to construct a certificate path to the signing key. 724

UntrustedKey 725

The signature is performed by a key the server considers suspect. For example, the signing 726 key may have been revoked, or it may be a different key from what the server is expecting the 727 signer to use. 728

IncorrectSignature 729

The signature fails to verify, indicating that the message was modified in transit, or that the 730 signature was performed incorrectly. 731

732

733


4.5 Options and Outputs 734

This document defines some options and outputs that might be useful in multiple profiles. 735 Profiles can define their own options and outputs, as well. 736

4.5.1 Option <ServiceProfile> 737

The <ServiceProfile> element indicates a particular profile. This may be used to select a 738 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 739 implements the profile the client thinks he does. 740

The following schema fragment defines the <ServiceProfile> element: 741

<xs:element name="ServiceProfile" type="xs:anyURI"/> 742

4.5.2 Option <ServicePolicy> 743

The <ServicePolicy> element indicates a particular policy associated with the DSS service. 744 The policy may include information on the characteristics of the server that are not necessarily 745 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 746 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 747 server implements the policy the client thinks he does. 748

The following schema fragment defines the <ServicePolicy> element: 749

<xs:element name="ServicePolicy" type="xs:anyURI"/> 750

4.5.3 Option <ClaimedIdentity> 751

The <ClaimedIdentity> element indicates the identity of the client who is requesting the 752 verification. The server should check this against the client’s authentication credentials, and then 753 may use this to parameterize any aspect of its processing. 754

The following schema fragment defines the <ClaimedIdentity> element: 755

<xs:element name="ClaimedIdentity" type="dss:NameType"/> 756

4.5.4 Option <IgnoreMissingInputDocuments> 757

The presence of this element instructs the server not to give an error if he can’t find an input 758 document that matches a particular <ds:Reference>, but instead to assume that the client has 759 already validated this <ds:Reference> himself. 760

The following schema fragment defines the <IgnoreMissingInputDocuments> element: 761

<xs:element name="IgnoreMissingInputDocuments"/> 762

4.5.5 Option <VerifyManifests> 763

The presence of this element instructs the server to attempt to validate any input documents it 764 encounters whose Type attribute equals 765 http://www.w3.org/2000/09/xmldsig#Manifest. Such an input document MUST 766 contain an XML element of type ds:ManifestType. On encountering such a document in step 2 767 of basic processing, the server should repeat step 2 for all the <ds:Reference> elements within 768 the manifest. 769

770


The following schema fragment defines the <VerifyManifests> element: 771

<xs:element name="VerifyManifests"/> 772

4.5.6 Option <VerificationTime> 773

This element instructs the server to attempt to determine the signature’s validity at the specified 774 time, instead of the current time. 775

The following schema fragment defines the <VerificationTime> element: 776

<xs:element name="VerificationTime" type="xs:dateTime"/> 777

4.5.7 Option <AdditionalKeyInfo> 778

This element provides the server with additional data (such as certificates and CRLs) which it can 779 use to validate the signing key. 780

The following schema fragment defines the <AdditionalKeyInfo> element: 781

<xs:element name="AdditionalKeyInfo"> 782 <xs:complexType> 783 <xs:sequence> 784 <xs:element ref="ds:KeyInfo"/> 785 </xs:sequence> 786 </xs:complexType> 787 </xs:element> 788

4.5.8 Option <ReturnProcessingDetails> and Output 789

<ProcessingDetails> 790

The presence of the <ReturnProcessingDetails> option instructs the server to return a 791 <ProcessingDetails> output, elaborating on what signature verification steps succeeded or 792 failed. The <ProcessingDetails> element may contain the following child elements: 793

<ValidDetail> [Any Number] 794

A verification aspect that was evaluated and found to be valid. 795

<IndeterminateDetail> [Any Number] 796

A verification aspect that could not be evaluated or was evaluated and returned an 797 indeterminate result. 798

<InvalidDetail> [Any Number] 799

A verification aspect that was evaluated and found to be invalid. 800

These elements each contains an XML Schema QName which identifies the detail. A 801 namespace prefix for the QName MUST be provided. The QName may be a value defined by 802 this specification, or a value defined by some other specification, in some other namespace. The 803 values defined by this specification are the following, interpreted as per [XKMS] section 5.18: 804 IssuerTrust, RevocationStatus, ValidityInterval, Signature. 805

The following schema fragment defines the <ReturnProcessingDetails> and 806 <ProcessingDetails> elements: 807

808

809

810


<xs:element name="ReturnProcessingDetails"> 811 812 <xs:element name="ProcessingDetails"> 813 <xs:complexType> 814 <xs:sequence> 815 <xs:element name="ValidDetail" type="xs:QName" 816 minOccurs="0" maxOccurs="unbounded"/> 817 <xs:element name="IndeterminateDetail" type="xs:QName" 818 minOccurs="0" maxOccurs="unbounded"/> 819 <xs:element name="InvalidDetail" type="xs:QName" 820 minOccurs="0" maxOccurs="unbounded"/> 821 </xs:sequence> 822 </xs:complexType> 823 </xs:element> 824

4.5.9 Option <ReturnSigningTime> and Output <SigningTime> 825

The presence of the <ReturnSigningTime> option instructs the server to return a 826 <SigningTime> output. This output contains an indication of when the signature was 827 performed, and a boolean attribute that indicates whether this value should be relied upon or not. 828

The following schema fragment defines the <ReturnSigningTime> and <SigningTime> 829 elements: 830

<xs:element name="ReturnSigningTime"/> 831 832 <xs:element name="SigningTime"> 833 <xs:complexType> 834 <xs:simpleContent> 835 <xs:extension base="xs:dateTime"> 836 <xs:attribute name="Trusted" type="xs:boolean"/> 837 </xs:extension> 838 </xs:simpleContent> 839 </xs:complexType> 840 </xs:element> 841

4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> 842

The presence of the <ReturnSignerIdentity> option instructs the server to return a 843 <SignerIdentity> output. This output contains an indication of who performed the signature. 844

The following schema fragment defines the <ReturnSignerIdentity> and 845 <SignerIdentity> elements: 846

<xs:element name="ReturnSignerIdentity"/> 847 848 <xs:element name="SignerIdentity" type="dss:Name"/> 849

4.5.11 Option <ReturnUpdatedSignature> and Output 850

<UpdatedSignature> 851

The presence of the <ReturnUpdatedSignature> option instructs the server to return an 852 <UpdatedSignature> output. This output contains the original signature with some additional 853 attributes added to it. 854

The following schema fragment defines the <ReturnUpdatedSignature> and 855 <UpdatedSignature> elements: 856


<xs:element name="ReturnUpdatedSignature"/> 857 858 <xs:element name="UpdatedSignature"> 859 <xs:complexType> 860 <xs:element ref="dss:Signature"> 861 </xs:complexType> 862 </xs:element> 863

864

865


5 Timestamp token 866

This section contains the definition of the timestamp token. 867

5.1 Schema Header and Namespace Declarations 868

The following schema fragment defines the XML namespaces and other header information for 869 the DSS schema: 870

<xs:schema 871 targetNamespace="http://www.oasis-open.org/tc/DSS/1.0/timestamp-872 token/schema" 873 xmlns:tst="http://www.oasis-open.org/tc/DSS/1.0/timestamp-874 token/schema" 875 xmlns:xs="http://www.w3.org/2001/XMLSchema" 876 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 877 elementFormDefault="qualified" 878 attributeFormDefault="unqualified"> 879

This schema imports definitions from the XML Digital Signature schema. 880

5.2 Element <Tst> 881

The <Tst> element represents a single timestamp token. 882

<xs:element name="Tst" type="ds:SignatureType"> 883

The <Tst> element has the same type-definition as the ds:SignatureType definition. In this 884 way, a timestamp token can be created and validated by a conventional XML Digital Signature 885 implementation. 886

The following sections define how the elements of the <ds:Signature> element MUST be 887 used. 888

ds:KeyInfo/ [Required] 889

The <KeyInfo> element SHALL identify the issuer of the timestamp and MAY be used 890 to locate, retrieve and validate the timestamp token signature-verification key. 891

ds:SignedInfo/Reference [Required] 892

The <Reference> element SHALL contain a bare name XPointer reference to the 893 <tstInfo> element. It MUST also reference the document or documents that are 894 timestamped. 895

ds:Object/ [Required] 896

The <TstInfo> element SHALL be contained in an <Object> element. Any extension 897 elements that are not defined by this specification SHALL also be represented as 898 <Object> elements. 899

5.3 Element <TstInfo> 900

A <TstInfo> element MUST be included in the <Tst> element as a 901 <ds:Signature/Object> element. The <TstInfo> element is of type tstInfoType. 902

<xs:element name="TstInfo" type="tst:TstInfoType"> 903


5.4 ComplexType TstInfoType 904

This section contains the definition of the tstInfoType complex type. 905

<xs:complexType name="TstInfoType"> 906 <xs:attribute name="SerialNumber" type="xs:integer"/> 907 <xs:attribute name="CreationTime" type="xs:dateTime"/> 908 <xs:attribute name="Policy" type="xs:anyURI" use="optional"/> 909 <xs:attribute name="ErrorBound" type="xs:duration"/> 910 <xs:attribute name="Ordered" type="xs:boolean" default="false"/> 911 </xs:complexType> 912

Defines the following attributes. 913

SerialNumber [Required] 914

This attribute SHALL contain a serial number produced by the timestamp authority. It 915 MUST be unique across all the tokens issued by a particular TSA. Provided relying 916 parties do not accept timestamp tokens from distinct TSAs that use the same name, the 917 combination of the issuer name and the serial number will uniquely identify a timestamp 918 token to a particular relying party. 919

CreationTime [Required] 920

The time at which the token was issued. It SHALL be a time according to the local clock 921 of the authority, no earlier than the time at which the request was completely received 922 and no later than the time at which the signature process was started. 923

Policy [Optional] 924

This attribute SHALL identify the policy under which the token was issued. If the 925 corresponding element appears in the request, then this element MUST contain one of 926 the values supplied in the request. Amongst other things, the TSA’s policy SHOULD 927 identify the fundamental source of its time. 928

ErrorBound [Optional] 929

The TSA’s estimate of the maximum error in its local clock. 930

Ordered [Default=”false”] 931

This attribute SHALL indicate whether or not timestamps issued by this TSA, under this 932 policy, are strictly ordered according to the value and precision of the creationTime 933 attribute value. 934

5.5 Timestamp verification procedure 935

If any one of these steps results in failure, then the timestamp token SHOULD be rejected. 936

1. Locate and verify the signature-verification key corresponding to the ds:KeyInfo/ 937 element contents. 938

2. Verify that the signature-verification key is authorized for verifying timestamps. 939

3. Verify that the signature-verification key conforms with all relevant aspects of the relying-940 party’s policy. 941

4. Verify that all digest and signature algorithms conform with the relying-party’s policy. 942

5. Verify that the signature-verification key is consistent with the 943 ds:SignedInfo/SignatureMethod/@Algorithm attribute value. 944

6. Verify that there is a ds:SignedInfo/Reference/@URI attribute whose value is 945 “#tstInfo”. 946


7. Verify that there is a ds:SignedInfo/Reference/@ attribute that correctly identifies 947 the timestamped document. 948

8. Verify that the tstInfo/@policy attribute value is acceptable. 949

9. Establish a maximum acceptable error bound value and verify that the 950 tstInfo/@errorBound attribute value is less than or equal to this value. 951

10. Verify all digests and the signature. 952

11. If comparing the tstInfo/@creationTime attribute value to another time value, first 953 verify that they differ by more than the maximum acceptable error bound value. 954


6 Editorial Issues 955

1) Another way of handling the options is to have each option placed within an <Option> 956 element. This has the advantage that each option could be tagged with a 957 mustUnderstand attribute, so the server would know whether it was okay to ignore the 958 option or not. It has the disadvantage of making things a little more verbose. 959

Resolution: Leave as is, per 10/20/2003 meeting. 960

2) It is suggested that the RequestID option be put in the top level of the protocol structure 961 so that it can be used at the basic level of the DSS protocol handler. 962

Resolution: This has been done, per 10/20/2003 meeting. 963

3) The utility of the <DocumentURI> element has been questioned. 964

Resolution: Since Rich, John, Trevor, and perhaps Andreas seem in favor of removing 965 this, and only Gregor and Juan Carlos, and perhaps Nick, seem in favor of keeping it, it’s 966 been removed. 967

4) Should every Output only be returned if the client requests it, through an Option? 968

Resolution: No - Servers can return outputs on their own initiative, per 11/3/2003 969 meeting. 970

5) Should Signature Placement, and elements to envelope, be made Signature Options? 971

Resolution: Yes - per 11/3/2003 meeting, but hasn’t been done yet. 972

6) Should <Options> be renamed? To <AdditionalInputs>, <Inputs>, <Parameters>, or 973 something else? 974

7) Should we adopt a Timestamp more like Dimitri’s <Tst>? 975

8) The <ProcessingDetails> are a little sketchy, these could be fleshed out. 976

9) A <dss:Signature> can contain a <dss:SignaturePtr>, which uses an XPath expression to 977 point to a signature. This allows a client to send an <InputDocument> to the server with 978 an embedded signature, and just point to the signature, without copying it. Is it 979 acceptable to require all servers to support XPath, for this? 980

981

982

983

984


7 References 985

7.1 Normative 986

[CMS] R. Housley. Cryptographic Message Syntax. IETF RFC 3369, August 2002. 987 http://www.ietf.org/rfc/rfc2459.txt. 988

[Core-XSD] T. Perrin et al. DSS Schema. 989 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 990

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 991 [XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide 992

Web Consortium, February 2003. http://www.w3.org/TR/xmldsig-core. 993 [XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 994

http://w3.org/TR/2000/CR-xmldsig-core-200001031/xmldsig-core-995 schema.xsd. 996

[Excl-C14N] J. Boyer et al. Exclusive XML Canonicalization Version 1.0. World Wide 997 Web Consortium, July 2002. http://www.w3.org/TR/xml-exc-c14n/. 998

[PGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer. OpenPGP Message 999 Format. IETF RFC 2440, November 1998. 1000 http://www.ietf.org/rfc/rfc2440.txt. 1001

[PKIX] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key 1002 Infrastructure Certificate and CRL Profile. IETF RFC 2459, January 1999. 1003 http://www.ietf.org/rfc/rfc2459.txt. 1004

[RFC 2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 1005 1999. http://www.ietf.org/rfc/rfc2246.txt. 1006

[RFC 2396] T. Berners-Lee et al. Uniform Resource Identifiers (URI): Generic Syntax. 1007 IETF RFC 2396, August, 1998. http://www.ietf.org/rfc/rfc2396.txt. 2000 1008

[RFC 2630] R. Housley. Cryptographic Message Syntax. IETF RFC 2630, June 1999. 1009 http://www.ietf.org/rfc/rfc2630.txt. 1010

[RFC 2822] P. Resnick. Internet Message Format. IETF RFC 2822, April 2001. 2003 1011 http://www.ietf.org/rfc/rfc2822.txt. 2004 1012

[RFC 2945] T. Wu. The SRP Authentication and Key Exchange System. IETF RFC 2945 1013 September 2000. http://www.ietf.org/rfc/rfc2945.txt. 1014

[RFC 3075] D. Eastlake, J. Reagle, D. Solo. XML-Signature Syntax and Processing. 1015 IETF RFC 3075, March 2001. http://www.ietf.org/rfc/rfc3075.txt. 1016

[SAMLCore1.0] E. Maler et al. Assertions and Protocol for the OASIS Security Assertion 1017 Markup Language (SAML). OASIS, November 2002. http://www.oasis- 1018 open.org/committees/download.php/1371/oasis-sstc-saml-core-1.0.pdf. 1019

[Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web 1020 Consortium Recommendation, May 2001. 1021 http://www.w3.org/TR/xmlschema-1/. 1022

[Schema2] P. V. Biron et al. XML Schema Part 2: Datatypes. World Wide Web 1023 Consortium Recommendation, May 2001. 1024 http://www.w3.org/TR/xmlschema-2/. 1025

[UNICODE-C] M. Davis, M. J. Dürst. Unicode Normalization Forms. UNICODE 1026 Consortium, March 2001. 1027 http://www.unicode.org/unicode/reports/tr15/tr15-21.html. 1028

[W3C-CHAR] M. J. Dürst. Requirements for String Identity Matching and String Indexing. 1029 World Wide Web Consortium, July 1998. http://www.w3.org/TR/WD-1030 charreq. 1031


[W3C-CharMod] M. J. Dürst. Character Model for the World Wide Web 1.0. World Wide Web 1032 Consortium, April 2002. http://www.w3.org/TR/charmod/. 1033

1034 [XKMS] W. Ford, P. Hallam-Baker, B. Fox, B. Dillaway, B. LaMacchia, J. Epstein, 1035

J. Lapp. XML Key Management Specification (XKMS). W3C Note 30 1036 March 2001. http://www.w3.org/TR/xkms/. 1037

[XML] T. Bray, et al. Extensible Markup Language (XML) 1.0 (Second Edition). 1038 World Wide Web Consortium, October 2000. http://www.w3.org/TR/REC-1039 xml. 1040

[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide Web 1041 Consortium, February 2002. http://www.w3.org/TR/xmldsig-core/. 1042

[XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 1043 http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-1044 schema.xsd. 1045

1046 1047 1048

1049


Appendix A. Revision History 1050

Rev Date By Whom What

wd-01 2003-10-03 Trevor Perrin Initial version

wd-02 2003-10-13 Trevor Perrin Skeleton of verify as well

wd-03 2003-10-19 Trevor Perrin Added TimeStampToken, References

wd-04 2003-10-29 Trevor Perrin Fleshed things out

wd-05 2003-11-9 Trevor Perrin Added Name, clarified options-handling

wd-06 2003-11-12 Trevor Perrin Added more options/outputs


Appendix B. Notices 1051

OASIS takes no position regarding the validity or scope of any intellectual property or other rights 1052 that might be claimed to pertain to the implementation or use of the technology described in this 1053 document or the extent to which any license under such rights might or might not be available; 1054 neither does it represent that it has made any effort to identify any such rights. Information on 1055 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 1056 website. Copies of claims of rights made available for publication and any assurances of licenses 1057 to be made available, or the result of an attempt made to obtain a general license or permission 1058 for the use of such proprietary rights by implementors or users of this specification, can be 1059 obtained from the OASIS Executive Director. 1060

OASIS invites any interested party to bring to its attention any copyrights, patents or patent 1061 applications, or other proprietary rights which may cover technology that may be required to 1062 implement this specification. Please address the information to the OASIS Executive Director. 1063

Copyright © OASIS Open 2003. All Rights Reserved. 1064

This document and translations of it may be copied and furnished to others, and derivative works 1065 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 1066 published and distributed, in whole or in part, without restriction of any kind, provided that the 1067 above copyright notice and this paragraph are included on all such copies and derivative works. 1068 However, this document itself does not be modified in any way, such as by removing the 1069 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 1070 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 1071 Property Rights document must be followed, or as required to translate it into languages other 1072 than English. 1073

The limited permissions granted above are perpetual and will not be revoked by OASIS or its 1074 successors or assigns. 1075

This document and the information contained herein is provided on an “AS IS” basis and OASIS 1076 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1077 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1078 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1079 PARTICULAR PURPOSE. 1080