Subject: [scim] draft-grizzle-scim-pam-ext-01: Section 2.1 - Use URI instead of linkedObject, nativeIdentifier?

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Tue, 23 Jan 2018 21:08:53 +0000

LinkedObject is not useful for a SCIM client or the SCIM service (e.g. PAM software) unless the LinkedObject extension of a user or group contains sufficient information to actually resolve the LinkedObject. 
 
The draft intends to communicate that the "source" attribute identifies the External Store containing the LinkedObject, and "nativeIdentifier" identifies the object within External Store (identified by "source").  

The definition of a "source" attribute as being just a string is ambiguous.  The example in 2.1.1. highlights the ambiguity of "source" by using a "source" value of "Corporate Active Directory".  How, in a the common scenario where PAM users/groups are being enumerated, is a SCIM client going to make sense of a "source" value like "Corporate Active Directory"?  In a scenario where PAM users/groups are being created by the SCIM client, how is the SCIM client going to know how to generate a "source" value like  "Corporate Active Directory" that is meaningful to the PAM software? 
 
Using a URI (instead of a "source" and "nativeIdentifier") seems like a more interoperable and explicit way to reference a LinkedObject.  For example, a URI scheme (RFC 4516) is standardized and well-known to developers for referencing AD/LDAP objects.  Using  a URI has the advantage of allowing LinkedObject reference into a broad range of object stores (not just directories) that can be supported without future modification of the draft.