Subject: [scim] Duplicate Multi-Valued Attributes

From: Shelley <[email-masked]>
Date: Wed, 24 Jul 2013 15:00:04 -0500

The core schema currently indicates the following with respect to
"duplicate" multi-valued attributes:

   Providers MAY return the same value more than
>    once with different types (e.g. the same e-mail address may used for
>    work and home), but *SHOULD NOT return the same (type, value)
>    combination more than once per Attribute*, as this complicates
>    processing by the Consumer.
>
>
I'd propose that in addition, *consumers *MUST NOT send the same (type,
value) combination more than once as well, as this complicates processing
by the Provider and better ensures that valid data is being sent by the
consumer.

In particular, this additional restriction helps avoid any ambiguity if a
consumer were to provide the following:

"emails": [
    { "value":"[email-masked]", "primary": true },
    { "value":"[email-masked]", "primary": false }
]

Restricting all type/value duplicates simplifies the requirement for
consumers and also simplifies processing for providers. This approach would
also be more consistent with the requirement that duplicate "schemas" must
not be provided [2].

[1] http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#section-3.2
[2] http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#section-5.2

---

From: Shelley <[email-masked]>
Date: Thu, 25 Jul 2013 08:51:05 -0500

(Alex, I'm replying to the SCIM mailing list for broader visibility to this
discussion.)

Regarding the duplicate multi-valued attributes, I am not at all suggesting
that any attributes are to be UNIQUE across resources, only that *multi-valued
attributes* must be unique *within a given resource.
*
For example, the following two resources would be perfectly *valid* (notice
multiple resources share a phoneNumber):

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "userName": "[email-masked]",
  "phoneNumbers": [
  *  { "value" : "tel:+1-201-555-0123" }*
  ]
}

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "userName": "[email-masked]",
  "phoneNumbers": [
  *  { "value" : "tel:+1-201-555-0123" }*
  ]
}

But the following should *NOT be valid* (notice that a single resource
duplicates the same value/type combination):

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "userName": "[email-masked]",
  "phoneNumbers": [
*    { "value" : "tel:+1-201-555-0123", "type": "home" },
    { "value" : "tel:+1-201-555-0123", "type": "home", "primary": true },
    { "value" : "tel:+1-201-555-0123", "type": "home", "primary": false }*
  ]
}

Again, this only applies to *multi-valued attributes within a single
resource* - not to singular attributes nor to multi-valued attributes
across resources. And it simply further extends the existing requirement
imposed upon Service Providers to Consumers. A duplicate would be defined
as the value + type sub-attribute combination within a multi-valued
attribute.

Regarding the displayName uniqueness, I think you may be referring to a
completely separate thread:
http://www.ietf.org/mail-archive/web/scim/current/msg01120.html? To
clarify, that proposal is only to make the *GROUP* displayName UNIQUE
(across resources); it wouldn't directly apply to any other use of
"display". I'd suggest continuing that discussion on that thread.

On Thu, Jul 25, 2013 at 2:49 AM, Alex Redston
<[email-masked]>wrote:

>  Shelly,
>
> I would think that whether or not the display name is unique or not, is a
> function of the target system being provisioned rather than the protocol
> (SCIM), people can and do have the same name.
>
> In the example you show in your subsequent email - the attribute in
> question is an email address - obviously a unique identifier but display
> name may not be, in terms of your suggestion "I'd propose that in addition,
> *consumers *MUST NOT send the same (type, value) combination more than
> once as well" what about first names? In my opinion, we have to draw the
> line on uniqueness at identifiers which were always in every situation
> designed to be wholly unique otherwise the protocol will not be in line
> with the requirements of the target systems.
>
> Alex
>
> Alex Redston
>
> Technical Architect, Managing Director
> Switch Research Limited
> +44 1328 838821+44 7973 320795
>
> Alex Redston
>
> Technical Architect, Managing Director
> Switch Research Limited
> Redston Systems Limited
> +44 1328 838821+44 7973 320795
>
> Registered Office:
> 6 LANGDALE COURT
> WITNEY
> OXFORDSHIRE
> UNITED KINGDOM
> OX28 6FG
>
> Company No. 02916682
>
> On 24/07/2013 21:00, Shelley wrote:
>

