security assertions markup language… · web viewspki public key . uri:...

Assertions and Protocol for the OASIS Security Assertion Markup

Language (SAML) Document identifier: draft-sstc-core-3231

Location: http://www.oasis-open.org/committees/security/docs

Publication date: April 10th 2002April 4rd 2002

Maturity Level: Committee Working Draft

Send comments to: [email protected]: Before sending a message to this list you must first subscribe; send an email message to [email protected] with the word "subscribe" as the body of the message.

Editors:Phillip Hallam-Baker, VeriSign,Eve Maler, Sun Microsystems

1

2

3

4

5

6

7

8

91011

121314

1

mailto:[email protected]

ASSERTIONS AND PROTOCOL FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) 1

1. INTRODUCTION 10

1.1. NOTATION 10

1.2. SCHEMA ORGANIZATION AND NAMESPACES 10

1.2.1. String and URI Values 11

1.2.2. Time Values. 11

1.2.3. Comparing SAML values 11

1.3. SAML CONCEPTS (NON-NORMATIVE) 11

1.3.1. Overview 12

1.3.2. SAML and URI-Based Identifiers 13

1.3.3. SAML and Extensibility 13

2. SAML ASSERTIONS 14

2.1. SCHEMA HEADER AND NAMESPACE DECLARATIONS 14

2.2. SIMPLE TYPES 14

2.2.1. Simple Types IDType and IDReferenceType 14

2.2.2. Simple Type DecisionType 15

2.3. ASSERTIONS 15

2.3.1. Element <AssertionID> 15

2.3.2. Element <Assertion> 15

2.3.2.1. Element <Conditions> 17

2.3.2.1.1 Attributes NotBefore and NotOnOrAfter 18

2.3.2.1.2 Element <Condition> 18

2.3.2.1.3 Elements <AudienceRestrictionCondition> and <Audience> 18

2.3.2.2. Elements <Advice> and <AdviceElement> 19

2.4. STATEMENTS 19

2.4.1. Element <Statement> 19

draft-sstc-core-32 2 April 10th 2002March 29th 2002

15

1617

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

2

2.4.2. Element <SubjectStatement> 19

2.4.2.1. Element <Subject> 20

2.4.2.2. Element <NameIdentifier> 20

2.4.2.3. Elements <SubjectConfirmation>, <ConfirmationMethod>, and <SubjectConfirmationData> 21

2.4.3. Element <AuthenticationStatement> 22

2.4.3.1. Element <SubjectLocality> 22

2.4.3.2. Element <AuthorityBinding> 23

2.4.4. Element <AuthorizationDecisionStatement> 23

2.4.4.1. Element <Action> 25

2.4.4.2. Element <Evidence> 25

2.4.5. Element <AttributeStatement> 25

2.4.5.1. Elements <AttributeDesignator> and <Attribute> 26

2.4.5.1.1 Element <AttributeValue> 26

3. SAML PROTOCOL 28


3.2. REQUESTS 28

3.2.1. Complex Type RequestAbstractType 28

3.2.1.1. Element <RespondWith> 29

3.2.2. Element <Request> 29

3.2.3. Element <AssertionArtifact> 30

3.3. QUERIES 30

3.3.1. Element <Query> 30

3.3.2. Element <SubjectQuery> 31

3.3.3. Element <AuthenticationQuery> 31

3.3.4. Element <AttributeQuery> 32

3.3.5. Element <AuthorizationDecisionQuery> 32

3.4. RESPONSES 33

3.4.1. Complex Type ResponseAbstractType 33

3.4.2. Element <Response> 34

3.4.3. Element <Status> 34


4344

45

46

4748

49

5051

52

5354

55

56

57

58

5960

61

62

63

64

65

66

67

68

69

70

71

72

3

3.4.3.1. Element <StatusCode> 35

3.4.3.2. Element <StatusMessage> 36

3.4.3.3. Element <StatusDetail> 36

3.4.4. Responses to <AuthenticationQuery> and <AttributeQuery> 36

4. SAML VERSIONING 37

4.1. ASSERTION VERSION 37

4.2. REQUEST VERSION 37

4.3. RESPONSE VERSION 38

5. SAML & XML-SIGNATURE SYNTAX AND PROCESSING 39

5.1. SIGNING ASSERTIONS 39

5.2. REQUEST/RESPONSE SIGNING 40

5.3. SIGNATURE INHERITANCE 40

5.3.1. Rationale 40

5.3.2. Rules for SAML Signature Inheritance 40

5.4. XML SIGNATURE PROFILE 40

5.4.1. Signing formats 40

5.4.2. CanonicalizationMethod 40

5.4.3. Transforms 41

5.4.4. KeyInfo 41

5.4.5. Binding between statements in a multi-statement assertion 41

6. SAML EXTENSIONS 42

6.1. ASSERTION SCHEMA EXTENSION 42

6.2. PROTOCOL SCHEMA EXTENSION 42

6.3. USE OF TYPE DERIVATION AND SUBSTITUTION GROUPS 43

7. SAML-DEFINED IDENTIFIERS 44


73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

4

7.1. AUTHENTICATION METHOD IDENTIFIERS 44

7.1.1. Password : 44

7.1.2. Kerberos 44

7.1.3. Secure Remote Password (SRP) 44

7.1.4. SSL/TLS Certificate Based Client Authentication: 45

7.1.5. X.509 Public Key 45

7.1.6. PGP Public Key 45

7.1.7. SPKI Public Key 45

7.1.8. XKMS Public Key 45

7.1.9. XML Digital Signature 45

7.2. ACTION NAMESPACE IDENTIFIERS 45

7.2.1. Read/Write/Execute/Delete/Control: 46

7.2.2. Read/Write/Execute/Delete/Control with Negation: 46

7.2.3. Get/Head/Put/Post: 46

7.2.4. UNIX File Permissions: 46

8. SAML SCHEMA LISTINGS 48

8.1. ASSERTION SCHEMA 48

8.2. PROTOCOL SCHEMA 51

9. REFERENCES 54

10. ACKNOWLEDGEMENTS 56

APPENDIX A. NOTICES 58

ASSERTIONS AND PROTOCOL FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) 1

1. INTRODUCTION 10

1.1. NOTATION 10


98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119120

121

122

5

1.2. SCHEMA ORGANIZATION AND NAMESPACES 10

1.2.1. String and URI Values 11

1.2.2. Time Values. 11

1.2.3. Comparing SAML values 11

1.3. SAML CONCEPTS (NON-NORMATIVE) 11

1.3.1. Overview 12

1.3.2. SAML and URI-Based Identifiers 13

1.3.3. SAML and Extensibility 13

2. SAML ASSERTIONS 14


2.2. SIMPLE TYPES 14

2.2.1. Simple Types IDType and IDReferenceType 14

2.2.2. Simple Type DecisionType 15

2.3. ASSERTIONS 15

2.3.1. Element <AssertionID> 15

2.3.2. Element <Assertion> 15

2.3.2.1. Element <Conditions> 17

2.3.2.1.1 Attributes NotBefore and NotOnOrAfter 18

2.3.2.1.2 Element <Condition> 18

2.3.2.1.3 Elements <AudienceRestrictionCondition> and <Audience> 18

2.3.2.2. Elements <Advice> and <AdviceElement> 19

2.4. STATEMENTS 19

2.4.1. Element <Statement> 19

2.4.2. Element <SubjectStatement> 19

2.4.2.1. Element <Subject> 20

2.4.2.2. Element <NameIdentifier> 20

2.4.2.3. Elements <SubjectConfirmation>, <ConfirmationMethod>, and <SubjectConfirmationData> 21

2.4.3. Element <AuthenticationStatement> 22

2.4.3.1. Element <SubjectLocality> 22

2.4.3.2. Element <AuthorityBinding> 23


123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138139

140

141

142

143

144

145

146147

148

149

150151

152

6

2.4.4. Element <AuthorizationDecisionStatement> 23

2.4.4.1. Element <Action> 25

2.4.4.2. Element <Evidence> 25

2.4.5. Element <AttributeStatement> 25

2.4.5.1. Elements <AttributeDesignator> and <Attribute> 26

2.4.5.1.1 Element <AttributeValue> 26

3. SAML PROTOCOL 28


3.2. REQUESTS 28

3.2.1. Complex Type RequestAbstractType 28

3.2.1.1. Element <RespondWith> 29

3.2.2. Element <Request> 29

3.2.3. Element <AssertionArtifact> 30

3.3. QUERIES 30

3.3.1. Element <Query> 30

3.3.2. Element <SubjectQuery> 31

3.3.3. Element <AuthenticationQuery> 31

3.3.4. Element <AttributeQuery> 32

3.3.5. Element <AuthorizationDecisionQuery> 32

3.4. RESPONSES 33

3.4.1. Complex Type ResponseAbstractType 33

3.4.2. Element <Response> 34

3.4.3. Element <Status> 34

3.4.3.1. Element <StatusCode> 35

3.4.3.2. Element <StatusMessage> 36

3.4.3.3. Element <StatusDetail> 36

3.4.4. Responses to <AuthenticationQuery> and <AttributeQuery> 36

4. SAML VERSIONING 38

4.1. ASSERTION VERSION 38


153154

155

156157

158

159

160

161

162163

164

165

166

167

168

169

170

171

172

173

174

175176

177

178

179

180

181

7

4.2. REQUEST VERSION 38

4.3. RESPONSE VERSION 39

5. SAML & XML-SIGNATURE SYNTAX AND PROCESSING 40

5.1. SIGNING ASSERTIONS 40

5.2. REQUEST/RESPONSE SIGNING 41

5.3. SIGNATURE INHERITANCE 41

5.3.1. Rationale 41

5.3.2. Rules for SAML Signature Inheritance 41

5.4. XML SIGNATURE PROFILE 41

5.4.1. Signing formats 41

5.4.2. CanonicalizationMethod 41

5.4.3. Transforms 42

5.4.4. KeyInfo 42

5.4.5. Binding between statements in a multi-statement assertion 42

6. SAML EXTENSIONS 43

6.1. ASSERTION SCHEMA EXTENSION 43

6.2. PROTOCOL SCHEMA EXTENSION 43

6.3. USE OF TYPE DERIVATION AND SUBSTITUTION GROUPS 44

7. SAML-DEFINED IDENTIFIERS 45

7.1. AUTHENTICATION METHOD IDENTIFIERS 45

7.1.1. Password : 46

7.1.2. Kerberos 46

7.1.3. Secure Remote Password (SRP) 47

7.1.4. SSL/TLS Certificate Based Client Authentication: 47

7.1.5. X.509 Public Key 47


182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

8

7.1.6. PGP Public Key 47

7.1.7. SPKI Public Key 47

7.1.8. XKMS Public Key 47

7.1.9. XML Digital Signature 48

7.2. ACTION NAMESPACE IDENTIFIERS 48

7.2.1. Read/Write/Execute/Delete/Control: 48

7.2.2. Read/Write/Execute/Delete/Control with Negation: 49

7.2.3. Get/Head/Put/Post: 49

7.2.4. UNIX File Permissions: 49

8. SAML SCHEMA LISTINGS 51

8.1. ASSERTION SCHEMA 51

8.2. PROTOCOL SCHEMA 54

9. REFERENCES 57

10. ACKNOWLEDGEMENTS 59

Appendix A. Notices 61


207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

9

1. IntroductionThis specification defines the syntax and semantics for XML-encoded SAML assertions, protocol requests, and protocol responses. These constructs are typically embedded in other structures for transport, such as HTTP form POSTs and XML-encoded SOAP messages. The SAML specification for bindings and profiles [SAMLBind] provides frameworks for this embedding and transport. Files containing just the SAML assertion schema [SAML-XSD] and protocol schema [SAMLP-XSD] are available.

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

1.1. NotationThis specification uses schema documents conforming to W3C XML Schema [Schema1] and normative text to describe the syntax and semantics of XML-encoded SAML assertions and protocol messages.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.Listings of SAML schemas appear like this.

Example code listings appear like this.

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

The prefix saml: stands for the SAML assertion namespace.

The prefix samlp: stands for the SAML request-response protocol namespace.

The prefix ds: stands for the W3C XML Signature namespace.

The prefix xsd: stands for the W3C XML Schema namespace in example listings. In schema listings, this is the default namespace and no prefix is shown.

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

1.2. Schema Organization and NamespacesThe SAML assertion structures are defined in a schema [SAML-XSD] associated with the following XML namespace:urn:oasis:names:tc:SAML:1.0:assertion

The SAML request-response protocol structures are defined in a schema [SAMLP-XSD] associated with the following XML namespace:urn:oasis:names:tc:SAML:1.0:protocol


223

224225226227228229

230

231

232233234

235236237

238239

240241242243244245246

247248249

250

251

252

253254

255256

257

258259260

261262263

10

Note: The SAML namespace names are temporary and will change when SAML 1.0 is finalized.

