Subject: [scim] Concurrent responsibilities

From: Tatsuo Kudo <[email-masked]>
Date: Wed, 16 Jan 2013 19:28:50 +0900

Today I had a discussion with a SaaS vendor on adding SCIM API to their
collaboration services, and we have concluded that we may have to develop
another new schema to represent "concurrent responsibilities" e.g. a person
holding two titles, officer at HQ and president at a subsidiary company as
follows (group may be unique identifier):

...
  "titles": [
    {
      "title": "Officer",
      "group": "HQ"
    },
    {
      "title": "US Employees",
      "group": "Subsidiary A"
    }
  ],
...

Any comments would be appreciated.

Thanks,
Tatsuo.

---

From: Patrick Radtke <[email-masked]>
Date: Wed, 16 Jan 2013 10:19:09 -0800

At Universities, "concurrent responsibilities" can also mean multiple 
offices, phone numbers, email addresses, etc for each role.
The challenge with using existing multivalued attributes for these is 
correlating the phone, email address, office addresses together to know 
which ones belong to a given role.

What is the SaaS vendor using the "concurrent responsibilities" for?
If it is for access control, can 'entitlement' or 'group' suffice?
Is it for information purposes in the UI?

-Patrick

On 1/16/13 2:28 AM, Tatsuo Kudo wrote:
> collaboration services, and we have concluded that we may have to
> develop another new schema to represent "concurrent responsibilities"
> e.g. a person holding two titles, officer at HQ and president at a
> subsidiary company as follows (group may be unique identifier):
>
> ...
>    "titles": [
>      {
>        "title": "Officer",
>        "group": "HQ"
>      },
>      {
>        "title": "US Employees",
>        "group": "Subsidiary A"
>      }
>    ],
> ...
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

---

From: Tatsuo Kudo <[email-masked]>
Date: Wed, 30 Jan 2013 19:35:47 +0900

Hi Patrick,

(2013/01/17 3:19), Patrick Radtke wrote:
> At Universities, "concurrent responsibilities" can also mean multiple offices, phone numbers, email addresses, etc for each role.
> The challenge with using existing multivalued attributes for these is correlating the phone, email address, office addresses together to know which ones belong to a given role.

They are doing access control with the correlated attributes.  An
employee would have full access within one of subsidiaries as a
president, while a bit resricted within its headquarter.

> If it is for access control, can 'entitlement' or 'group' suffice?

It may be applicable if the vendor agrees the following for example.
I will be discussing later.

   "roles": [
     {
       "value": "<role id of President-in-a-Subsidiary>"
     },
     {
       "value": "<role id of Officer-in-a-Headquarter>"
     },
   ],

> Is it for information purposes in the UI?

It would be used for UI as well as access control.

Tatsuo.