---

From: Alex Redston <[email-masked]>
Date: Thu, 25 Jul 2013 15:04:16 +0100

Yes - this makes perfect sense.

Sorry for the misunderstanding

Alex

Alex Redston

+44 1328 838821
+44 7973 320795

On 25/07/2013 14:48, Shelley wrote:
> Regarding the duplicate multi-valued attributes, I am not at all 
> suggesting that any attributes are to be UNIQUE across resources, only 
> that /multi-valued attributes/ must be unique /within a given resource.
> /
> For example, the following two resources would be perfectly *valid* 
> (notice multiple resources share a phoneNumber):
>
> {
> "userName": "[email-masked] <mailto:[email-masked]>",
> "phoneNumbers": [
> "userName": "[email-masked] <mailto:[email-masked]>",
> "phoneNumbers": [
> "userName": "[email-masked] <mailto:[email-masked]>",
> "phoneNumbers": [
> Again, this only applies to /multi-valued attributes within a single 
> resource/ - not to singular attributes nor to multi-valued attributes 
> across resources. And it simply further extends the existing 
> requirement imposed upon Service Providers to Consumers. A duplicate 
> would be defined as the value + type sub-attribute combination within 
> a multi-valued attribute.
>
> Regarding the displayName uniqueness, I think you may be referring to 
> a completely separate thread: 
> clarify, that proposal is only to make the /GROUP/ displayName UNIQUE 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Shelly,
>
>     I would think that whether or not the display name is unique or
>     not, is a function of the target system being provisioned rather
>     than the protocol (SCIM), people can and do have the same name.
>
>     In the example you show in your subsequent email - the attribute
>     in question is an email address - obviously a unique identifier
>     but display name may not be, in terms of your suggestion "I'd
>     propose that in addition, /*consumers */MUST NOT send the same
>     (type, value) combination more than once as well" what about first
>     names? In my opinion, we have to draw the line on uniqueness at
>     identifiers which were always in every situation designed to be
>     wholly unique otherwise the protocol will not be in line with the
>     requirements of the target systems.
>
>     Alex
>
>     Alex Redston
>
>     +44 1328 838821  <tel:%2B44%201328%20838821>
>     +44 7973 320795  <tel:%2B44%207973%20320795>
>
>     Alex Redston
>
>     +44 1328 838821  <tel:%2B44%201328%20838821>
>     +44 7973 320795  <tel:%2B44%207973%20320795>
>
>     Registered Office:
>     6 LANGDALE COURT
>     WITNEY
>     OXFORDSHIRE
>     UNITED KINGDOM
>     OX28 6FG
>
>     Company No. 02916682
>
>>             work and home), but*SHOULD NOT return the same (type, value)
>>     I'd propose that in addition, /*consumers */MUST NOT send the
>>     same (type, value) combination more than once as well, as this
>>     complicates processing by the Provider and better ensures that
>>     valid data is being sent by the consumer.
>>
>>     In particular, this additional restriction helps avoid any
>>     ambiguity if a consumer were to provide the following:
>>     "emails": [
>>          { "value":"[email-masked]  <mailto:[email-masked]>", "primary": true },
>>          { "value":"[email-masked]  <mailto:[email-masked]>", "primary": false }
>>     ]
>>     Restricting all type/value duplicates simplifies the requirement
>>     for consumers and also simplifies processing for providers. This
>>     approach would also be more consistent with the requirement that
>>     duplicate "schemas" must not be provided [2].
>>
>>     [1]
>>     http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#section-3.2
>>     [2]
>>     http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#section-5.2
>
>