Subject: [scim] Introduction & question

From: Thorsten Roßner <[email-masked]>
Date: Wed, 25 Sep 2013 15:07:31 +0200

Dear SCIM folks,

even that I already sent a couple of mails in this list and I'm a
regular reader, I would like to quickly introduce myself.

I'm Thorsten :) I'm working with osiam.org where we develop a MIT
licenced implementation of SCIMv2. Unfortuantely I wasn't able to come
to the IETF Meeting in Berlin to meet some of you in person as I just
moved into a new, not yet ready, home the Monday after the
Berlin-Meeting. Currently we hope to have a kitchen in there by x-mas,
so still a lot to do for me beside osiam.org. ;-)

I'll catch up with the latest development of the currently existing
tickets and may come up with some comments in this list in the next
days/weeks.

But first of all I have question:

When I look into most of the complex/multi-value attributes (e.g.
emails, addresses, phoneNumbers) SCIM does not require the values below
to be unique (within the user record).
How should a PATCH based "delete" of a certain email-address work, when
it's possible to have two identical entries?
Would a solution using $refs for each item of a multi-value attribute be
covered by the standard or are there other ways to handle the problem?

Thanks
Thorsten

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 30 Sep 2013 21:00:10 +0000

Hi Thorsten ... you're bumping up against the stickiest part of PATCH (and believe me ... this has incited some debate in the past).

The drafts say this:

API section 3.3.2
   Attributes that do not  have a value Sub-Attribute or that have a
   non-unique value Sub-Attribute are matched by comparing all
   Sub-Attribute values from the PATCH request body to the Sub-Attribute
   values of the Resource.

Schema section 3.2
   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.

According to the draft, you should use the entire complex object to delete an entry.  For example:

PATCH /Users/bjensen
...
{
  "emails": [
    {
      "value": "[email-masked]",
      "type": "work",
      "operation": "delete"
  ]
}

A $ref-like syntax has been discussed, but the consensus was that given every list element a unique identifier was too intrusive on the service provider since an SP is likely not storing an uid already for each element.  Another option would be using a list index, but this would be prone to concurrent modification problems for objects that are modified often (eg - the members list on a Group).

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thorsten Roßner
Sent: Wednesday, September 25, 2013 8:08 AM
To: [email-masked]
Subject: [scim] Introduction & question

Dear SCIM folks,

even that I already sent a couple of mails in this list and I'm a regular reader, I would like to quickly introduce myself.

I'm Thorsten :) I'm working with osiam.org where we develop a MIT licenced implementation of SCIMv2. Unfortuantely I wasn't able to come to the IETF Meeting in Berlin to meet some of you in person as I just moved into a new, not yet ready, home the Monday after the Berlin-Meeting. Currently we hope to have a kitchen in there by x-mas, so still a lot to do for me beside osiam.org. ;-)

I'll catch up with the latest development of the currently existing tickets and may come up with some comments in this list in the next days/weeks.

When I look into most of the complex/multi-value attributes (e.g.
emails, addresses, phoneNumbers) SCIM does not require the values below to be unique (within the user record).
How should a PATCH based "delete" of a certain email-address work, when it's possible to have two identical entries?
Would a solution using $refs for each item of a multi-value attribute be covered by the standard or are there other ways to handle the problem?

Thanks
Thorsten

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim