1 Introduction

1.1 Purpose

This specification defines the concepts and operations of Version 2 of the Service Provisioning Markup Language (SPML). SPML is an XML-based provisioning request-and-response protocol.

1.2 Organization

The body of this specification is organized into three major sections: Concepts, Protocol and Conformance.

· The Concepts section introduces the main ideas in SPMLv2. Subsections highlight significant features that later sections will discuss in more detail.

· The Protocol section first presents an overview of protocol features and then discusses the purpose and behavior of each protocol operation. The core operations are presented in an order that permits a continuing set of examples. Subsequent sections present optional operations.

Each section that describes an operation includes:

- The relevant XML Schema

- A normative subsection that describes the request for the operation

- A normative subsection that describes the response to the operation

- A non-normative sub-section that discusses examples of the operation

· The Conformance section describes the aspects of this protocol that a requestor or provider must support in order to be considered conformant.

· A Security and Privacy Considerations section describes risks that an implementer of this protocol should weigh in deciding how to deploy this protocol in a specific environment.

Appendices contain additional information that supports the specification, including references to other documents.

1.3 Audience

The PSTC intends this specification to meet the needs of several audiences.

One group of readers will want to know: "What is SPML?”
A reader of this type should pay special attention to the Concepts section.

A second group of readers will want to know: "How would I use SPML?"
A reader of this type should read the Protocol section
(with special attention to the examples).

A third group of readers will want to know: "How must I implement SPML?"
A reader of this type must read the Protocol section
(with special attention to normative request and response sub-sections).

A reader who is already familiar with SPML 1.0 will want to know: “What is new in SPMLv2?”
A reader of this type should read the Concepts section thoroughly.

1.4 Notation

1.4.1 Normative sections

Normative sections of this specification are labeled as such. The title of a normative section will contain the word “normative” in parentheses, as in the following title: “Syntax (normative)”.

1.4.2 Normative terms

This specification contains schema that conforms to W3C XML Schema and contains normative text that describes the syntax and semantics of XML-encoded policy statements.

The keywords "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 [RFC2119]

"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 capitalized when used to unambiguously specify requirements of the protocol or 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.

1.4.3 Typographical conventions

This specification uses the following typographical conventions in text:

Format	Description	Indicates
xmlName	monospace font	The name of an XML attribute, element or type.
“attributeName”	monospace font surrounded by double quotes	An instance of an XML attribute.
‘attributeValue’	monospace font surrounded by double quotes	A literal value (of type string).
“attributeName=’value’”	monospace font name followed by equals sign and value surrounded by single quotes	An instance of an XML attribute value. Read as “a value of (value) specified for an instance of the (attributeName) attribute.”
{XmlTypeName} or {ns:XmlTypeName}	monospace font surrounded by curly braces	The name of an XML type.
<xmlElement> or <ns:xmlElement>	monospace font surrounded by <>	An instance of an XML element.

Terms in italic boldface are intended to have the meaning defined in the Glossary.

Listings of SPML schemas appear like this.

Example code listings appear like this.

1.4.4 Namespaces

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

· The prefix dsml: stands for the Directory Services Markup Language namespace [DSML].

· The prefix xsd: stands for the W3C XML Schema namespace [XSD].

· The prefix spml: stands for the SPMLv2 Core XSD namespace
[SPMLv2-CORE].

· The prefix spmlasync: stands for the SPMLv2 Async Capability XSD namespace.
[SPMLv2-ASYNC].

· The prefix spmlbatch: stands for the SPMLv2 Batch Capability XSD namespace
[SPMLv2-BATCH].

· The prefix spmlbulk: stands for the SPMLv2 Bulk Capability XSD namespace
[SPMLv2-BULK].

· The prefix spmlpass: stands for the SPMLv2 Password Capability XSD namespace
[SPMLv2-PASS].

· The prefix spmlref: stands for the SPMLv2 Reference Capability XSD namespace
[SPMLv2-REF].

· The prefix spmlsearch: stands for the SPMLv2 Search Capability XSD namespace
[SPMLv2-SEARCH].

· The prefix spmlsuspend: stands for the SPMLv2 Suspend Capability XSD namespace
[SPMLv2-SUSPEND].

· The prefix spmlupdates: stands for the SPMLv2 Updates Capability XSD namespace
[SPMLv2-UPDATES].

2 Concepts

SPML Version 2 (SPMLv2) builds on the concepts defined in SPML Version 1.

The basic roles of Requesting Authority (RA) and Provisioning Service Provider (PSP) are unchanged. The core protocol continues to define the basis for interoperable management of Provisioning Service Objects (PSO). However, the concept of Provisioning Service Target (PST) takes on new importance in SPMLv2.

2.1 Domain Model

The following section describes the main conceptual elements of the SPML domain model. The Entity Relationship Diagram (ERD) in Figure 1 shows the basic relationships between these elements.

Figure 1. Domain model elements

2.1.1 Requestor

A Requesting Authority (RA) or requestor is a software component that issues well-formed SPML requests to a Provisioning Service Provider. Examples of requestors include:

· Portal applications that broker the subscription of client requests to system resources

· Service subscription interfaces within an Application Service Provider

Trust relationship. In an end-to-end integrated provisioning scenario, any component that issues an SPML request is said to be operating as a requestor. This description assumes that the requestor and its provider have established a trust relationship between them. The details of establishing and maintaining this trust relationship are beyond the scope of this specification.

2.1.2 Provider

A Provisioning Service Provider (PSP) or provider is a software component that listens for, processes, and returns the results for well-formed SPML requests from a known requestor. For example, an installation of an Identity Management system could serve as a provider.

Trust relationship. In an end-to-end integrated provisioning scenario, any component that receives and processes an SPML request is said to be operating as a provider. This description assumes that the provider and its requestor have established a trust relationship between them. The details of establishing and maintaining this trust relationship are beyond the scope of this specification.

2.1.3 Target

A Provisioning Service Target (PST) or target represents a destination or endpoint that a provider makes available for provisioning actions.

A target is not a provider. A requestor asks a provider to act upon objects that the provider manages. Each target is a container for objects that a provider manages.

A target may not be an actual endpoint. A target may represent a traditional user account source (such as a Windows NT domain or a directory service instance), or a target may represent an abstract collection of endpoints.

Every provider exposes at least one target. Each target represents a destination or endpoint (e.g., a system, application or service—or a set of systems, applications, and services) to which the provider can provision (e.g., create or modify accounts).

A target is a special, top-level object that:

· A requestor can discover from the provider

· No requestor can add, modify, delete or otherwise act upon

· May contain any number of provisioning service objects (PSO) upon which a requestor may act

· May contain a schema that defines the XML structure of the provisioning service objects (PSO) that the target may contain

· May define which schema entities the target supports

· May expose capabilities:

- That apply to every supported schema entity

- That apply only to specific schema entities

The SPMLv2 model does not restrict a provider’s targets other than to specify that:

· A provider (PSP) must uniquely identify each target that it exposes.

· A provider must uniquely identify each object (PSO) that a target contains.

· Exactly one target must contain each object (PSO) that the provider manages.

2.1.3.1Target Schema

The schema for each target defines the XML structure of the objects (PSO) that the target may contain.

SPMLv2 does not specify a required format for the target schema. For example, a target schema could be XML Schema [XSD] or (a target schema could be) SPML1.0 Schema [SPMLv2-Profile-DSML].

Each target schema includes a schema namespace. The schema namespace indicates (to any requestor that recognizes the schema namespace) how to interpret the schema.

A provider must present any object (to a requestor) as XML that is valid according to the schema of the target that contains the object. A requestor must accept and manipulate, as XML that is valid according to the schema of the target, any object that a target contains.

2.1.3.2Supported Schema Entities

A target may declare that it supports only a subset of the entities (e.g., object classes or top-level elements) in its schema. A target that does not declare such a subset is assumed to support every entity in its schema.

A provider must implement the basic SPML operations for any object that is an instance of a supported schema entity (i.e., a schema entity that the target containing the object supports).

2.1.3.3Capabilities

A target may also support a set of capabilities. Each capability defines optional operations or semantics (in addition to the basic operations that the target must support for each supported schema entity).

A capability must be either "standard" or "custom":

· The OASIS PSTC defines each standard capability in an SPML namespace.
See the section titled “Namespaces”.

· Anyone may define a custom capability in another namespace.

A target may support a capability for all of its supported schema entities or (a target may support a capability) only for specific subset of its supported schema entities. Each capability may specify any number of supported schema entities to which it applies. A capability that does not specify at least one supported schema entity implicitly declares that the capability applies to every schema entity that the target supports.

Capability-defined operations. If a capability defines an operation and if the target supports that capability for a schema entity of which an object is an instance, then the provider must support that optional operation for that object. For example, if a target supports the Password Capability for User objects (but not for Group objects), then a requestor may ask the provider to perform the ‘resetPassword’ operation for any User object (but the provider will fail any request to ‘resetPassword’ for a Group).

If a capability defines more than one operation and a target supports that capability (for any set of schema entities), then the provider must support (for any instance of any of those schema entities on that target) every operation that the capability defines. See the section titled "Conformance".

Capability-specific data. A capability may imply that data specific to that capability may be associated with an object. Capability-specific data are not part of the schema-defined data of an object. SPML operations handle capability-specific data separately from schema-defined data. Any capability that implies capability-specific data must define the structure of that data.
See the section titled "CapabilityData".

Of the capabilities that SPML defines, only one capability actually implies that capability-specific data may be associated with an object. The Reference Capability implies that an object (that is an instance of a schema entity for which the provider supports the Reference Capability) may contain any number of references to other objects. The Reference Capability defines the structure of a reference element. For more information, see the section titled "Reference Capability".

2.1.4 Provisioning Service Object (PSO)

A Provisioning Service Object (PSO), sometimes simply called an object, represents a data entity or an information object on a target. For example, a provider would represent as an object each account that the provider manages.

NOTE: Within this document, the term “object” (unless otherwise qualified) refers to a PSO.

Every object is contained by exactly one target. Each object has a unique identifier (PSO-ID).

2.2 Core Protocol

SPMLv2 retains the SPML1.0 concept of a “core protocol”. The SPMLv2 Core XSD defines:

· Basic operations (such as add, lookup, modify and delete)

· Basic and extensible data types and elements

· The means to expose individual targets and optional operations

The SPMLv2 Core XSD also defines modal mechanisms that allow a requestor to:

· Specify that a requested operation must be executed asynchronously
(or to specify that a requested operation must be executed synchronously)

· Recognize that a provider has chosen to execute an operation asynchronously

· Obtain the status (and any result) of an asynchronous request

· Stop execution of an asynchronous request

Conformant SPMLv2 implementations must support the core protocol, including:

· The new listTargets operation

· The basic operations for every schema entity that a target supports

· The modal mechanisms for asynchronous operations

(For more information, see the section titled “Conformance”).

2.3 Profile

SPMLv2 defines two “profiles” in which a requestor and provider may exchange SPML protocol:

· XML Schema as defined in the “SPMLv2 XSD Profile” [SPMLv2-Profile-XSD].

· DSMLv2 as defined in the “SPMLv2 DSMLv2 Profile” [SPMLv2-Profile-DSML].

A requestor and a provider may exchange SPML protocol in any profile to which they agree.

SPML 1.0 defined file bindings and SOAP bindings that assumed the SPML1.0 Schema for DSML [SPML-Bind]. The SPMLv2 DSMLv2 Profile provides a degree of backward compatibility with SPML 1.0. The DSMLv2 profile supports a schema model similar to that of SPML 1.0.

The DSMLv2 Profile may be more convenient for applications that access mainly targets that are LDAP or X500 directory services. The XSD Profile may be more convenient for applications that access mainly targets that are web services.

3 Protocol

General Aspects. The general model adopted by this protocol is that a requestor (client) asks a provider (server) to perform operations. In the simplest case, each request for an SPML operation is processed individually and is processed synchronously. The first sub-section, “Request/Response Model”, presents this model and discusses mechanisms that govern asynchronous execution. Sub-sections such as “Identifiers”, “Selection”, “CapabilityData” and “Transactional Semantics” also describe aspects of the protocol that apply to every operation.

Core Operations. In order to encourage adoption of this standard, this specification minimizes the set of operations that a provider must implement. The Core Operations section discusses these required operations.

