Re: [scim] Multiple external id values

Phil Hunt <phil.hunt@oracle.com> Mon, 05 October 2015 15:17 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756ED1ACED2 for <scim@ietfa.amsl.com>; Mon, 5 Oct 2015 08:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4nEiF37tcCi for <scim@ietfa.amsl.com>; Mon, 5 Oct 2015 08:17:44 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F76B1ACF57 for <scim@ietf.org>; Mon, 5 Oct 2015 08:17:44 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t95FHhu7010894 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2015 15:17:43 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t95FHgBJ004967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 15:17:42 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t95FHgBa010345; Mon, 5 Oct 2015 15:17:42 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Oct 2015 08:17:42 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail-17F1BB1F-F6C1-47B5-9FF0-C27632675DD8"
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13A452)
In-Reply-To: <56128C3A.6050402@twobotechnologies.com>
Date: Mon, 05 Oct 2015 08:17:41 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <E575C310-B322-4C6F-9E3A-A736D3CBB2CB@oracle.com>
References: <56128C3A.6050402@twobotechnologies.com>
To: Mark Dobrinic <mark.dobrinic@twobotechnologies.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/scim/C0-Jnu8uaeSiSYoRpbfbeNSPOVQ>
Cc: scim@ietf.org
Subject: Re: [scim] Multiple external id values
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 15:17:46 -0000

This was discussed and the consensus was single value. 

What you can do is expose a different single value for each domain client your server talks to.  Thus domains cannot see each other's ids. The spec already suggests this as a security consideration for the id value. 

This would provide much better privacy characteristics and reduces propagation of PII. 

Phil

> On Oct 5, 2015, at 07:42, Mark Dobrinic <mark.dobrinic@twobotechnologies.com> wrote:
> 
> Hi Scim people,
> 
> While incorporating Scim client functionality towards a Scim Service Provider, we've stumbled upon a limitation regarding our desired use of externalId, that doesn't fit the current spec.
> 
> Our usecase involves managing multiple external id's, so that we can both support multiple externalId's to multiple Scim Clients from one Scim Service Provider, as well as let a Scim Client manage multiple external id's with one Scim Service Provider.  Each external id lives within the domain of a, well, domain. There are plenty of real world examples where domain-scoped id's are used, so it seems no more than natural to consider this with Scim as well.
> 
> For example, a user with id barbara has an externalId 'babs' in the domain 'home', and externalId 'labarbara' in domain 'work'.
> 
> As I understand Scim as being as effective and simple as possible, we've been using the extensibility of Scim to make this work. I can imagine this to be a generic problem that more people are (or will be) facing. Therefore, I'd like to propose our solution and would like to discuss whether this could/should be considered a standard solution to a standard problem, either in this form or something better.
> 
> What we did was introduce an extension " urn:scim:schemas:extensions:external-ids:1.0"
> that defines an attribute "externalIds",
> is of type "complex",
> is multiValued,
> can be described as "External Identities of a user. Each External Identity is scoped within its domain",
> is optional,
> and has the following sub-attributes:
> - value : string value containing the value of the external id
> - type : string value containing the domain of the external id
> 
> In JSON, it would look like this:
> 
>                 {
>                 "schemas": [ "urn:scim:schemas:core:1.0", "urn:scim:schemas:extensions:external-ids:1.0" ],
>                 "id":"2819c223-7f76-453a-919d-413861904646",
>                 "userName":"bjensen",
>                 "externalId":"bjensen",
>                 ....
>                 "urn:scim:schemas:extensions:external-ids:1.0": {
>                     "externalIds": [
>                         {
>                             "value": "babs",
>                             "type": "home"
>                         },
>                         {
>                             "value": "labarbara",
>                             "type": "work"
>                         }]
>                     }
>                 }
> 
> 
> 
> Note that we are adding to the baseline features of Scim, and not changing anything existing.
> 
> 
> I would like to hear your feedback on this, and I'm interested whether this could be considered as a standard extension in upcoming Scim versions.
> 
> 
> Thanks!
> 
> -- 
> Regards,
> 
> Mark Dobrinic
> Software Engineer and Identity Specialist
> Twobo Technologies AB
> 
> mark.dobrinic@twobotechnologies.com
> www.twobotechnologies.com
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim