Microsoft

danny@zollnerd.com

TODO SCIM Internet-Draft SCIM The System for Cross-domain Identity Management (SCIM) protocol supports creation and management of identity resources such as users between a client and a service provider. In some instances, a SCIM service provider may maintain a list of DNS domains that an organization using that service has registered for their exclusive use with the service. This registration of domains is frequently tied to some form of ownership verification for each domain. This document defines an extension to the SCIM protocol introducing a new 'VerifiedDomains' resource type in order to allow a SCIM client to confirm what domains have had ownership verified by the SCIM service provider, as well as some information about whether the User resource's userName and emails attributes require domain verification in order for a value to possess that domain suffix.

Introduction The System for Cross-domain identity Management (SCIM) protocol RFC7644 supports creation, modification, and deletion of core identity resources. To allow for efficient interactions between SCIM clients and multi-customer SCIM service providers such as SaaS applications, the client may wish to avoid sending creation or update requests that are already known to contain attribute values that will be rejected by the SCIM service provider. A common source of creation and update failures when interacting with SCIM service providers for SaaS applications is when the SCIM client attempts to create or update the userName(adhering to RFC5321 format) or emails attribute on a user and the SCIM client provides a value with a domain suffix that is not verified in the customer's tenant in the service represented by the SCIM service provider. This document defines a simple extension to the SCIM protocol and core schema that adds support for a "VerifiedDomains" resource type that can be queried to retrieve a list of verified domains in the SCIM service provider's environment so that a SCIM client can utilize this information to apply additional logic and avoid sending requests that will fail.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

IANA Considerations This document has no IANA actions.

Definitions Domain: At least a Second Level Domain (SLD) and a Top Level Domain(TLD) registered with public DNS registrars and ICANN. Further expansion to Third Level Domains (aka subdomains) are also permitted.

Verified Domains A SCIM endpoint supporting the Domains extension MUST implement a /VerifiedDomains resource as outlined in this document. This extension is written with only the HTTP/REST GET method required, as the data provided by the SCIM service provider is intended to be read-only. POST, PUT, PATCH and DELETE requests to the /VerifiedDomains resource MUST result in a HTTP Bad Request (400).

ServiceProviderConfig Extension SCIM endpoints that support the Verified Domains extension MUST advertise this support in the ServiceProviderConfig endpoint as defined:

VerifiedDomains Schema Extension Any SCIM service provider that supports the Verified Domains extension MUST implement the VerifiedDomains resource type with the urn:ietf:params:scim:schemas:2.0:VerifiedDomain schema defined in this section: The following singular attributes are defined:

Sample Requests

Retrieving all verified domains

Request

Response

Querying verified domains by domainName value

Request

Response

Schema BNF

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.