Standard Capabilities. This specification also defines optional operations.  Some operations are optional (rather than required) because those operations may be more difficult for a provider to implement for certain kinds of targets. Some operations are optional because those operations may apply only to specific types of objects on a target. This specification defines a set of standard capabilities, each of which groups optional operations that are functionally related. The remainder of the Operations section discusses optional operations (such as search) that are associated with SPMLv2’s standard capabilities.

Custom Capabilities. The capability mechanism in SPMLv2 is open and allows an individual provider (or any third party) to define additional custom capabilities.  See the sub-section titled "Custom Capabilities".

3.1 Request/Response Model

The general model adopted by this protocol is that a requestor (client) asks a provider (server) to perform an operation. A requestor asks a provider to perform an operation by sending to the provider an SPML request that describes the operation. The provider examines the request and, if the provider determines that the request is valid, the provider does whatever is necessary to implement the requested operation. The provider also returns to the requestor an SPML response that details any status or error that pertains to the request.

</sequence>

</complexType>

</restriction>

</simpleType>

<documentation>Contains elements specific to a capability.</documentation>

</annotation>

</extension>

</complexContent>

</complexType>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

</restriction>

</simpleType>

</restriction>

</simpleType>

</sequence>

</extension>

</complexContent>

</complexType>

The following subsections describe aspects of this request/response model in more detail:

· the exchange of requests and responses between requestor and provider

· synchronous and asynchronous execution of operations

· individual and batch requests

3.1.1 Conversational flow

A requestor asks a provider to do something by issuing an SPML request. A provider responds exactly once to each request. Therefore, the simplest conversation (i.e., pattern of exchange) between a requestor and a provider is an orderly alternation of request and response. However, the SPML protocol does not require this. A requestor may issue any number of concurrent requests to a single provider. A requestor may issue any number of concurrent requests to multiple providers.

Recommend requestID. Each SPML request should specify a reasonably unique identifier as the value of “requestID”. See the section titled "Request Identifier (normative)”. This allows a requestor to control the identifier for each requested operation and (also allows the requestor) to match each response to the corresponding request without relying on the transport protocol that underlies the SPML protocol exchange.

3.1.2 Status and Error codes

A provider’s response always specifies a “status”. This value tells the requestor what the provider did with (the operation that was described by) the corresponding request.

If a provider’s response specifies “status=’failure’”, then the provider’s response must also specify an “error”. This value tells the requestor what type of problem prevented the provider from executing (the operation that was described by) the corresponding request.

The “status” and “error” attributes of a response apply to (the operation that is described by) the corresponding request. This is straightforward for most requests. The status and batch operations present the only subtleties.

· A status request asks for the status of another operation that the provider is already executing asynchronously. See the section titled "Synchronous and asynchronous operations” below. A status response has status and error attributes that tell the requestor what happened to the status request itself. However, the response to a successful status operation also contains a nested response that tells what has happened to the operation that the provider is executing asynchronously.

· A batch request contains nested requests (each of which describes an operation). The response to a batch request contains nested responses (each of which corresponds to a request that was nested in the batch request). See the section titled "Individual and batch requests” below.

3.1.2.1Status (normative)

A provider’s response MUST specify “status” as one of the following values: ‘success’, ‘failure’ or ‘pending’.

· A response that specifies “status=’success’”
indicates that the provider has completed the requested operation.
In this case, the response contains any result of the operation
and the response MUST NOT specify “error” (see below).

· A response that specifies “status=’failure’”
indicates that the provider could not complete the requested operation.
In this case, the response MUST specify an appropriate value of “error” (see below).

· A response that specifies “status=’pending’”
indicates that the provider will execute the requested operation asynchronously
(see “Synchronous and asynchronous operations” below).
In this case, the response acknowledges the request and contains the “requestID” value that identifies the asynchronous operation.

3.1.2.2Error (normative)

A response that specifies “status=’failure’” MUST specify an appropriate value of “error”.

· A response that specifies “error=’malformedRequest’”
indicates that the provider could not interpret the request.
This includes, but is not limited to, parse errors.

· A response that specifies “error=’unsupportedOperation’”
indicates that the provider does not support the operation that the request specified.

· A response that specifies “error=’unsupportedIdentifierType’”
indicates that the provider does not support the type of identifier specified in the request.

· A response that specifies “error=’noSuchIdentifier’”
indicates that the provider (supports the type of identifier specified in the request,
but the provider) cannot find the object to which an identifier refers.

· A response that specifies “error=’unsupportedExecutionMode’”
indicates that the provider does not support the requested mode of execution.

· A response that specifies “error=’invalidContainment’”
indicates that the provider cannot add the specified object to the specified container.

- The request may have specified as container an object that does not exist.

- The request may have specified as container an object that is not a valid container.
The target schema implicitly or explicitly declares each supported schema entity.
An explicit declaration of a supported schema entity specifies
whether an instance of that schema entity may contain other objects.

- The request may have specified a container that is may not contain the specified object.
The target (or a system or application that underlies the target) may restrict the types of objects that the provider can add to the specified container. The target (or a system or application that underlies the target) may restrict the containers to which the provider can add the specified object.

· A response that specifies “error=’resultSetTooLarge’” indicates that the provider cannot return (or cannot queue for subsequent iteration—as in the case of an overlarge search result) the entire result of an operation.

In this case, the requestor may be able to refine the request so as to produce a smaller result. For example, a requestor might break a single search operation into several search requests, each of which selects a sub-range of the original (overlarge) search result.

· A response that specifies “error=’customError’” indicates that the provider has encountered an error that none of the standard error code values describes.
In this case, the provider’s response SHOULD provide error information in a format that is available to the requestor. SPMLv2 does not specify the format of a custom error.

Several additional values of {ErrorCode} apply only to certain operations. (For example, “error=’unsupportedProfile’” applies only to the listTargets operation. Currently, “error=’invalidIdentifier’” and “error=’alreadyExists’” apply only to the add operation.) The section that discusses each operation also discusses any value of {ErrorCode} that is specific to that operation.

3.1.2.3Error Message (normative)

A response MAY contain any number of <errorMessage> elements. The XML content of each <errorMessage> is a string that provides additional information about the status or failure of the requested operation.

· A response that specifies “status=’failure’” SHOULD contain at least one <errorMessage> that describes each condition that caused the failure.

· A response that specifies “status=’success’” MAY contain any number of <errorMessage> elements that describe warning conditions.

· A response that specifies “status=’success’” SHOULD NOT contain an <errorMessage> element that describes an informational message

The content of an <errorMessage> is intended for logging or display to a human administrator (rather than for programmatic interpretation).

3.1.3 Synchronous and asynchronous operations

A provider may execute a requested operation either synchronously or asynchronously.

· Synchronous: operation before response. If a provider executes a requested operation synchronously, the provider completes the requested operation before the provider returns a response to the requestor. The response will include the status and any error or result.

· Asynchronous: response before operation. If a provider executes a requested operation asynchronously, the provider returns to the requestor a response (that indicates that the operation will be executed asynchronously) before the provider executes the requested operation. The response will specify “status=’pending’” and will specify a “requestID” value that the requestor must use in order to cancel the asynchronous operation or (in order to) obtain the status or results of the asynchronous operation.

- If a request specifies “requestID”, then the provider’s response to that request will specify the same “requestID” value.

- If the request omits “requestID”, then the provider’s response to that request will specify a “requestID” value that is generated by the provider.

A requestor may specify the execution mode for an operation in its request or (a requestor may omit the execution mode and thus) allow the provider to decide the execution mode (for the requested operation). If the requestor specifies an execution mode that the provider cannot support for the requested operation, then the provider will fail the request.

3.1.3.1ExecutionMode attribute

A requestor uses the optional “executionMode” attribute of an SPML request to specify that the provider must execute the specified operation synchronously or (to specify that the provider must execute the specified operation) asynchronously. If a requestor omits the “executionMode” attribute from an SPML request, the provider decides whether to execute the requested operation synchronously or (to execute the requested operation) asynchronously.

3.1.3.2Async Capability

A provider uses the Async Capability that is defined as part of SPMLv2 to tell any requestor that the provider supports asynchronous execution of requested operations on objects contained by that target. A target may further refine this declaration to apply only to specific types of objects (i.e., for a specific subset of supported schema entities) on the target.

