RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015

Note: This RFC has been updated by RFC 9865

Errata ID: 8367
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Winter
Date Reported: 2025-04-01
Held for Document Update by: Deb Cooley
Date Held: 2025-12-28

Section 3.4.1 says:

3.4.1.  Retrieving a Known Resource

   To retrieve a known resource, clients send GET requests to the
   resource endpoint, e.g., "/Users/{id}", "/Groups/{id}", or
   "/Schemas/{id}", where "{id}" is a resource identifier (for example,
   the value of the "id" attribute).

It should say:

3.4.1.  Retrieving a Known Resource

   To retrieve a known resource, clients send GET requests to the
   resource endpoint, e.g., "/Users/{id}", "/Groups/{id}", or
   "/Schemas/{id}", where "{id}" is the value of the "id" attribute
   of the resource.

Notes:

The change clearifies that "{id}" is the value of the "id" attribute.

In the original text, the value of the "id" attribute is only mentioned as an example. It remains unclear if the value of the "id" attribute always is a "resource identifier" or if there may be exceptions. It also remains unclear, which other attribute values are considered "resource identifiers", e.g. the values of "externalId", "userName" for User resources, "name" for Resource Type resources, and so on.

RFC6743 specifies for example:
* "id" as "A unique identifier for a SCIM resource" (section 3.1)
* "externalId" as "identifier for the resource" (section 3.1)
* "userName" as "unique identifier for the user" (section 4.1.1)
But as a client I would rather not expect a GET call on "/Users/{userName}" or "/Users/{externalId}" to work. It is also unclear which object would be returned if the "{externalId}" or "{userName}" matches the "{id}" of a different user.

Report New Errata