The assertion schema is imported into the protocol schema. Also imported into both schemas is the schema for XML Signature [XMLSig-XSD], which is associated with the following XML namespace:http://www.w3.org/2000/09/xmldsig#

1.2.1. String and URI ValuesAll SAML string and URI values have the types string and anyURI respectively, which are built in to the W3C XML Schema Datatypes specification. All strings in SAML messages MUST consist of at least one non-whitespace character (whitespace is defined in [XML 1.0 Sec. 2.3]). Empty and whitespace-only values are disallowed. Also, unless otherwise indicated in this specification, all URI values MUST consist of at least one non-whitespace character.

1.2.2. Time Values.All SAML time values have the type dateTime, which is built in to the W3C XML Schema Datatypes specification [Schema2] and MUST be expressed in UTC form.

SAML Requestors and Responders SHOULD NOT rely on other applications supporting time resolution finer than milliseconds. Implementations MUST NOT generate time instants that specify leap seconds.

1.2.3. Comparing SAML valuesUnless otherwise noted, all elements in SAML documents that have the XML Schema "string" type, or a type derived from that, MUST be compared using an exact binary comparison. In particular, SAML implementations and deployments MUST NOT depend on case-insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers or currency. This requirement is intended to conform to the W3C Requirements for String Identity, Matching, and String Indexing [W3C-CHAR].

