One document matched: draft-hunt-scim-discovery-00.xml


<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-hunt-scim-discovery-00" ipr="trust200902">
  <front>
    <title abbrev="draft-hunt-scim-discovery">System for Cross-Domain Identity
    Management: Discovery</title>

    <author fullname="Phil Hunt" initials="P." role="editor" surname="Hunt">
      <organization abbrev="Oracle">Oracle Corporation</organization>

      <address>
        <email>phil.hunt@yahoo.com</email>
      </address>
    </author>

    <date year="2016"/>

    <abstract>
      <t>The System for Cross-Domain Identity Management (SCIM) specifications
      are designed to enable identity provisioning in cloud based applications and
      web services easier using HTTP protocol. This specification defines a method
      for discovering a SCIM service provider using the <spanx style="verb">/.well-known</spanx>
      mechanism and optional support
      for WebFinger queries.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="overview" title="Introduction and Overview">
      <t>The System for Cross-Domain Identity Management (SCIM) protocol <xref
      target="RFC7644"/> is designed to enable identity provisioning in web
      applications using the HTTP protocol. This specification defines 
      two methods for discovering a SCIM service provider using the 
      <spanx style="verb">/.well-known</spanx> mechanism defined in
      <xref target="RFC5785"/> and an OPTIONAL WebFinger discovery as defined in 
      <xref target="RFC7033"/> that allows the discovery of a specific SCIM
      service provider discovery based on a subject identifier.</t>
       
      <section anchor="rnc" title="Requirements Notation and Conventions">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"/>.</t>

        <t>Throughout this document all figures may contain spaces and extra
        line-wrapping for readability and space reasons. Similarly, some URI's
        contained within examples, have been shortened for space and
        readability reasons.</t>
      </section>

      <section anchor="defs" title="Definitions" toc="default">
        <t><list style="hanging">
            <t hangText="Service Provider"><vspace/>An HTTP web application
            that provides identity information via the SCIM protocol.</t>

            <t hangText="Client"><vspace/>A website or application that uses
            the SCIM protocol to manage identity data maintained by the
            service provider. The client initiates SCIM HTTP requests to a
            target service provider.</t>

            <t hangText="Endpoint"><vspace/>An endpoint for a service provider
            is a defined base path relative to the service providers Base URI
            (see Sec 1.3 of <xref target="RFC7644"/>) over which
            SCIM operations may be performed against SCIM resources. </t>
          </list></t>
      </section>
    </section>
   
   
    <section title="Discovery Using '/.well-known'">
      <t>In cases where a client would like to ask where the default SCIM
      endpoint is, the <spanx style="verb">/.well-known/scim</spanx>
      discovery method MAY be used. The discovery service MAY use the client's
      security context to determine the correct SCIM endpoint and MAY require
      authentication. For example, a currently authenticated client may be assigned
      a different SCIM endpoint than another subject as they may be members 
      of a different tenancy.</t>
      <t>A SCIM service provider MAY be queried by issuing an HTTP GET request
      at a previously known <spanx style="verb">/.well-known</spanx> 
      discovery end-point <xref target="RFC5785"/> using the URI suffix <spanx style="verb">scim</spanx>. </t>
      
      <figure>
        <preamble>The requesting client would make a request similar to the following 
      (with line wraps for display purposes only):</preamble>
        <artwork align="left">GET /.well-known/scim  HTTP/1.1
HOST: example.com</artwork>
        </figure>
        <figure>
          <preamble>If a SCIM service provider is known, a response is
          returned, encoded in JSON with mime-type application/json</preamble>
          <artwork align="left">HTTP/1.1 200 OK
Content-Type: application/json
          
{
  "issuer":
    "https://example.com",
  "scim_base":
    "https://scim.example.com"
}</artwork>
        </figure>
        <t>The response to a well-known endpoint with the URI suffix 
        <spanx style="verb">scim</spanx> SHALL return a JSON structure consisting
        of the following attributes:<list style="hanging">
          <t hangText="issuer">The issuer of the discovery information. The issuer MUST correspond to the
          URL of the discovery location.</t>
          <t hangText="scim_base">The base URL of a SCIM server as defined 
          in Sec 1.3 of <xref target="RFC7644"/>. From this point, a client
          MAY query the SCIM service's own configuration endpoints as 
          documented in <xref target="RFC7644">Section 4</xref>.</t>
        </list></t>
        <t>When receiving a response, clients MUST confirm that the URI used
        to retrieve the well-known discovery information matches the returned
        <spanx style="verb">issuer</spanx> attribute.</t>
        <t>If the service provider is able to detect a current security subject,
        the value of scim_base MAY change to match the authenticated subject. 
        This may be useful in situations such as multi-tenancy where a 
        specific SCIM service is defined for subjects that part of a specific
        security domain.</t>
    </section>

    <section anchor="webfinger" title="Discovery Using WebFinger">
      <t>A SCIM service provider MAY offer WebFinger <xref target="RFC7033"/> discovery as a means
      of determining the base URL of a SCIM server (as defined 
      in <xref target="RFC7644">Section 1.3</xref>) assigned based
      upon a client's knowledge of a subject or identifier or other 
      unique account key that has been obtained through an out-of-band 
      mechanism.</t>
      <t>When making a WebFinger request, the client SHALL use the following 
      parameters:
      <list style="hanging">
        <t hangText="rel">Containing the value <spanx style="verb">scim</spanx>; and,</t>
        <t hangText="resource">With a value in the form of a URI whose 
          scheme is <spanx style="verb">acct</spanx> 
          as per <xref target="RFC7565"/> and whose suffix corresponds to 
          an attribute of the subject which can either be mapped or searched
          in order to determine the appropriate SCIM base URL that 
          corresponds to the identified account.</t>
      </list>  </t>
      <t>When the query is submitted, the WebFinger JRD response SHALL 
      include an <spanx style="verb">href</spanx>
      value matching the SCIM base URL endpoint for the matched query resource.
      A match indicates where a resource MAY exist, it does not confirm
      that the matched resource exists. The actual account URI SHALL NOT
      be returned (see <xref target="security"/>).</t>
      
      <figure>
      <preamble>The following example uses the "rel" parameter to request 
      links for a SCIM service provider (spaces and line-breaks added for 
      read-ability):</preamble>
      <artwork>
GET /.well-known/webfinger?
resource=acct%3Abob%40example.com&
rel=scim HTTP/1.1
Host: example.com
</artwork>
      </figure>
      <figure>
      <preamble>The following example shows a corresponding response 
      in JRD form (spaces and line-breaks added for read-ability):</preamble>
      <artwork>HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json

{
   "subject" : "acct:bob@example.com",
   "links" :
       [
         {
           "rel" : "scim",
           "href" : "https://scim.example.com/tenant/b939a93/"
         }
       ]
}</artwork>
      
      </figure>
      <t>Upon receiving the response, the client MAY query the discovered
      SCIM service's own configuration endpoints as documented in 
      <xref target="RFC7644">Section 4</xref>. Using the href value 
      provided, the client MAY do a SCIM Query to locate the actual
      URI of the account requested if one exists.</t>
    </section>
 
    <section anchor="security" title="Security Considerations" toc="default">
      <section title="TLS Requirements">
        <t>This specification requires
        the use of transport-layer security when communicating with
        service providers. The service provider MUST support TLS 1.2 
        <xref target="RFC5246"/> and MAY support additional transport-layer
        security mechanisms meetings its security requirements. When using
        TLS, the client MUST perform a TLS/SSL server identity check as per
        <xref target="RFC6125"/>. Implementation security considerations 
        for TLS can be found in <xref target="RFC7525"/>.</t>
      </section>
      <section title="Limited Information Disclosure">
        <t>The intent of WebFinger discovery is to disclose only the correct SCIM
        endpoint for a potential account identifier. WebFinger is not intended
        be used to discover actual account URIs or to confirm their existence.</t> 
        <t>It is the intention of this specification that clients SHALL 
        make a second query to the returned SCIM endpoint to discover 
        the actual account URI if it exists. In the context of SCIM 
        discovery, WebFinger is not intended as a secondary query protocol for SCIM
        due to the sensitive information contained in SCIM service providers
        (see <xref target="privacy"/>).</t>
      </section>
    </section>
    
    <section anchor="privacy" title="Privacy Considerations">
      <t>In cases where the WebFinger discovery method is used, it is important
      to consider that the account query contains personally identifiable
      information. Appropriate measure must be taken to keep this 
      information confidential such as the use of Transport Layer Security.</t> 
      <t>Implementers SHOULD consider the privacy considerations outlined
      in <xref target="RFC7643">Section 9.3</xref> when passing account
      query information.</t>
    </section>

    <section title="IANA Considerations">
      
      <section title="Well-Known Registration">
        <t>This section registers the well-known URI suffix "scim" as per
        Section 5.1 of <xref target="RFC5785"/>.<list style="hanging">
          <t hangText="URI suffix:">The name requested for the well-known
          URI, relative to <spanx style="verb">/.well-known/</spanx> is 
          <spanx style="verb">scim</spanx>.</t>
          <t hangText="Change controller:">IETF.</t>
          <t hangText="Specification document(s):">This document.</t>
        </list>
        </t>
      </section>
      <section title="Scim Link Relation Type">
        <t>This section registers the link relation type <spanx style="verb">scim</spanx>
        as per Section 6.2.1 of <xref target="RFC5988"/>.<list style="hanging">
          <t hangText="Relation Name:">scim</t>
          <t hangText="Description:">Refers to a SCIM endpoint corresponding to a WebFinger query.</t>
          <t hangText="Reference:"><xref target="webfinger"/></t>
        </list></t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      
      <?rfc include="reference.RFC.5246"?>
      
      <?rfc include="reference.RFC.5785"?>

      <?rfc include="reference.RFC.5988"?>

      <?rfc include="reference.RFC.6125"?>     
      
      <?rfc include="reference.RFC.7033"?>
<!-- 
      <?rfc include="reference.RFC.7159"?>     
      --> 
      <?rfc include="reference.RFC.7565"?>
       
      <?rfc include="reference.RFC.7643"?>
      
      <?rfc include="reference.RFC.7644"?>

    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7525"?>
    <!-- 
      <?rfc include="reference.RFC.2141"?>
      
      <?rfc include="reference.RFC.3986"?>
       -->
   
    </references>

    <section title="Acknowledgements">
     
    </section>

    <section title="Change Log">
      <t>[[This section to be removed prior to publication as an RFC]]</t>

      <t>Draft 00 - PH - Initial Draft</t>

     
    </section>
  </back>
</rfc>

PAFTECH AB 2003-20262026-04-24 07:13:47