SPMLv2’s Async Capability also defines two operations that a requestor may use to manage other operations that a provider is executing asynchronously:

· A status operation allows a requestor to check the status (and optionally results) of an operation (or of all operations)

· A cancel operation asks the provider to stop executing an operation.

For more information, see the section titled "Async Capability".

3.1.3.3Determining execution mode

By default, a requestor allows a provider to decide whether to execute a requested operation synchronously or asynchronously. A requestor that needs the provider to execute a requested operation in a particular manner must specify this in the request. Each subsection that follows describes one of the four possibilities:

· Requestor specifies synchronous execution

· Requestor specifies asynchronous execution

· Provider chooses synchronous execution

· Provider chooses asynchronous execution

The following subsections normatively apply to every SPMLv2 operation unless the normative text that describes an operation specifies otherwise.

3.1.3.3.1 Requestor specifies synchronous execution (normative)

A requestor MAY specify that an operation must execute synchronously. A requestor that wants the provider to execute an operation synchronously MUST specify "executionMode='synchronous'" in the SPML request.

If a requestor specifies that an operation must be executed synchronously and the provider cannot execute the requested operation synchronously, then the provider MUST fail the operation. If a provider fails an operation because the provider cannot execute the operation synchronously, then the provider’s response MUST specify “status=’failed’” and (the provider’s response MUST also specify) “error=’unsupportedExecutionMode’”.

If a requestor specifies that an operation must be executed synchronously and the provider does not fail the request, then the provider implicitly agrees to execute the requested operation synchronously. The provider MUST acknowledge the request with a response that contains any status and any error or output of the operation. The provider’s response MUST NOT specify “status=’pending’”. The provider’s response MUST specify either “status='success'” or “status=’failed’”.

· If the provider’s response specifies “status=’failed’”, then the provider’s response must have an “error” attribute.

· If the provider’s response specifies “status='success'”, then the provider’s response MUST contain any additional results (i.e., output) of the completed operation.

3.1.3.3.2 Requestor specifies asynchronous execution (normative)

A requestor MAY specify that an operation must execute asynchronously. A requestor that wants the provider to execute an operation asynchronously MUST specify "executionMode='asynchronous'" in the SPML request.

If a requestor specifies that an operation must be executed asynchronously and the provider cannot execute the requested operation asynchronously, then the provider MUST fail the operation. If the provider fails the operation because the provider cannot execute the operation asynchronously, then the provider’s response MUST specify “status=’failed’” and (the provider’s response MUST specify) “error=’unsupportedExecutionMode’”.

If a requestor specifies that an operation must be executed asynchronously and the provider does not fail the request, then the provider implicitly agrees to execute the requested operation asynchronously. The provider MUST acknowledge the request with a synchronous response that indicates that the operation will execute asynchronously. The provider’s response MUST specify “status=’pending’” and (the provider’s response MUST specify) “requestID”.

· If the request specifies a “requestID” value, then the provider’s response MUST specify the same “requestID” value.

· If the request omits “requestID”, then the provider’s response MUST specify a “requestID” value that uniquely identifies the requested operation within the namespace of the provider.

If the provider’s response indicates that the requested operation will execute asynchronously, the requestor may continue with other processing. If the requestor wishes to obtain the status and results of the requested operation (or to cancel the requested operation), the requestor MUST use the “requestID” value that is returned in the provider’s response to identify the operation.

See also the sections titled “Async Capability” and “Results of asynchronous operations (normative)”.

3.1.3.3.3 Provider chooses synchronous execution (normative)

A requestor MAY allow the provider to decide whether to execute a requested operation synchronously or asynchronously. A requestor that wants to let the provider decide the type of execution for an operation MUST omit the “executionMode” attribute of the SPML request.

If a requestor lets the provider decide the type of execution for an operation and the provider chooses to execute the requested operation synchronously, then the provider’s response MUST indicate that the requested operation was executed synchronously. The provider’s response MUST NOT specify “status=’pending’”. The provider’s response MUST specify either “status='success'” or “status=’failed’”.

· If the provider’s response specifies “status=’failed’”, then the provider’s response must have an “error” attribute.

· If the provider’s response specifies “status='success'”, t