If an implementation is comparing values that are represented using different character encodings, the implementation MUST use a comparison method that returns the same result as converting both values to the Unicode character encoding (http://www.unicode.org), Normalization Form C [UNICODE-C] and then performing an exact binary comparison. This requirement is intended to conform to the W3C Character Model for the World Wide Web ([W3C-CharMod]), and in particular the rules for Unicode-normalized Text.

Applications that compare data received in SAML documents to data from external sources MUST take into account the normalization rules specified for XML. Text contained within elements is normalized so that line endings are represented using linefeed characters (ASCII code 10Decimal), as described in section 2.11 of the XML Recommendation [XML]. Attribute values defined as strings (or types derived from strings) are normalized as described in section 3.3.3 [XML]. All white space characters are replaced with blanks (ASCII code 32Decimal).

The SAML specification does not define collation or sorting order for attribute or element values. SAML implementations MUST NOT depend on specific sorting orders for values, because these may differ depending on the locale settings of the hosts involved.

1.3. SAML Concepts (Non-Normative)This section is informative only and is superseded by any contradicting information in the normative text in Section 2 and following. A glossary of SAML terms and concepts [SAMLGloss] is available.


264265

266267268

269270271272273274

275276277

278279280

281282283284285286287

288289290291292293

294295296297298299

300301302

303

304305

11

http://www.unicode.org/

1.3.1. OverviewThe Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain.

Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes. Note that assertions containing authentication statements merely describe acts of authentication that happened previously.

Assertions are issued by SAML authorities, namely, authentication authorities, attribute authorities, and policy decision points. SAML defines a protocol by which clients can request assertions from SAML authorities and get a response from them. This protocol, consisting of XML-based request and response message formats, can be bound to many different underlying communications and transport protocols; SAML currently defines one binding, to SOAP over HTTP.

SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests, in creating their responses. Thus, while clients always consume assertions, SAML authorities can be both producers and consumers of assertions.

The following model is conceptual only; for example, it does not account for real-world information flow or the possibility of combining of authorities into a single system.

SAML

CredentialsCollector

AuthenticationAuthority

AttributeAuthority

Policy DecisionPoint

Policy

Policy EnforcementPointSystem Entity

AuthenticationAssertion Attribute Assertion Authorization

Decision Assertion

Policy Policy

ApplicationRequest

Figure 1 The SAML Domain Model

One major design goal for SAML is Single Sign-On (SSO), the ability of a user to authenticate in one domain and use resources in other domains without re-authenticating. However, SAML can be


306307308309310311

312313314315316317

318319320321322

323324325

326327

328329

330331

12

used in various configurations to support additional scenarios as well. Several profiles of SAML are currently being defined that support different styles of SSO and the securing of SOAP payloads.

The assertion and protocol data formats are defined in this specification. The bindings and profiles are defined in a separate specification [SAMLBind]. A conformance program for SAML is defined in the conformance specification [SAMLConform]. Security issues are discussed in a separate security and privacy considerations specification [SAMLSecure].

1.3.2. SAML and URI-Based IdentifiersSAML defines some identifiers to manage references to well-known concepts and sets of values. For example, the SAML-defined identifier for the password authentication method is as follows:

urn:oasis:names:tc:SAML:1.0:am:password

For another example, the SAML-defined identifier for the set of possible actions on a resource consisting of Read/Write/Execute/Delete/Control is as follows:

urn:oasis:names:tc:SAML:1.0:action:rwedcThese identifiers are defined as Uniform Resource Identifiers (URIs), but they are not necessarily able to be resolved to some Web resource. At times SAML authorities need to use identifier strings of their own design, for example, for assertion IDs or additional kinds of authentication methods not covered by SAML-defined identifiers. In these cases, using a URI form is not required; if it is used, it is not required to be resolvable to some Web resource. However, using URIs – particularly URLs based on the http: scheme – is likely to mitigate problems with clashing identifiers to some extent.

The Read/Write/Execute/Delete/Control identifier above is an example of a namespace (not in the sense of an XML namespace). SAML uses this namespace mechanism to manage the universe of possible types of actions and possible names of attributes.

See section 7 for a list of SAML-defined identifiers.

1.3.3. SAML and ExtensibilityThe XML formats for SAML assertions and protocol messages have been designed to be extensible.

However, it is possible that the use of extensions will harm interoperability and therefore the use of extensions SHOULD be carefully considered.


332333

334335336337

338339340

341

342343344

345

346347348349350

351352

353354355

356

357358359

360361

13

2. SAML AssertionsAn assertion is a package of information that supplies one or more statements made by an issuer. SAML allows issuers to make three different kinds of assertion statement:

Authentication: The specified subject was authenticated by a particular means at a particular time.

Authorization Decision: A request to allow the specified subject to access the specified resource has been granted or denied.

Attribute: The specified subject is associated with the supplied attributes.

Assertions have a nested structure. A series of inner elements representing authentication statements, authorization decision statements, and attribute statements contain the specifics, while an outer generic assertion element provides information that is common to all of the statements.

2.1. Schema Header and Namespace DeclarationsThe following schema fragment defines the XML namespaces and other header information for the assertion schema:<schema

targetNamespace="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified"><import namespace="http://www.w3.org/2000/09/xmldsig#"

schemaLocation="xmldsig-core-schema.xsd"/><annotation>

<documentation>draft-sstc-schema-assertion-3231.xsd</documentation></annotation>

…</schema>

2.2. Simple TypesThe following sections define the SAML assertion-related simple types.

2.2.1. Simple Types IDType and IDReferenceTypeThe IDType simple type is used to declare identifiers to assertions, requests, and responses. The IDReferenceType is used to reference identifiers of type IDType.

Values declared to be of type IDType MUST satisfy the following properties:

Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.

Where a data object declares that it has a particular identifier, there MUST be exactly one such declaration.

The mechanism by which the SAML Requestor or Responder ensures that the identifier is unique is left to the implementation. In the case that a pseudorandom technique is employed, the probability of two randomly chosen identifiers being identical MUST be less than 2-128 and SHOULD be less than 2-160. This requirement MAY be met by applying Base64 encoding to a randomly chosen value 128 or 160 bits in length.


362

363364

365366

367368

369

370371372

373

374375376377378379380381382383384385386387388

389

390

391392393

394

395396

397398

399400401402403

14

Phillip Hallam-Baker, 01/03/-1,

schema location bug

It is OPTIONAL for an identifier based on IDType to be resolvable in principle to some resource. In the case that the identifier is resolvable in principle (for example, the identifier is in the form of a URI reference), it is OPTIONAL for the identifier to be dereferenceable.

The following schema fragment defines the IDType and IDReferenceType simple types:<simpleType name="IDType">

<restriction base="string"/></simpleType><simpleType name="IDReferenceType">

<restriction base="string"/></simpleType>

2.2.2. Simple Type DecisionTypeThe DecisionType simple type defines the possible values to be reported as the status of an authorization decision statement.

PermitThe specified action is permitted.

DenyThe specified action is denied.

IndeterminateThe issuer cannot determine whether the specified action is permitted or denied. The Indeterminate Decision value is used in situations where the issuer requires the ability to provide an affirmative statement that it is not able to issue a decision. Additional information as to the reason for the refusal or inability to provide a decision MAY be returned as <StatusDetail> elements

The following schema fragment defines the DecisionType simple type:<simpleType name="DecisionType">

<restriction base="string"><enumeration value="Permit"/><enumeration value="Deny"/><enumeration value="Indeterminate"/>

</restriction></simpleType>

2.3. AssertionsThe following sections define the SAML constructs that contain assertion information.

2.3.1. Element <AssertionIDReference>The <AssertionIDReference> element makes a reference to a SAML assertion by means of the value of the assertion’s AssertionID attribute..

The following schema fragment defines the <AssertionIDReference> element:<element name="AssertionIDReference" type="saml:IDReferenceType"/>

2.3.2. Element <Assertion>The <Assertion> element is of AssertionType complex type. This type specifies the basic information that is common to all assertions, including the following elements and attributes:

MajorVersion [Required]The major version of this assertion. The identifier for the version of SAML defined in this specification is 1. Processing of this attribute is specified in Section 3.4.4.


404405406

407408409410411412413

414415416

417418

419420

421422423424425

426427428429430431432433434

435

436

437438439440

441

442443444

445446

447

15

MinorVersion [Required]The minor version of this assertion. The identifier for the version of SAML defined in this specification is 0. Processing of this attribute is specified in Section 3.4.4.

AssertionID [Required]The identifier for this assertion. It is of type IDType, and MUST follow the requirements specified by that type for identifier uniqueness.

Issuer [Required]The issuer of the assertion. The name of the issuer is provided as a string. The issuer name SHOULD be unambiguous to the intended relying parties. SAML authorities may use an identifier such as a URI reference that is designed to be unambiguous regardless of context.

IssueInstant [Required]The time instant of issue in UTC as described in section 1.2.1.

<Conditions> [Optional]Conditions that MUST be taken into account in assessing the validity of the assertion.

<Advice> [Optional]Additional information related to the assertion that assists processing in certain situations but which MAY be ignored by applications that do not support its use.

<Signature> [Optional]An XML Signature that authenticates the assertion, see section 5.

One or more of the following statement elements:

<Statement>A statement defined in an extension schema.

<SubjectStatement>A subject statement defined in an extension schema.

<AuthenticationStatement>An authentication statement.

<AuthorizationDecisionStatement>An authorization decision statement.

<AttributeStatement>An attribute statement.

The following schema fragment defines the <Assertion> element and its AssertionType complex type:

<element name="Assertion" type="saml:AssertionType"/><complexType name="AssertionType">

<sequence><element ref="saml:Conditions" minOccurs="0"/><element ref="saml:Advice" minOccurs="0"/><choice maxOccurs="unbounded">

<element ref="saml:Statement"/><element ref="saml:SubjectStatement"/><element ref="saml:AuthenticationStatement"/><element ref="saml:AuthorizationDecisionStatement"/><element ref="saml:AttributeStatement"/>

</choice><element ref="ds:Signature" minOccurs="0"/>

</sequence><attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="AssertionID" type="saml:IDType" use="required"/>


448449

450451452453

454455456457458

459460

461462

463464465

466467

468

469470

471472

473474

475476

477478

479480481482483484485486487488489490491492493494495496497

16

<attribute name="Issuer" type="string" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/>

</complexType>

2.3.2.1. Element <Conditions>

The <Conditions> element MAY contain the following elements and attributes:

NotBefore [Optional]Specifies the earliest time instant at which the assertion is valid. The time value is encoded in UTC as described in section 1.2.1.

NotOnOrAfter [Optional]Specifies the time instant at which the assertion has expired. The time value is encoded in UTC as described in section 1.2.1.

<Condition> [Any Number]Provides an extension point allowing extension schemas to define new conditions.

<AudienceRestrictionCondition> [Any Number]Specifies that the assertion is addressed to a particular audience.

The following schema fragment defines the <Conditions> element and its ConditionsType complex type:

<element name="Conditions" type="saml:ConditionsType"/><complexType name="ConditionsType">

<choice minOccurs="0" maxOccurs="unbounded"><element ref="saml:AudienceRestrictionCondition"/><element ref="saml:Condition"/>

</choice><attribute name="NotBefore" type="dateTime" use="optional"/><attribute name="NotOnOrAfter" type="dateTime" use="optional"/>

</complexType>

If an assertion contains a <Conditions> element, the validity of the assertion is dependent on the sub-elements and attributes provided. When processing the sub-elements and attributes of a <Conditions> element, the following rules MUST be used in the order shown to determine the overall validity of the assertion:

1. If no sub-elements or attributes are supplied in the <Conditions> element, then the assertion is considered to be Valid.

2. If any sub-element or attribute of the <Conditions> element is determined to be invalid, then the assertion is Invalid.

3. If any sub-element or attribute of the <Conditions> element cannot be evaluated, then the validity of the assertion cannot be determined and is deemed to be Indeterminate.

4. If all sub-elements and attributes of the <Conditions> element are determined to be Valid, then the assertion is considered to be Valid.

The <Conditions> element MAY be extended to contain additional conditions. If an element contained within a <Conditions> element is encountered that is not understood, the status of the condition cannot be evaluated and the validity status of the assertion MUST be deemed to be Indeterminate in accordance with rule 3 above.

Note that an assertion that has validity status Valid may not be trustworthy by reasons such as not being issued by a trustworthy issuer or not being authenticated by a trustworthy means.


498499500

501

502503504505506

507508509

510511

512513

514515516517518519520521522523524

525526

527528

529530

531532

533534

535536

537538539540

541542

17

2.3.2.1.1 Attributes NotBefore and NotOnOrAfter The NotBefore and NotOnOrAfter attributes specify time limits on the validity of the assertion.

The NotBefore attribute specifies the time instant at which the validity interval begins. The NotOnOrAfter attribute specifies the time instant at which the validity interval has ended.

If the value for either NotBefore or NotOnOrAfter is omitted it is considered unspecified. If the NotBefore attribute is unspecified (and if any other conditions that are supplied evaluate to Valid), the assertion is valid at any time before the time instant specified by the NotOnOrAfter attribute. If the NotOnOrAfter attribute is unspecified (and if any other conditions that are supplied evaluate to Valid), the assertion is valid from the time instant specified by the NotBefore attribute with no expiry. If neither attribute is specified (and if any other conditions that are supplied evaluate to Valid), the assertion is valid at any time.

The NotBefore and NotOnOrAfter attributes are defined to have the dateTime simple type that is built in to the W3C XML Schema Datatypes specification [Schema2]. All time instants are specified in Universal Coordinated Time (UTC) as described in section 1.2.1.

Implementations MUST NOT generate time instants that specify leap seconds.

2.3.2.1.2 Element <Condition> The <Condition> element serves as an extension point for new conditions. Its ConditionAbstractType complex type is abstract; extension elements MUST use the xsi:type attribute to indicate the derived type.

The following schema fragment defines the <Condition> element and its ConditionAbstractType complex type:

<element name="Condition" type="saml:ConditionAbstractType"/><complexType name="ConditionAbstractType" abstract="true"/>

2.3.2.1.3 Elements <AudienceRestrictionCondition> and <Audience>The <AudienceRestrictionCondition> element specifies that the assertion is addressed to one or more specific audiences identified by <Audience> elements. Although a party that is outside the audiences specified is capable of drawing conclusions from an assertion, the issuer explicitly makes no representation as to accuracy or trustworthiness to such a party. It contains the following elements:

<Audience>A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership.

The AudienceRestrictionCondition evaluates to Valid if and only if the relying party is a member of one or more of the audiences specified.

The issuer of an assertion cannot prevent a party to whom it is disclosed from making a decision on the basis of the information provided. However, the <AudienceRestrictionCondition> element allows the issuer to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved.

The following schema fragment defines the <AudienceRestrictionCondition> element and its AudienceRestrictionConditionType complex type:

<element name="AudienceRestrictionCondition" type="saml:AudienceRestrictionConditionType"/>

<complexType name="AudienceRestrictionConditionType"><complexContent>


543

544545546547548549550551552

553554555556

557

558

559560561

562563564565

566

567568569570571

572573574

575576

577578579580581582

583584585586587588

18

<extension base="saml:ConditionAbstractType"><sequence>

<element ref="saml:Audience" maxOccurs="unbounded"/></sequence>

</extension></complexContent>

</complexType><element name="Audience" type="anyURI"/>

2.3.2.2. Elements <Advice> and <AdviceElement>The <Advice> element contains any additional information that the issuer wishes to provide. This information MAY be ignored by applications without affecting either the semantics or the validity of the assertion.

The <Advice> element contains a mixture of zero or more <Assertion> elements, <AssertionIDReference> elements and elements in other namespaces, with lax schema validation in effect for these other elements.

Following are some potential uses of the <Advice> element:

Include evidence supporting the assertion claims to be cited, either directly (through incorporating the claims) or indirectly (by reference to the supporting assertions).

State a proof of the assertion claims.

Specify the timing and distribution points for updates to the assertion.

The following schema fragment defines the <Advice> element and its AdviceType complex type:<element name="Advice" type="saml:AdviceType"/><complexType name="AdviceType">

<choice minOccurs="0" maxOccurs="unbounded"><element ref="saml:AssertionIDReference"/><element ref="saml:Assertion"/><any namespace="##other" processContents="lax"/>

</choice></complexType>

2.4. StatementsThe following sections define the SAML constructs that contain statement information.

2.4.1. Element <Statement> The <Statement> element is an extension point that allows other assertion-based applications to reuse the SAML assertion framework. Its StatementAbstractType complex type is abstract; extension elements MUST use the xsi:type attribute to indicate the derived type.

The following schema fragment defines the <Statement> element and its StatementAbstractType complex type:

<element name="Statement" type="saml:StatementAbstractType"/><complexType name="StatementAbstractType" abstract="true"/>

2.4.2. Element <SubjectStatement>The <SubjectStatement> element is an extension point that allows other assertion-based applications to reuse the SAML assertion framework. It contains a <Subject> element that allows an issuer to describe a subject. Its SubjectStatementAbstractType complex type, which extends StatementAbstractType, is abstract; extension elements MUST use the xsi:type attribute to indicate the derived type.


589590591592593594595596

597598599600

601602603

604605606

607

608

609610611612613614615616617

618

619

620621622

623624625626627

628629630631

632633

19

The following schema fragment defines the <SubjectStatement> element and its SubjectStatementAbstractType abstract type:

<element name="SubjectStatement" type="saml:SubjectStatementAbstractType"/><complexType name="SubjectStatementAbstractType" abstract="true">

<complexContent><extension base="saml:StatementAbstractType">

<sequence><element ref="saml:Subject"/>

</sequence></extension>

</complexContent></complexType>

2.4.2.1. Element <Subject> The <Subject> element specifies the principal that is the subject of the statement. It contains either or both of the following elements:

<NameIdentifier>An identification of a subject by its name and security domain.

<SubjectConfirmation>Information that allows the subject to be authenticated.

If the <Subject> element contains both a <NameIdentifier> and a <SubjectConfirmation>, the issuer is asserting that if the relying party performs the specified <SubjectConfirmation>, it can be confident that the entity presenting the assertion to the relying party is the entity that the issuer associates with the <NameIdentifier> A <Subject> element SHOULD NOT identify more than one principal.The following schema fragment defines the <Subject> element and its SubjectType complex type:

<element name="Subject" type="saml:SubjectType"/><complexType name="SubjectType">

<choice><sequence>

<element ref="saml:NameIdentifier"/><element ref="saml:SubjectConfirmation" minOccurs="0"/>

</sequence><element ref="saml:SubjectConfirmation"/>


2.4.2.2. Element <NameIdentifier> The <NameIdentifier> element specifies a subject by a combination of a name qualifier, a name and a format. It has the following attributes:NameQualifier [Optional]

The security or administrative domain that qualifies the name of the subject. The NameQualifier attribute provides a means to federate names from disparate user stores without collision.

Format [Optional]The syntax used to describe the name of the subject

The format value MUST be a URI reference. The following URI references are defined by this specification, where only the fragment identifier portion is shown, assuming a base URI of the SAML assertion namespace name.

#emailAddressIndicates that the content of the NameIdentifier element is in the form of an email address,


634635636637638639640641642643644645

646647648

649650

651652

653654655656657

658659660661662663664665666667668669

670671672

673674675676

677678

679680681

682683

20

specifically "addr-spec" as defined in section 3.4.1 of RFC 2822 [RFC 2822]. An addr-spec has the form local-part@domain. Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">".

#X509SubjectNameIndicates that the content of the NameIdentifier element is in the form specified for the contents of <ds:X509SubjectName> element in [DSIG]. Implementors should note that [DSIG] specifies encoding rules for X.509 subject names that differ from the rules given in RFC2253 [RFC2253].

#WindowsDomainQualifiedNameIndicates that the content of the NameIdentifier element is a Windows domain qualified name. A Windows domain qualified user name is a string of the form "DomainName\UserName". The domain name and "\" separator may be omitted.

The following schema fragment defines the <NameIdentifier> element and its NameIdentifierType complex type:

<element name="NameIdentifier" type="saml:NameIdentifierType"/><complexType name="NameIdentifierType">

<simpleContent><extension base="string">

<attribute name="NameQualifier" type="string" use="optional"/><attribute name="Format" type="anyURI" use="optional"/>

</extension></simpleContent>

</complexType>

The interpretation of the NameQualifier, and NameIdentifier's content in the case of a Format not specified in this document, are left to individual implementations.Regardless of format, issues of anonymity, pseudonymity, and the persistence of the identifier with respect to the asserting and relying parties, are also implementation-specific.

2.4.2.3. Elements <SubjectConfirmation>, <ConfirmationMethod>, and <SubjectConfirmationData>

The <SubjectConfirmation> element specifies a subject by supplying data that allows the subject to be authenticated. It contains the following elements in order:

<ConfirmationMethod> [One or more]A URI reference that identifies a protocol to be used to authenticate the subject. URI references identifying SAML-defined confirmation methods are currently defined with the SAML profiles in [SAMLBind]. Additional methods may be added by defining new profiles or by private agreement.Additional SAML confirmation methods may be defined in future OASIS-approved SAML profile specifications.

<SubjectConfirmationData> [Optional]Additional authentication information to be used by a specific authentication protocol.

<ds:KeyInfo> [Optional]An XML Signature [XMLSig] element that specifies a cryptographic key held by the subject.

The following schema fragment defines the <SubjectConfirmation> element and its SubjectConfirmationType complex type, along with the <SubjectConfirmationData> element and the <ConfirmationMethod> element:

<element name="SubjectConfirmation" type="saml:SubjectConfirmationType"/><complexType name="SubjectConfirmationType">

<sequence><element ref="saml:ConfirmationMethod" maxOccurs="unbounded"/><element ref="saml:SubjectConfirmationData" minOccurs="0"/>


684685686687

688689690691692

693694695696

697698699700701702703704705706707

708709710711712

713714715716

717718719720721722

723724

725726

727728729

730731732733734

21

<element ref="ds:KeyInfo" minOccurs="0"/></sequence>

</complexType><element name="SubjectConfirmationData" type="anyType"/><element name="ConfirmationMethod" type="anyURI"/>

2.4.3. Element <AuthenticationStatement>The <AuthenticationStatement> element supplies a statement by the issuer that its subject was authenticated by a particular means at a particular time. It is of type AuthenticationStatementType, which extends SubjectStatementAbstractType with the addition of the following element and attributes:

AuthenticationMethod [Optional]A URI reference that specifies the type of authentication that took place. URI references identifying common authentication protocols are listed in Section 7.

AuthenticationInstant [Optional]Specifies the time at which the authentication took place. The time value is encoded in UTC as described in section 1.2.1.

<SubjectLocality> [Optional]Specifies the DNS domain name and IP address for the system entity from which the Subject was apparently authenticated.

<AuthorityBinding> [Any Number]Indicates that additional information about the subject of the statement may be available.

The following schema fragment defines the <AuthenticationStatement> element and its AuthenticationStatementType complex type:

<element name="AuthenticationStatement" type="saml:AuthenticationStatementType"/>

<complexType name="AuthenticationStatementType"><complexContent>

<extension base="saml:SubjectStatementAbstractType"><sequence>

<element ref="saml:SubjectLocality" minOccurs="0"/><element ref="saml:AuthorityBinding" minOccurs="0" maxOccurs="unbounded"/>

</sequence><attribute name="AuthenticationMethod" type="anyURI"/><attribute name="AuthenticationInstant" type="dateTime"/>


</complexType>

2.4.3.1. Element <SubjectLocality>The <SubjectLocality> element specifies the DNS domain name and IP address for the system entity that was authenticated. It has the following attributes:

IPAddress [Optional]The IP address of the system entity that was authenticated.

DNSAddress [Optional]The DNS address of the system entity that was authenticated.

This element is entirely advisory, since both these fields are quite easily “spoofed” but current practice appears to require its inclusion.

The following schema fragment defines the <SubjectLocality> element and its SubjectLocalityType complex type:


735736737738739

740741742743744

745746747

748749750

751752753

754755

756757758759760761762763764765766767768769770771772

773774775

776777

778779

780781

782783

22

<element name="SubjectLocality" type="saml: SubjectLocalityType"/>

<complexType name="SubjectLocalityType"><attribute name="IPAddress" type="string" use="optional"/><attribute name="DNSAddress" type="string" use="optional"/>

</complexType>

2.4.3.2. Element <AuthorityBinding>The <AuthorityBinding> element may be used to indicate to a relying party receiving an AuthenticationStatement that a SAML authority may be available to provide additional information about the subject of the statement. A single SAML authority may advertise its presence over multiple protocol bindings, at multiple locations, and as more than one kind of authority by sending multiple elements as needed.AuthorityKind [Required]

The type of SAML Protocol queries to which the authority described by this element will respond. The value is specified as an XML Schema QName. The acceptable values for AuthorityKind are the namespace-qualified names of element types or elements derived from the SAML Protocol Query element (see Section 3.3). For example, an attribute authority would be identified by AuthorityKind="samlp:AttributeQuery". For extension schemas, where the actual type of the samlp:Query would be identified by an xsi:type attribute, the value of AuthorityKind MUST be the same as the value of the xsi:type attribute for the corresponding query.

Location [Required]A URI reference describing how to locate and communicate with the authority, the exact syntax of which depends on the protocol binding in use. For example, a binding based on HTTP will be a web URL, while a binding based on SMTP might use the "mailto" scheme.

Binding [Required]A URI reference identifying the SAML protocol binding to use in communicating with the authority. All SAML protocol bindings will have an assigned URI reference.

The following schema fragment defines the <AuthorityBinding> element and its AuthorityBindingType complex type and AuthorityKindType simple type:

<element name="AuthorityBinding" type="saml:AuthorityBindingType"/><complexType name="AuthorityBindingType">

<attribute name="AuthorityKind" type="QName" use="required"/><attribute name="Location" type="anyURI" use="required"/><attribute name="Binding" type="anyURI" use="required"/>

</complexType>

2.4.4. Element <AuthorizationDecisionStatement>The <AuthorizationDecisionStatement> element supplies a statement by the issuer that the request for access by the specified subject to the specified resource has resulted in the specified decision on the basis of some optionally specified evidence.

The resource is identified by means of a URI reference. In order for the assertion to be interpreted correctly and securely the issuer and relying party MUST interpret each URI reference in a consistent manner. Failure to achieve a consistent URI reference interpretation can result in different authorization decisions depending on the encoding of the resource URI reference. Rules for normalizing URI references are to be found in [RFC 2396]§6

In general, the rules for equivalence and definition of a normal form, if any, are scheme dependent. When a scheme uses elements of the common syntax, it will also use the common syntax equivalence rules, namely that the scheme and hostname are case insensitive and a URL with an explicit ":port", where the port is the default for the scheme, is equivalent to one where the port is elided.


784785786787788789

790791792793794795

796797798

799800

801802803804805806807808

809810811

812813814815816817818819

820821822823

824825826827828

829830831832833

23

To avoid ambiguity resulting from variations in URI encoding SAML requestors and responders SHOULD employ the URI normalized form wherever possible as follows:

The assertion issuer SHOULD encode all resource URIs in normalized form.

Relying parties SHOULD convert resource URIs to normalized form prior to processing.

Inconsistent URI interpretation can also result from differences between the URI syntax and the semantics of an underlying file system. Particular care is required if URIs are employed to specify an access control policy language. The following security conditions should be satisfied by the system which employs SAML assertions:

Parts of the URI syntax are case sensitive. If the underlying file system is case insenstive a requestor SHOULD NOT be able to gain access to a denied resource by changing the case of a part of the resource URI.

Many file systems support mechanisms such as logical paths and symbolic links which allow users to establish logical equivalences between file system entries. A requestor SHOULD NOT be able to gain access to a denied resource by creating such an equivalence.

The <AuthorizationDecisionStatement> element is of type AuthorizationDecisionStatementType, which extends SubjectStatementAbstractType with the addition of the following elements (in order) and attributes:

Resource [Required]A URI reference identifying the resource to which access authorization is sought. It is permitted for this attribute to have the value of the empty URI reference (""), and the meaning is defined to be "the start of the current document", as specified by [RFC 2396]§ 4.2.

Decision [Required]The decision rendered by the issuer with respect to the specified resource. The value is of the DecisionType simple type.

<Action> [One or more]The set of actions authorized to be performed on the specified resource.

<Evidence> [Any Number]A set of assertions that the issuer relied on in making the decision.

The following schema fragment defines the <AuthorizationDecisionStatement> element and its AuthorizationDecisionStatementType complex type:

<element name="AuthorizationDecisionStatement" type="saml:AuthorizationDecisionStatementType"/>

<complexType name="AuthorizationDecisionStatementType"><complexContent>


<element ref="saml:Action" maxOccurs="unbounded"/><element ref="saml:Evidence" minOccurs="0"/>

</sequence><attribute name="Resource" type="anyURI" use="required"/><attribute name="Decision" type="saml:DecisionType" use="required"/>


</complexType>


834835

836

837

838839840841

842843844

845846847848

849850851

852853854855856857

858859860

861862

863864

865866867868869870871872873874875876877878879880

24

2.4.4.1. Element <Action>The <Action> element specifies an action on the specified resource for which permission is sought. It has the following attribute:

Namespace [Optional]A URI reference representing the namespace in which the name of the specified action is to be interpreted. If this element is absent, the namespace urn:oasis:names:tc:SAML:1.0:action:rwedc-negation specified in section 7.2.2 is in effect.

string data [Required]An action sought to be performed on the specified resource.

The following schema fragment defines the <Action> element and its ActionType complex type:<element name="Action" type="saml:ActionType"/><complexType name="ActionType">


<attribute name="Namespace" type="anyURI"/></extension>

</simpleContent></complexType>

2.4.4.2. Element <Evidence>The <Evidence> element contains an assertion that the issuer relied on in issuing the authorization decision. It has the EvidenceType complex type. It contains one of the following elements:

<AssertionIDReference>Specifies an assertion by reference to the value of the assertion’s AssertionID attribute.

<Assertion>Specifies an assertion by value.

The provision of an assertion as evidence MAY affect the reliance agreement between the requestor and the Authorization Authority. For example, in the case that the requestor presented an assertion to the Authorization Authority in a request, the Authorization Authority MAY use that assertion as evidence in making its response without endorsing the assertion as valid either to the requestor or any third party.

The following schema fragment defines the <Evidence> element and its EvidenceType complex type:

<element name="Evidence" type="saml:EvidenceType"/><complexType name="EvidenceType">

<choice maxOccurs="unbounded"><element ref="saml:AssertionIDReference"/><element ref="saml:Assertion"/>


2.4.5. Element <AttributeStatement>The <AttributeStatement> element supplies a statement by the issuer that the specified subject is associated with the specified attributes. It is of type AttributeStatementType, which extends SubjectStatementAbstractType with the addition of the following element:

<Attribute> [One or More]The <Attribute> element specifies an attribute of the subject.


881882883

884885886887

888889

890891892893894895896897898

899900901902

903904905906

907908909910911

912913914915916917918919920

921922923924

925926

25

The following schema fragment defines the <AttributeStatement> element and its AttributeStatementType complex type:

<element name="AttributeStatement" type="saml:AttributeStatementType"/><complexType name="AttributeStatementType">

<complexContent><extension base="saml:SubjectStatementAbstractType">

<sequence><element ref="saml:Attribute" maxOccurs="unbounded"/>



2.4.5.1. Elements <AttributeDesignator> and <Attribute>The <AttributeDesignator> element identifies an attribute name within an attribute namespace. It has the AttributeDesignatorType complex type. It is used in an attribute query to request that attribute values within a specific namespace be returned (see 3.3.4 for more information). The <AttributeDesignator> element contains the following XML attributes:

AttributeNamespace [Optional]The namespace in which the AttributeName elements are interpreted.

AttributeName [Optional]The name of the attribute.

The following schema fragment defines the <AttributeDesignator> element and its AttributeDesignatorType complex type:

<element name="AttributeDesignator" type="saml:AttributeDesignatorType"/><complexType name="AttributeDesignatorType">

<attribute name="AttributeName" type="string" use="required"/><attribute name="AttributeNamespace" type="anyURI" use="required"/>

</complexType>

The <Attribute> element supplies the value for an attribute of an assertion subject. It has the AttributeType complex type, which extends AttributeDesignatorType with the addition of the following element:

<AttributeValue> [Any Number]The value of the attribute.

The following schema fragment defines the <Attribute> element and its AttributeType complex type:

<element name="Attribute" type="saml:AttributeType"/><complexType name="AttributeType">

<complexContent><extension base="saml:AttributeDesignatorType">

<sequence><element ref="saml:AttributeValue" maxOccurs="unbounded"/>



2.4.5.1.1 Element <AttributeValue>The <AttributeValue> element supplies the value of a specified attribute. It is of the anyType simple type, which allows any well-formed XML to appear as the content of the element.

If the data content of an AttributeValue element is of a XML Schema simple type (e.g. interger, string, etc) the data type MAY be declared explicitly by means of an xsi:type declaration in the


927928929930931932933934935936937938

939940941942

943944945946947

948949950951952953954

955956957

958959

960961962963964965966967968969970971

972

973974

975976

26

<AttributeValue> element. If the attribute value contains structured data the necessary data elements may be defined in an extension schema introduced by means of the xmlns= mechanism.

The following schema fragment defines the <AttributeValue> element:<element name="AttributeValue" type="anyType"/>


977978979

980

27

3. SAML ProtocolSAML assertions MAY be generated and exchanged using a variety of protocols. The bindings and profiles specification for SAML [SAMLBind] describes specific means of transporting assertions using existing widely deployed protocols.

SAML-aware requestors MAY in addition use the SAML request-response protocol defined by the <Request> and <Response> elements. The requestor sends a <Request> element to a SAML authority, and the authority generates a <Response> element, as shown in Figure 2.

Figure 2: SAML Request-Response Protocol

3.1. Schema Header and Namespace DeclarationsThe following schema fragment defines the XML namespaces and other header information for the protocol schema:<schema

targetNamespace="urn:oasis:names:tc:SAML:1.0:protocol" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="unqualified"><import namespace="urn:oasis:names:tc:SAML:1.0:assertion"

schemaLocation="draft-sstc-schema-assertion-3231.xsd"/><import namespace="http://www.w3.org/2000/09/xmldsig#"

schemaLocation="xmldsig-core-schema.xsd"/><annotation>

<documentation>draft-sstc-schema-protocol-3231.xsd</documentation></annotation>

…</schema>

3.2. RequestsThe following sections define the SAML constructs that contain request information.

3.2.1. Complex Type RequestAbstractTypeAll SAML requests are of types that are derived from the abstract RequestAbstractType complex type. This type defines common attributes and elements that are associated with all SAML requests:

RequestID [Required]An identifier for the request. It is of type IDType, and MUST follow the requirements specified by that type for identifier uniqueness. The values of the RequestID attribute in a request and the InResponseTo attribute in the corresponding response MUST match.

MajorVersion [Required]The major version of this request. The identifier for the version of SAML defined in this specification is 1. Processing of this attribute is specified in Section 3.4.2.


981

982983984

985986987

988989

990

991992993994995996997998999

100010011002100310041005100610071008

1009

1010

1011

1012101310141015

10161017

1018101910201021

1022

28

MinorVersion [Required]The minor version of this request. The identifier for the version of SAML defined in this specification is 0. Processing of this attribute is specified in Section 3.4.2.

IssueInstant [Required]The time instant of issue of the request. The time value is encoded in UTC as described in section 1.2.1.

<RespondWith> [Any Number]Each <RespondWith> element specifies a type of response that is acceptable to the requestor.


The following schema fragment defines the RequestAbstractType complex type:<complexType name="RequestAbstractType" abstract="true">

<sequence><element ref="samlp:RespondWith"

minOccurs="0" maxOccurs="unbounded"/><element ref = "ds:Signature" minOccurs="0"/>

</sequence><attribute name="RequestID" type="saml:IDType" use="required"/><attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/>

</complexType>

3.2.1.1. Element <RespondWith>The <RespondWith> element specifies the type of Statement the requestor wants from the responder. Multiple <RespondWith> elements MAY be included to indicate that the requestor will accept assertions containing any of the specified types. If no <RespondWith> element is given, the responder may return assertions containing statements of any type.

If the requestor sends one or more <RespondWith> elements, the responder MUST NOT respond with assertions containing statements of any type not specified in one of the <RespondWith> elements.

NOTE: Inability to find assertions that meet <RespondWith> criteria should be treated identical to any other query for which no assertions are available. In both cases a status of success would normally be returned in the Response message, but no assertions to be found therein.

<RespondWith> element values are XML QNames. The XML namespace and name specifically refer to the namespace and element name of the Statement element, exactly as for the saml:AuthorityKind attribute; see section 2.4.3.2. For example, a requestor that wishes to receive assertions containing only attribute statements must specify <RespondWith>saml:AttributeStatement</RespondWith>. To specify extension types, the <RespondWith> element MUST contain exactly the extension element type as specified in the xsi:type attribute on the corresponding element.

The following schema fragment defines the <RespondWith> element:<element name="RespondWith" type="QName"/>

3.2.2. Element <Request>The <Request> element specifies a SAML request. It provides either a query or a request for a specific assertion identified by <AssertionIDReference> or <AssertionArtifact>. It has


10231024

1025102610271028

102910301031

10321033

103410351036103710381039104010411042104310441045

10461047104810491050

105110521053

105410551056

10571058

10591060

106110621063

10641065

106610671068

29

the complex type RequestType, which extends RequestAbstractType by adding a choice of one of the following elements:

<Query>An extension point that allows extension schemas to define new types of query.

<SubjectQuery>An extension point that allows extension schemas to define new types of query that specify a single SAML subject.

<AuthenticationQuery>Makes a query for authentication information.

<AttributeQuery>Makes a query for attribute information.

<AuthorizationDecisionQuery>Makes a query for an authorization decision.

<AssertionIDReference> [One or more]Requests assertions by reference to its assertion identifier.

<AssertionArtifact> [One or more]Requests assertions by supplying an assertion artifact that represents it.

The following schema fragment defines the <Request> element and its RequestType complex type:

<element name="Request" type="samlp:RequestType"/><complexType name="RequestType">

<complexContent><extension base="samlp:RequestAbstractType">

<choice><element ref="samlp:Query"/><element ref="samlp:SubjectQuery"/><element ref="samlp:AuthenticationQuery"/><element ref="samlp:AttributeQuery"/><element ref="samlp:AuthorizationDecisionQuery"/><element ref="saml:AssertionIDReference" maxOccurs="unbounded"/><element ref="samlp:AssertionArtifact" maxOccurs="unbounded"/>

</choice></extension>


3.2.3. Element <AssertionArtifact> The <AssertionArtifact> element is used to specify the assertion artifact that represents an assertion.

The following schema fragment defines the <AssertionArtifact> element:<element name="AssertionArtifact" type="string"/>

3.3. QueriesThe following sections define the SAML constructs that contain query information.

3.3.1. Element <Query> The <Query> element is an extension point that allows new SAML queries to be defined. Its QueryAbstractType is abstract; extension elements MUST use the xsi:type attribute to indicate


10691070

10711072

107310741075

10761077

10781079

10801081

10821083

10841085

108610871088108910901091109210931094109510961097109810991100110111021103

1104

11051106

11071108

1109

1110

111111121113

30

the derived type. QueryAbstractType is the base type from which all SAML query elements are derived.

The following schema fragment defines the <Query> element and its QueryAbstractType complex type:

<element name="Query" type="samlp:QueryAbstractType"/><complexType name="QueryAbstractType" abstract="true"/>

3.3.2. Element <SubjectQuery>The <SubjectQuery> element is an extension point that allows new SAML queries that specify a single SAML subject. Its SubjectQueryAbstractType complex type is abstract; extension elements MUST use the xsi:type attribute to indicate the derived type. SubjectQueryAbstractType adds the <Subject> element.

The following schema fragment defines the <SubjectQuery> element and its SubjectQueryAbstractType complex type:

<element name="SubjectQuery" type="samlp:SubjectQueryAbstractType"/><complexType name="SubjectQueryAbstractType" abstract="true">

<complexContent><extension base="samlp:QueryAbstractType">




3.3.3. Element <AuthenticationQuery>The <AuthenticationQuery> element is used to make the query “What assertions containing authentication statements are available for this subject?” A successful response will be in the form of assertions containing authentication statements.

Note: The <AuthenticationQuery> MAY NOT be used as a request for a new authentication using credentials provided in the request. The <AuthenticationQuery> is a request for statements about authentication acts which have occurred in a previous interaction between the indicated principal and the Authentication Authority.

This element is of type AuthenticationQueryType, which extends SubjectQueryAbstractType with the addition of the following element:

<AuthenticationMethod> [Optional] A filter for possible responses. If it is present, the query made is “What assertions containing authentication statements do you have for this subject with the supplied authentication method?”

In response to an authentication query, a responder returns assertions with authentication statements as follows:

First, rules given in section 3.4.4 for matching against the <Subject> element of the query identify the assertions that may be returned.

Further, if the <AuthenticationMethod> element is present in the query, at least one <AuthenticationMethod> element in the set of returned assertions MUST match. It is OPTIONAL for the complete set of all such matching assertions to be returned in the response.

The <Subject> element in the returned assertions MUST be identical to the <Subject> element of the query. If the <ConfirmationMethod> element is present in the query, at least one


11141115

1116111711181119

112011211122

11231124112511261127112811291130113111321133113411351136

1137113811391140

1141114211431144

11451146

1147114811491150

11511152

11531154

1155115611571158

11591160

31

<ConfirmationMethod> element in the response MUST match. It is OPTIONAL for the complete set of all such matching assertions to be returned in the response.

The following schema fragment defines the <AuthenticationQuery> type and its AuthenticationQueryType complex type:

<element name="AuthenticationQuery" type="samlp:AuthenticationQueryType"/><complexType name="AuthenticationQueryType">

<complexContent><extension base="samlp:SubjectQueryAbstractType">

<attribute name="AuthenticationMethod" type="anyURI"/></extension>


3.3.4. Element <AttributeQuery>The <AttributeQuery> element is used to make the query “Return the requested attributes for this subject.” A successful response will be in the form of assertions containing attribute statements. This element is of type AttributeQueryType, which extends SubjectQueryAbstractType with the addition of the following element and attribute:

Resource [Optional]The Resource attribute if present specifies that the attribute query is made in response to a specific authorization decision relating to the resource. The responder MAY use the resource attribute to establish the scope of the request. It is permitted for this attribute to have the value of the empty URI reference (""), and the meaning is defined to be "the start of the current document", as specified by [RFC 2396]§ 4.2.

If the resource attribute is specified and the responder does not wish to support resource-specific attribute queries, or if the resource value provided is invalid or unrecognized, then it SHOULD respond with a top-level StatusCode value of Responder and a second-level code value of ResourceNotRecognized

<AttributeDesignator> [Any Number] (see Section 2.4.5.1)Each <AttributeDesignator> element specifies an attribute whose value is to be returned. If no attributes are specified, it indicates that all attributes allowed by policy are requested.

The following schema fragment defines the <AttributeQuery> element and its AttributeQueryType complex type:

<element name="AttributeQuery" type="samlp:AttributeQueryType"/><complexType name="AttributeQueryType">


<sequence><element ref="saml:AttributeDesignator"

minOccurs="0" maxOccurs="unbounded"/></sequence><attribute name="Resource" type="anyURI reference" use="optional"/>


</complexType>

3.3.5. Element <AuthorizationDecisionQuery>The <AuthorizationDecisionQuery> element is used to make the query “Should these actions on this resource be allowed for this subject, given this evidence?” A successful response will be in the form of assertions containing authorization decision statements. This element is of


11611162

1163116411651166116711681169117011711172

11731174117511761177

117811791180118111821183

1184118511861187

1188118911901191

11921193119411951196119711981199120012011202120312041205

1206120712081209

32

type AuthorizationDecisionQueryType, which extends SubjectQueryAbstractType with the addition of the following elements and attribute:

Resource [Required]A URI reference indicating the resource for which authorization is requested.

<Action> [One or More]The actions for which authorization is requested.

<Evidence> [Any Number]An assertion that the responder MAY rely on in making its response.

The following schema fragment defines the <AuthorizationDecisionQuery> element and its AuthorizationDecisionQueryType complex type:

<element name="AuthorizationDecisionQuery" type="samlp:AuthorizationDecisionQueryType"/>

<complexType name="AuthorizationDecisionQueryType"><complexContent>

<extension base="samlp:SubjectQueryAbstractType"><sequence>

<element ref="saml:Action" maxOccurs="unbounded"/><element ref="saml:Evidence"

minOccurs="0" maxOccurs="unbounded"/></sequence><attribute name="Resource" type="anyURI" use="required"/>


</complexType>

3.4. ResponsesThe following sections define the SAML constructs that contain response information.

3.4.1. Complex Type ResponseAbstractTypeAll SAML responses are of types that are derived from the abstract ResponseAbstractType complex type. This type defines common attributes and elements that are associated with all SAML responses:

ResponseID [Required]An identifier for the response. It is of type IDType, and MUST follow the requirements specified by that type for identifier uniqueness.

InResponseTo [Optional]A reference to the identifier of the request to which the response corresponds, if any. If the response is not generated in response to a request, or if the RequestID of a request cannot be determined (because the request is malformed), then this attribute MUST NOT be present. Otherwise, it MUST be present and match the value of the corresponding RequestID attribute.

MajorVersion [Required]The major version of this response. The identifier for the version of SAML defined in this specification is 1. Processing of this attribute is specified in Section 3.4.4.

MinorVersion [Required]The minor version of this response. The identifier for the version of SAML defined in this specification is 0. Processing of this attribute is specified in Section 3.4.4.


12101211

12121213

12141215

12161217

1218121912201221122212231224122512261227122812291230123112321233

1234

1235

1236123712381239

124012411242

124312441245124612471248

12491250

125112521253

1254

33

IssueInstant [Optional]The time instant of issue of the request. The time value is encoded in UTC as described in section 1.2.1.

Recipient [Optional]The intended recipient of this response. This is useful to prevent malicious forwarding of responses to unintended recipients, a protection that is required by some use profiles. It is set by the generator of the response to a URI reference that identifies the intended recipient. If present, the actual recipient MUST check that the URI reference identifies the recipient or a resource managed by the recipient. If it does not, the response MUST be discarded.


The following schema fragment defines the ResponseAbstractType complex type:<complexType name="ResponseAbstractType" abstract="true">

<sequence><element ref = "ds:Signature" minOccurs="0"/>

</sequence><attribute name="ResponseID" type="saml:IDType" use="required"/><attribute name="InResponseTo" type="saml:IDReferenceType"

use="optional"/><attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/><attribute name="Recipient" type="anyURI" use="optional"/>

</complexType>

3.4.2. Element <Response>The <Response> element specifies the status of the corresponding SAML request and a list of zero or more assertions that answer the request. It has the complex type ResponseType, which extends ResponseAbstractType by adding the following elements (in an unbounded mixture):

<Status> [Required] (see Section 3.4.3)A code representing the status of the corresponding request.

<Assertion> [Any Number] (see Section 2.3.2)Specifies an assertion by value.

The following schema fragment defines the <Response> element and its ResponseType complex type:

<element name="Response" type="samlp:ResponseType"/><complexType name="ResponseType">

<complexContent><extension base="samlp:ResponseAbstractType">

<sequence><element ref="samlp:Status"/><element ref="saml:Assertion" minOccurs="0" maxOccurs="unbounded"/>



3.4.3. Element <Status>The <Status> element :


125512561257

1258125912601261126212631264

12651266

1267126812691270127112721273127412751276127712781279

1280128112821283

12841285

12861287

12881289129012911292129312941295129612971298129913001301

13021303

34

<StatusCode> [Required]A code representing the status of the corresponding request.

<StatusMessage> [Any Number]A message which MAY be returned to an operator.

<StatusDetail> [Optional]Specifies additional information concerning an error condition.

The following schema fragment defines the <Status> element and its StatusType complex type:<element name="Status" type="samlp:StatusType"/><complexType name="StatusType">

<sequence><element ref="samlp:StatusCode"/><element ref="samlp:StatusMessage" minOccurs="0" maxOccurs="unbounded"/><element ref="samlp:StatusDetail" minOccurs="0"/>

</sequence></complexType>

3.4.3.1. Element <StatusCode>The <StatusCode> element specifies one or more nested codes representing the status of the corresponding request. top-most code value MUST be one of the values defined below. Subsequent nested code values, if present, may provide more specific information concerning a particular error.

Value [Required]The status code value as defined below.

<StatusCode> [Optional]An optional subordinate status code value that provides more specific information on an error condition.

The following top-level StatusCode Value QNames are defined. The responder MUST NOT include a code not listed below except by nesting it below one of the listed values.

SuccessThe request succeeded.

VersionMismatchThe receiver could not process the request because the version was incorrect.

ReceiverThe request could not be performed due to an error at the receiving end.

SenderThe request could not be performed due to an error in the sender or in the request

The following second-level status codes are referenced at various places in the specification. Additional subcodes MAY be defined in future versions of the SAML specification.

RequestVersionTooHighThe protocol version specified in the request is a major upgrade from the highest protocol version supported by the responder.

RequestVersionTooLowThe responder cannot respond to the particular request using the SAML version specified in the request because it is too low.

RequestVersionDeprecatedThe responder does not respond to any requests with the protocol version specified in the request.


13041305

13061307

13081309

1310131113121313131413151316131713181319

13201321132213231324

13251326

132713281329

13301331

13321333

13341335

13361337

13381339

13401341

134213431344

134513461347

134813491350

35

TooManyResponsesThe response would contain more elements than the responder will return.

RequestDeniedThe responder is able to process the request but has chosen not to respond. MAY be used when the responder is concerned about the security context of the request or the sequence of requests received from a particular client.

All status code values defined in this document are QNames associated with the SAML protocol namespace [SAMLP] and MUST be prefixed approprately when they appear in SAML messages. SAML extensions and SAML Responders are free to define more specific status codes in other namespaces, but MAY NOT define additional codes in either the SAML assertion or protocol namespaces.

The QNames defined as status codes SHOULD only be used in the StatusCode element's Value attribute and have the above semantics only in that context.

The following schema fragment defines the <StatusCode> element and its StatusCodeType complex type:

<element name="StatusCode" type="samlp:StatusCodeType"/><complexType name="StatusCodeType">

<sequence><element ref="samlp:StatusCode" minOccurs="0"/>

</sequence><attribute name="Value" type="QName" use="required"/>

</complexType>

3.4.3.2. Element <StatusMessage>The <StatusMessage> element specifies a message that MAY be returned to an operator:

The following schema fragment defines the <StatusMessage> element and its StatusMessageType complex type:

<element name="StatusMessage" type="string"/>

3.4.3.3. Element <StatusDetail>The <StatusDetail> element MAY be used to specify additional information concerning an error condition.

The following schema fragment defines the <StatusDetail> element and its StatusDetailType complex type:

<element name="StatusDetail" type="samlp:StatusDetailType"/><complexType name="StatusDetailType">

<sequence><any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>


3.4.4. Responses to <AuthenticationQuery> and <AttributeQuery> Responses to Authentication and Attribute queries are constructed by matching against the <saml:Subject> element found within the <AuthenticationQuery> or <AttributeQuery> elements. In response to these queries, every assertion returned by a SAML responder MUST contain at least one statement whose <saml:Subject> element strongly matches the <saml:Subject> element found in the query.

A <saml:Subject> element S1 strongly matches S2 if and only if:


13511352

1353135413551356

13571358135913601361

13621363

136413651366136713681369137013711372

13731374137513761377

137813791380

138113821383138413851386138713881389

13901391

13921393

139413951396

36

1 If S2 includes a <saml:NameIdentifier> element, then S1 must include an identical <saml:NameIdentifier> element.

2 If S2 includes a <saml:SubjectConfirmation> element, then S1 must include an identical <saml:SubjectConfirmation> element.

If the responder cannot provide an assertion with any statement(s) satisfying the constraints expressed by a query, the <saml:Response> element MUST NOT contain an <assertion> element and MUST include a <saml:StatusCode> with value "Success". It MAY return a <saml:StatusMessage> with additional information.


13971398139914001401140214031404

37

4. SAML VersioningSAML version information appears in the following elements:

<Assertion>

<Request>

<Response>

The version numbering of the SAML assertion is independent of the version number of the SAML request-response protocol. The version information for each consists of a major version number and a minor version number, both of which are integers. In accordance with industry practice a version number SHOULD be presented to the user in the form Major.Minor. This document defines SAML Assertions 1.0 and SAML Protocol 1.0.

The version number MajorB.MinorB is higher than the version number MajorA.MinorA if and only if:

MajorB > MajorA ( ( MajorB = MajorA ) MinorB > MinorA )

Each revision of SAML SHALL assign version numbers to assertions, requests, and responses that are the same as or higher than the corresponding version number in the SAML version that immediately preceded it.

New versions of SAML SHALL assign new version numbers as follows:

Documentation change: ( MajorB = MajorA ) ( MinorB > MinorA )If the major and minor version numbers are unchanged, the new version B only introduces changes to the documentation that raise no compatibility issues with an implementation of version A.

Minor upgrade: ( MajorB = MajorA ) ( MinorB > MinorA )If the major version number of versions A and B are the same and the minor version number of B is higher than that of A, the new SAML version MAY introduce changes to the SAML schema and semantics but any changes that are introduced in B SHALL be compatible with version A.

Major upgrade: MajorB > MajorA If the major version of B number is higher than the major version of A, Version B MAY introduce changes to the SAML schema and semantics that are incompatible with A.

4.1. Assertion VersionA SAML authority MUST NOT issue any assertion whose version number is not supported.

A SAML relying party MUST reject any assertion whose major version number is not supported.

A SAML relying party MAY reject any assertion whose version number is higher than the highest supported version.

4.2. Request VersionA SAML authority SHOULD issue requests that specify the highest SAML version supported by both the sender and recipient.

If the SAML authority does not know the capabilities of the recipient it should assume that it supports the highest SAML version supported by the sender.


1405

1406

1407

1408

1409

14101411141214131414

1415

1416

141714181419

1420

1421142214231424

14251426142714281429

143014311432

1433

1434

1435

14361437

1438

14391440

14411442

38

4.3. Response VersionA SAML authority MUST NOT issue responses that specify a higher SAML version number than the corresponding request.

A SAML authority MUST NOT issue a response that has a major version number that is lower than the major version number of the corresponding request except to report the error RequestVersionTooHigh.

An error response resulting from incompatible protocol versions MUST result in reporting a top-level StatusCode value of VersionMismatch, and MAY result in reporting one of the following second-level values:

RequestVersionTooHighThe protocol version specified in the request is a major upgrade from the highest protocol version supported by the responder.

RequestVersionTooLowThe responder cannot respond to the particular request using the SAML version specified in the request because it is too low.

RequestVersionDeprecatedThe responder does not respond to any requests with the protocol version specified in the request.


1443

14441445

14461447

1448144914501451

145214531454

145514561457

145814591460

39

5. SAML & XML-Signature Syntax and Processing

SAML Assertions, Request and Response messages may be signed, with the following benefits: An Assertion signed by the asserting party (AP). This supports :

(1) Message integrity(2) Authentication of the asserting party to a relying party (RP)(3) If the signature is based on the asserting party's public-private key pair, then it

also provides for non-repudiation of origin. A SAML request or a SAML response message signed by the message originator. This

supports :(1) Message integrity(2) Authentication of message origin to a destination(3) If the signature is based on the originator's public-private key pair, then it also

provides for non-repudiation of origin.Note :

SAML documents may be the subject of signatures from different packaging contexts. [XMLSig] provides a framework for signing in XML and is the framework of choice. However, signing may also take place in the context of S/MIME or Java objects that contain SAML documents. One goal is to ensure compatibility with this type of "foreign" digital signing.

It is useful to characterize situations when a digital signature is NOT required in SAML. Assertions:

The asserting party has provided the assertion to the relying party, authenticated by means other than digital signature and the channel is secure. In other words, the RP has obtained the assertion from the AP directly (no intermediaries) through a secure channel and the AP has authenticated to the RP.

Request/Response messages: The originator has authenticated to the destination and the destination has obtained the assertion directly from the originator (no intermediaries) through secure channel(s).Many different techniques are available for "direct" authentication and secure channel between two parties. The list includes SSL, HMAC, password-based login etc. Also the security requirement depends on the communicating applications and the nature of the assertion transported.

All other contexts require the use of digital signature for assertions and request and response messages. Specifically:

(1) An assertion obtained by a relying party from an entity other than the asserting party MUST be signed by the asserting party.

(2) A SAML message arriving at a destination from an entity other than the originating site MUST be signed by the origin site.

5.1. Signing AssertionsAll SAML assertions MAY be signed using the XML Signature. This is reflected in the assertion schema – Section 2.3.


1461

1462

1463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493

149414951496149714981499

1500

15011502

40

5.2. Request/Response SigningAll SAML requests and responses MAY be signed using the XML Signature. This is reflected in the schema – Section 3.2 & 3.4.

5.3. Signature Inheritance

5.3.1. RationaleSAML assertions may be embedded within request or response messages or other XML messages, which may be signed. Request or response messages may themselves be contained within other messages that are based on other XML messaging frameworks (e.g., SOAP) and the composite object may be the subject of a signature. Another possibility is that SAML assertions or request/response messages are embedded within a non-XML messaging object (e.g., MIME package) and signed.

In such a case, the SAML sub-message (Assertion, request, response) may be viewed as inheriting a signature from the "super-signature" over the enclosing object, provided certain constraints are met.

(1) An assertion may be viewed as inheriting a signature from a super signature, if the super signature applies all the elements within the assertion.

A SAML request or response may be viewed as inheriting a signature from a super signature, if the super signature applies to all of the elements within the response.

5.3.2. Rules for SAML Signature InheritanceSignature inheritance occurs when SAML message (assertion/request/response) is not signed but is enclosed within signed SAML such that the signature applies to all of the elements within the message. In such a case, the SAML message is said to inherit the signature and may be considered equivalent to the case where it is explicitly signed. The SAML message inherits the "closest enclosing signature”.

But if SAML messages need to be passed around by themselves, or embedded in other messages, they would need to be signed as per section 5.1

5.4. XML Signature ProfileThe XML Signature [XMLSig] specification calls out a general XML syntax for signing data with many flexibilities and choices. This section details the constraints on these facilities so that SAML processors do not have to deal with the full generality of XML Signature processing.

5.4.1. Signing formatsXML Signature has three ways of representing signature in a document viz: enveloping, enveloped and detached.

SAML assertions and protocols MUST use the enveloped signatures for signing assertions and protocols. SAML processors should support use of RSA signing and verification for public key operations.

5.4.2. CanonicalizationMethodXML Signature REQUIRES the Canonical XML (omits comments) (http://www.w3.org/TR/2001/REC-xml-c14n-20010315). SAML implementations SHOULD use Canonical XML with no comments.


1503

15041505

1506

1507150815091510151115121513

1514151515161517151815191520

152115221523152415251526

15271528

1529

153015311532

153315341535

153615371538

1539154015411542

41

http://www.w3.org/TR/2001/REC-xml-c14n-20010315

5.4.3. Transforms[XMLSig] REQUIRES the enveloped signature transform http://www.w3.org/2000/09/xmldsig#enveloped-signature

5.4.4. KeyInfoSAML does not restrict or impose any restrictions in this area. Therefore following [XMLSig] keyInfo may be absent.

5.4.5. Binding between statements in a multi-statement assertionUse of signing does not affect semantics of statements within assertions in any way, as stated in this document Sections 1 through 4.


154315441545

154615471548

154915501551

42

http://www.w3.org/2000/09/xmldsig#enveloped-signature

6. SAML ExtensionsThe SAML schemas support extensibility. An example of an application that extends SAML assertions is the XTAML system for management of embedded trust roots [XTAML]. The following sections explain how to use the extensibility features in SAML to create extension schemas.

Note that elements in the SAML schemas are not blocked from substitution, so that all SAML elements MAY serve as the head element of a substitution group. Also, types are not defined as final, so that all SAML types MAY be extended and restricted. The following sections discuss only elements that have been specifically designed to support extensibility.

6.1. Assertion Schema ExtensionThe SAML assertion schema is designed to permit separate processing of the assertion package and the statements it contains, if the extension mechanism is used for either part.

The following elements are intended specifically for use as extension points in an extension schema; their types are set to abstract, so that the use of an xsi:type attribute with these elements is REQUIRED:

<Assertion>

<Condition>

<Statement>

<SubjectStatement>

<AdviceElement>

In addition, the following elements that are directly usable as part of SAML MAY be extended:

<AuthenticationStatement>

<AuthorizationDecisionStatement>

<AttributeStatement>

<AudienceRestrictionCondition>

Finally, the following elements are defined to allow elements from arbitrary namespaces within them, which serves as a built-in extension point without requiring an extension schema:

<AttributeValue>

<Advice>

6.2. Protocol Schema ExtensionThe following elements are intended specifically for use as extension points in an extension schema; their types are set to abstract, so that the use of an xsi:type attribute with these elements is REQUIRED:

<Query>

<SubjectQuery>

In addition, the following elements that are directly usable as part of SAML MAY be extended:

<Request>

<AuthenticationQuery>

<AuthorizationDecisionQuery>


1552

155315541555

15561557

15581559

1560

15611562

156315641565

1566

1567

1568

1569

1570

1571

1572

1573

1574

1575

15761577

1578

1579

1580

158115821583

1584

1585

1586

1587

1588

1589

43

<AttributeQuery>

<Response>

6.3. Use of Type Derivation and Substitution GroupsW3C XML Schema [Schema1] provides two principal mechanisms for specifying an element of an extended type: type derivation and substitution groups.

For example, a <Statement> element can be assigned the type NewStatementType by means of the xsi:type attribute. For such an element to be schema-valid, NewStatementType needs to be derived from StatementType. The following example of a SAML assertion assumes that the extension schema (represented by the new: prefix) has defined this new type:

<saml:Assertion …> <saml:Statement xsi:type="new:NewStatementType"> … </saml:Statement></saml:Assertion>

Alternatively, the extension schema can define a <NewStatement> element that is a member of a substitution group that has <Statement> as a head element. For the substituted element to be schema-valid, it needs to have a type that matches or is derived from the head element’s type. The following is an example of an extension schema fragment that defines this new element:

<xsd:element "NewStatement" type="new:NewStatementType" substitutionGroup="saml:Statement"/>

The substitution group declaration allows the <NewStatement> element to be used anywhere the SAML <Statement> element can be used. The following is an example of a SAML assertion that uses the extension element:

<saml:Assertion …> <new:NewStatement> … </new:NewStatement></saml:Assertion>

The choice of extension method has no effect on the semantics of the XML document but does have implications for interoperability.

The advantages of type derivation are as follows:

A document can be more fully interpreted by a parser that does not have access to the extension schema because a “native” SAML element is available.

At the time of writing, some W3C XML Schema validators do not support substitution groups, whereas the xsi:type attribute is widely supported.

The advantage of substitution groups is that a document can be explained without the need to explain the functioning of the xsi:type attribute.


1590

1591

1592

15931594

159515961597

159815991600160116021603

160416051606160716081609

16101611161216131614161516161617

16181619

1620

16211622

162316241625

1626

44

7. SAML-Defined IdentifiersThe following sections define URI-based identifiers for common authentication protocols and actions.

Where possible an existing URN is used to specify a protocol. In the case of IETF protocols the URN of the most current RFC that specifies the protocol is used. URI references created specifically for SAML have the initial stem:urn:oasis:names:tc:SAML:1.0:

7.1. Authentication Method IdentifiersThe <AuthenticationMethod> and <SubjectConfirmationMethod> elements perform different functions within the SAML architecture, although both can refer to the same underlying mechanisms. <AuthenticationMethod> is a part of an Authentication Statement, which describes an authentication act which occured in the past. The <AuthenticationMethod> indicates how that authentication was done. Note that the authentication statement does not provide the means to perform that authentication, such as a password, key or certificate.

In contrast, <SubjectConfirmationMethod> is a part of the <SubjectConfirmation>, which is used to allow the Relying Party to confirm that the request or message came from the System Entity that corresponds to the Subject in the statement. The <SubjectConfirmationMethod> indicates the method that the Relying Party can use to do this in the future. This may or may not have any relationship to an authentication that was performed previously. Unlike the Authentication Method, the <SubjectConfirmationMethod> may be accompanied with some piece of information, such as a certificate or key, which will allow the Relying Party to perform the necessary check.

Subject Confirmation Methods are defined in the SAML Profile or Profiles in which they are used [SAMLBind]. Additional methods may be added by defining new profiles or by private agreement.

The following identifiers refer to SAML specified Authentication methods.

7.1.1. Password :URI: urn:oasis:names:tc:SAML:1.0:am:password

The authentication was performed by means of a password.

7.1.2. Kerberos URI: urn:ietf:rfc:1510

The authentication was performed by means of the Kerberos protocol [RFC 1510], an instantiation of the Needham-Schroeder symmetric key authentication mechanism [Needham78] .

7.1.3. Secure Remote Password (SRP) URI: urn:ietf:rfc:2945

The authentication was performed by means of Secure Remote Password protocol as specified in [RFC 2945]


1627

16281629

1630163116321633

1634

16351636

1637163816391640

16411642

164316441645

164616471648

16491650

1651

1652

1653

1654

16551656

16571658

16591660

16611662

45

7.1.4. Hardware Token URI: urn:oasis:names:tc:SAML:1.0:am:HardwareToken

The authentication was performed by means of an unspecified hardware token.

7.1.5. SSL/TLS Certificate Based Client Authentication:URI: urn:ietf:rfc:2246

The authentication was performed using either the SSL or TLS protocol with certificate based client authentication. TLS is described in [RFC 2246].

7.1.6. X.509 Public Key URI: urn:oasis:names:tc:SAML:1.0:am:X509-PKI

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of an X.509 PKI [X.500][PKIX]. It may have been one of the mechanisms for which a more specific identifier has been defined below.

7.1.7. PGP Public Key URI: urn:oasis:names:tc:SAML:1.0:am:PGP

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a PGP web of trust [PGP]. It may have been one of the mechanisms for which a more specific identifier has been defined below.

7.1.8. SPKI Public Key URI: urn:oasis:names:tc:SAML:1.0:am:SPKI

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a SPKI PKI [SPKI]. It may have been one of the mechanisms for which a more specific identifier has been defined below.

7.1.9. XKMS Public Key URI: urn:oasis:names:tc:SAML:1.0:am:XKMS

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a XKMS trust service [XKMS]. It may have been one of the mechanisms for which a more specific identifier has been defined below.

7.1.10. XML Digital Signature URI: urn:ietf:rfc:3075

The authentication was performed by means of an XML digital signature [RFC 3075].

7.2. Action Namespace IdentifiersThe following identifiers MAY be used in the Namespace attribute of the <Action> element (see Section 2.4.4.1) to refer to common sets of actions to perform on resources.


16631664

1665

1666

1667

16681669

16701671

167216731674

16751676

167716781679

16801681

168216831684

16851686

168716881689

1690

1691

1692

1693

16941695

46

7.2.1. Read/Write/Execute/Delete/Control:URI: urn:oasis:names:tc:SAML:1.0:action:rwedc

Defined actions:

Read Write Execute Delete Control

These actions are interpreted in the normal manner, i.e.

ReadThe subject may read the resource

WriteThe subject may modify the resource

ExecuteThe subject may execute the resource

DeleteThe subject may delete the resource

ControlThe subject may specify the access control policy for the resource

7.2.2. Read/Write/Execute/Delete/Control with Negation:URI: urn:oasis:names:tc:SAML:1.0:action:rwedc-negation

Defined actions:

Read Write Execute Delete Control ~Read ~Write ~Execute ~Delete ~Control

The actions specified in section 7.2.1are interpreted in the same manner described there. Actions prefixed with a tilde ~ are negated permissions and are used to affirmatively specify that the stated permission is denied. Thus a subject described as being authorized to perform the action ~Read is affirmatively denied read permission.

A SAML authority MUST NOT authorize both an action and its negated form.

7.2.3. Get/Head/Put/Post:URI: urn:oasis:names:tc:SAML:1.0:action:ghpp

Defined actions:

GET HEAD PUT POST

These actions bind to the corresponding HTTP operations. For example a subject authorized to perform the GET action on a resource is authorized to retrieve it.

The GET and HEAD actions loosely correspond to the conventional read permission and the PUT and POST actions to the write permission. The correspondence is not exact however since a HTTP GET operation may cause data to be modified and a POST operation may cause modification to a resource other than the one specified in the request. For this reason a separate Action URI reference specifier is provided.

7.2.4. UNIX File Permissions:URI: urn:oasis:names:tc:SAML:1.0:action:unix


1696

1697

1698

1699

1700

17011702

17031704

17051706

17071708

17091710

1711

1712

1713

17141715

171617171718

1719

1720

1721

1722

1723

17241725

17261727172817291730

1731

1732

47

The defined actions are the set of UNIX file access permissions expressed in the numeric (octal) notation.

The action string is a four digit numeric code:

extended user group world

Where the extended access permission has the value

+2 if sgid is set

+4 if suid is set

The user group and world access permissions have the value

+1 if execute permission is granted

+2 if write permission is granted

+4 if read permission is granted

For example 0754 denotes the UNIX file access permission: user read, write and execute, group read and execute and world read.


17331734

1735

1736

1737

1738

1739

1740

1741

1742

1743

17441745

48

8. SAML Schema ListingsThe following sections contain complete listings of the assertion and protocol schemas for SAML.

8.1. Assertion SchemaFollowing is a complete listing of the SAML assertion schema [SAML-XSD].<?xml version="1.0" encoding="UTF-8"?><schema targetNamespace="urn:oasis:names:tc:SAML:1.0:assertion" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="unqualified">

<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/><annotation>

<documentation>draft-sstc-schema-assertion-3231.xsd</documentation></annotation><simpleType name="IDType">

<restriction base="string"/></simpleType><simpleType name="IDReferenceType">

<restriction base="string"/></simpleType><simpleType name="DecisionType">

<restriction base="string"><enumeration value="Permit"/><enumeration value="Deny"/><enumeration value="Indeterminate"/>

</restriction></simpleType><element name="AssertionIDReference" type="saml:IDReferenceType"/><element name="Assertion" type="saml:AssertionType"/><complexType name="AssertionType">

<sequence><element ref="saml:Conditions" minOccurs="0"/><element ref="saml:Advice" minOccurs="0"/><choice maxOccurs="unbounded">

<element ref="saml:Statement"/><element ref="saml:SubjectStatement"/><element ref="saml:AuthenticationStatement"/><element ref="saml:AuthorizationDecisionStatement"/><element ref="saml:AttributeStatement"/>

</choice><element ref = "ds:Signature" minOccurs="0"/>

</sequence><attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="AssertionID" type="saml:IDType" use="required"/><attribute name="Issuer" type="string" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/>

</complexType><element name="Conditions" type="saml:ConditionsType"/><complexType name="ConditionsType">

<choice minOccurs="0" maxOccurs="unbounded"><element ref="saml:AudienceRestrictionCondition"/><element ref="saml:Condition"/>


1746

1747

1748

174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802

49

</choice><attribute name="NotBefore" type="dateTime" use="optional"/><attribute name="NotOnOrAfter" type="dateTime" use="optional"/>

</complexType><element name="Condition" type="saml:ConditionAbstractType"/><complexType name="ConditionAbstractType" abstract="true"/><element name="AudienceRestrictionCondition" type="saml:AudienceRestrictionConditionType"/><complexType name="AudienceRestrictionConditionType">

<complexContent><extension base="saml:ConditionAbstractType">

<sequence><element ref="saml:Audience" maxOccurs="unbounded"/>


</complexContent></complexType><element name="Audience" type="anyURI"/><element name="Advice" type="saml:AdviceType"/><complexType name="AdviceType">

<choice minOccurs="0" maxOccurs="unbounded"><element ref="saml:AssertionIDReference"/><element ref="saml:Assertion"/><any namespace="##other" processContents="lax"/>

</choice></complexType><element name="Statement" type="saml:StatementAbstractType"/><complexType name="StatementAbstractType" abstract="true"/><element name="SubjectStatement" type="saml:SubjectStatementAbstractType"/><complexType name="SubjectStatementAbstractType" abstract="true">

<complexContent><extension base="saml:StatementAbstractType">



</complexContent></complexType><element name="Subject" type="saml:SubjectType"/><complexType name="SubjectType">

<choice><sequence>

<element ref="saml:NameIdentifier"/><element ref="saml:SubjectConfirmation" minOccurs="0"/>

</sequence><element ref="saml:SubjectConfirmation"/>

</choice></complexType><element name="NameIdentifier" type="saml:NameIdentifierType"/><complexType name="NameIdentifierType">


<attribute name="NameQualifier" type="string" use="optional"/><attribute name="Format" type="anyURI" use="optional"/>

</extension></simpleContent>

</complexType><element name="SubjectConfirmation" type="saml:SubjectConfirmationType"/><complexType name="SubjectConfirmationType">

<sequence><element ref="saml:ConfirmationMethod" maxOccurs="unbounded"/><element ref="saml:SubjectConfirmationData" minOccurs="0"/><element ref="ds:KeyInfo" minOccurs="0"/>


180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847184818491850185118521853185418551856185718581859186018611862186318641865

50

</sequence></complexType><element name="SubjectConfirmationData" type="anyType"/><element name="ConfirmationMethod" type="anyURI"/><element name="AuthenticationStatement" type="saml:AuthenticationStatementType"/><complexType name="AuthenticationStatementType">


<sequence><element ref="saml:SubjectLocality" minOccurs="0"/><element ref="saml:AuthorityBinding" minOccurs="0" maxOccurs="unbounded"/>

</sequence><attribute name="AuthenticationMethod" type="anyURI"/><attribute name="AuthenticationInstant" type="dateTime"/>


</complexType><element name="SubjectLocality" type="saml:SubjectLocalityType"/><complexType name=" SubjectLocalityType ">

<attribute name="IPAddress" type="string" use="optional"/><attribute name="DNSAddress" type="string" use="optional"/>

</complexType><element name="AuthorityBinding" type="saml:AuthorityBindingType"/><complexType name="AuthorityBindingType">

<attribute name="AuthorityKind" type="QName" use="required"/><attribute name="Location" type="anyURI" use="required"/><attribute name="Binding" type="anyURI" use="required"/>

</complexType><element name="AuthorizationDecisionStatement"

type="saml:AuthorizationDecisionStatementType"/><complexType name="AuthorizationDecisionStatementType">


<sequence><element ref="saml:Action" maxOccurs="unbounded"/><element ref="saml:Evidence" minOccurs="0"/>

</sequence><attribute name="Resource" type="anyURI" use="required"/><attribute name="Decision" type="saml:DecisionType" use="required"/>


</complexType><element name="Action" type="saml:ActionType"/><complexType name="ActionType">


<attribute name="Namespace" type="anyURI"/></extension>

</simpleContent></complexType><element name="Evidence" type="saml:EvidenceType"/><complexType name="EvidenceType">

<choice maxOccurs="unbounded"><element ref="saml:AssertionIDReference"/><element ref="saml:Assertion"/>

</choice></complexType><element name="AttributeStatement" type="saml:AttributeStatementType"/><complexType name="AttributeStatementType">

<complexContent>


186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889189018911892189318941895189618971898189919001901190219031904190519061907190819091910191119121913191419151916191719181919192019211922192319241925192619271928

51

<element ref="saml:Attribute" maxOccurs="unbounded"/></sequence>


</complexType><element name="AttributeDesignator" type="saml:AttributeDesignatorType"/><complexType name="AttributeDesignatorType">

<attribute name="AttributeName" type="string" use="required"/><attribute name="AttributeNamespace" type="anyURI" use="required"/>

</complexType><element name="Attribute" type="saml:AttributeType"/><complexType name="AttributeType">

<complexContent><extension base="saml:AttributeDesignatorType">

<sequence><element ref="saml:AttributeValue" maxOccurs="unbounded"/>


</complexContent></complexType><element name="AttributeValue" type="saml:anyType"/>

</schema>

8.2. Protocol SchemaFollowing is a complete listing of the SAML protocol schema [SAMLP-XSD].<?xml version="1.0" encoding="UTF-8"?><schema

targetNamespace="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified"><import namespace="urn:oasis:names:tc:SAML:1.0:assertion" schemaLocation="draft-sstc-schema-assertion-3231.xsd"/><import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/><annotation>

<documentation>draft-sstc-schema-protocol-3231.xsd</documentation></annotation><complexType name="RequestAbstractType" abstract="true">

<sequence><element ref="samlp:RespondWith" minOccurs="0" maxOccurs="unbounded"/><element ref = "ds:Signature" minOccurs="0"/>

</sequence><attribute name="RequestID" type="saml:IDType" use="required"/><attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/>

</complexType><element name="RespondWith" type="QName"/><element name="Request" type="samlp:RequestType"/><complexType name="RequestType">

<complexContent><extension base="samlp:RequestAbstractType">

<choice>


192919301931193219331934193519361937193819391940194119421943194419451946194719481949195019511952

1953

19541955195619571958195919601961196219631964196519661967196819691970197119721973197419751976197719781979198019811982198319841985198619871988

52

<element ref="samlp:Query"/><element ref="samlp:SubjectQuery"/><element ref="samlp:AuthenticationQuery"/><element ref="samlp:AttributeQuery"/><element ref="samlp:AuthorizationDecisionQuery"/><element ref="saml:AssertionID" maxOccurs="unbounded"/><element ref="samlp:AssertionArtifact" maxOccurs="unbounded"/>

</choice></extension>

</complexContent></complexType><element name="AssertionArtifact" type="string"/><element name="Query" type="samlp:QueryAbstractType"/><complexType name="QueryAbstractType" abstract="true"/><element name="SubjectQuery" type="samlp:SubjectQueryAbstractType"/><complexType name="SubjectQueryAbstractType" abstract="true">

<complexContent><extension base="samlp:QueryAbstractType">



</complexContent></complexType><element name="AuthenticationQuery" type="samlp:AuthenticationQueryType"/><complexType name="AuthenticationQueryType">


<attribute name="AuthenticationMethod" type="anyURI"/></extension>

</complexContent></complexType><element name="AttributeQuery" type="samlp:AttributeQueryType"/><complexType name="AttributeQueryType">


<sequence><element ref="saml:AttributeDesignator" minOccurs="0" maxOccurs="unbounded"/>

</sequence><attribute name="Resource" type="anyURI" use="optional"/>


</complexType><element name="AuthorizationDecisionQuery" type="samlp:AuthorizationDecisionQueryType"/><complexType name="AuthorizationDecisionQueryType">


<sequence><element ref="saml:Action" maxOccurs="unbounded"/><element ref="saml:Evidence" minOccurs="0" maxOccurs="unbounded"/>

</sequence><attribute name="Resource" type="anyURI" use="required"/>


</complexType><complexType name="ResponseAbstractType" abstract="true">

<sequence><element ref = "ds:Signature" minOccurs="0"/>

</sequence><attribute name="ResponseID" type="saml:IDType" use="required"/>


198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012201320142015201620172018201920202021202220232024202520262027202820292030203120322033203420352036203720382039204020412042204320442045204620472048204920502051

53

<attribute name="InResponseTo" type="saml:IDReferenceType" use="optional"/>

<attribute name="MajorVersion" type="integer" use="required"/><attribute name="MinorVersion" type="integer" use="required"/><attribute name="IssueInstant" type="dateTime" use="required"/><attribute name="Recipient" type="anyURI" use="optional"/>

</complexType><element name="Response" type="samlp:ResponseType"/><complexType name="ResponseType">

<complexContent><extension base="samlp:ResponseAbstractType">

<sequence><element ref="samlp:Status"/><element ref="saml:Assertion" minOccurs="0" maxOccurs="unbounded"/>


</complexContent></complexType><element name="Status" type="samlp:StatusType"/><complexType name="StatusType">

<sequence><element ref="samlp:StatusCode"/><element ref="samlp:StatusMessage" minOccurs="0" maxOccurs="unbounded"/><element ref="samlp:StatusDetail" minOccurs="0"/>

</sequence></complexType><element name="StatusCode" type="samlp:StatusCodeType"/><complexType name="StatusCodeType">

<sequence><element ref="samlp:StatusCode" minOccurs="0"/>

</sequence><attribute name="Value" type="QName" use="required"/>

</complexType><element name="StatusMessage" type="string"/><element name="StatusDetail" type="samlp:StatusDetailType"/><complexType name="StatusDetailType">

<sequence><any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>


</schema>


205220532054205520562057205820592060206120622063206420652066206720682069207020712072207320742075207620772078207920802081208220832084208520862087208820892090209120922093209420952096

54

9. References[Kern-84] B. Kernighan, Rob Pike The UNIX Programming Environment, (March

1984) Prentice Hall Computer Books; [Needham78] R. Needham et al., Using Encryption for Authentication in Large Networks

of Computers, Communications of the ACM, Vol. 21 (12), pp. 993-999, December 1978.

[PGP] Atkins, D., Stallings, W. and P. Zimmermann, PGP Message Exchange Formats, RFC 1991, August 1996.

[PKCS1] B. Kaliski, PKCS #1: RSA Encryption Version 2.0, RSA Laboratories, also IETF RFC 2437, October 1998. http://www.ietf.org/rfc/rfc2437.txt

[PKCS7] B. Kaliski., PKCS #7: Cryptographic Message Syntax, Version 1.5, RFC 2315, March 1998.

[PKIX] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459, January 1999.

[RFC 1510] J. Kohl, C. Neuman. The Kerberos Network Authentication Requestor (V5). September 1993. http://www.ietf.org/rfc/rfc1510.txt

[RFC 2104] H. Krawczyk et al., HMAC: Keyed Hashing for Message Authentication, http://www.ietf.org/rfc/rfc2104.txt, IETF RFC 2104, February 1997.

[RFC 2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997

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

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

[RFC 2630] R. Housley. Cryptographic Message Syntax. June 1999. http://www.ietf.org/rfc/rfc630.txt

[RFC 2648] R. Moats. A URN Namespace for IETF Documents. August 1999. http://www.ietf.org/rfc/rfc2648.txt

[RFC 2945] T. Wu, The SRP Authentication and Key Exchange System, September 2000, http://www.ietf.org/rfc/rfc2945.txt [RFC 3075] D. Eastlake, J. Reagle, D. Solo. XML-Signature Syntax and Processing. March 2001. http://www.ietf.org/rfc/rfc3075.txt

[SAMLBind] P. Mishra et al., Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML), http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-07.pdf, OASIS, December 2001.

[SAMLConform] TBS[SAMLGloss] J. Hodges et al., Glossary for the OASIS Security Assertion Markup

Language (SAML), http://www.oasis-open.org/committees/security/docs/draft-sstc-glossary-02.pdf, OASIS, December 2001.

[SAMLP-XSD] P. Hallam-Baker et al., SAML protocol schema, http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-protocol-21.xsd, OASIS, December 2001.

[SAMLSecure] TBS


2097

20982099210021012102210321042105210621072108210921102111211221132114211521162117211821192120212121222123212421252126212721282129213021312132213321342135213621372138213921402141

55

http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-protocol-21.xsd

http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-protocol-21.xsd

http://www.oasis-open.org/committees/security/docs/draft-sstc-glossary-02.pdf

http://www.oasis-open.org/committees/security/docs/draft-sstc-glossary-02.pdf

http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-07.xsd

http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-07.xsd

http://www.ietf.org/rfc/rfc3075.txt










[SAML-XSD] P. Hallam-Baker et al., SAML assertion schema, http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-21.xsd, OASIS, December 2001.

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

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

[SPKI] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. SPKI Certificate Theory, RFC 2693, September 1999.

[UNICODE-C] M. Davis, M. J. Dürst,http://www.unicode.org/unicode/reports/tr15/tr15-21.html, UNICODE Consortium

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

[W3C-CharMod] M. J. Dürst,, Unicode Normalization Forms http://www.w3.org/TR/charmod/, World Wide Web Consortium.

[X.500] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.

[XKMS] W. Ford, P. Hallam-Baker, B. Fox, B. Dillaway, B. LaMacchia, J. Epstein, J. Lapp, XML Key Management Specification (XKMS), W3C Note 30 March 2001, http://www.w3.org/TR/xkms/

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

[XMLEnc] XML Encryption Specification, In development.[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing,

http://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.[XMLSig-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-

xmldsig-core-20001031/xmldsig-core-schema.xsd. [XTAML] P. Hallam-Baker, XML Trust Axiom Markup Language 1.0,

http://www.xmltrustcenter.org/, VeriSign Inc. September 2001.


2142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172

56

http://www.xmltrustcenter.org/

http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd

http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/REC-xml

http://www.w3.org/TR/xkms/

http://www.w3.org/TR/charmod/



http://www.w3.org/TR/WD-charreq

http://www.unicode.org/unicode/reports/tr15/tr15-21.html

http://www.unicode.org/unicode/reports/tr15/tr15-21.html

http://www.w3.org/TR/xmlschema-2

http://www.w3.org/TR/xmlschema-1/

http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-21.xsd

http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-21.xsd

10. AcknowledgementsThe editors would like to acknowledge the contributions of the OASIS SAML Technical Committee, whose voting members at the time of publication were:

Allen Rogers, AuthenticaIrving Reid, Baltimore TechnologiesKrishna Sankar, Cisco Systems IncSimon Godik, CrosslogixGil Pilz, E2openHal Lockhart, Entegrity SolutionsCarlisle Adams, Entrust Inc.Robert Griffin, Entrust Inc.Don Flinn, HitachiJoe Pato, Hewlett-Packard (co-Chair)Jason Rouault, Hewlett-PackardMarc Chanliau, NetegrityChris McLaren, NetegrityPrateek Mishra, NetegrityCharles Knouse, OblixSteve Anderson, OpenNetworkRob Philpott, RSA SecurityJahan Moreh, SigabaBhavna Bhatnagar, Sun MicrosystemsJeff Hodges, Sun Microsystems (co-Chair)Eve Maler, Sun Microsystems (Former Chair)Aravindan Ranganathan, Sun MicrosystemsEmily Xu, Sun MicrosystemsBob Morgan, University of WashingtonPhillip Hallam-Baker, VeriSign Inc.

The editors would also like to thank the following people for their contributions:Stephen Farrell, Baltimore TechnologiesDavid Orchard, BEA SystemsTim Moses, Entrust Inc.Nigel Edwards, Hewlett-PackardMarc Chanliau, NetegrityScott Cantor, The Ohio State UniversityDarren Platt, Formerly with RSA SecurityBob Blakley IBM Tivoli SoftwareMarlena Erdos, Tivoli


2173

217421752176217721782179218021812182218321842185218621872188218921902191219221932194219521962197219821992200

22012202220322042205220622072208220922102211221222132214221522162217221822192220222122222223

57


222422252226

58

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

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

Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001. All Rights Reserved.

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

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

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


2227

222822292230223122322233223422352236

223722382239

22402241

22422243224422452246224722482249

22502251

22522253225422552256

59