From nobody Mon Sep 1 13:52:22 2014 Return-Path: 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 021A41A0717; Mon, 1 Sep 2014 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 e0prj0m4gT7s; Mon, 1 Sep 2014 13:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E391A06F0; Mon, 1 Sep 2014 13:52:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140901205217.23951.26977.idtracker@ietfa.amsl.com> Date: Mon, 01 Sep 2014 13:52:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Y7YoVOtcC_n0HChtDi4T1mzCsk4 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-10.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:52:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management 0;,Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-10.txt Pages : 77 Date : 2014-09-01 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized services. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model and a service protocol defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 1 13:56:57 2014 Return-Path: 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 D409C1A06F0 for ; Mon, 1 Sep 2014 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 qxzrWHK5BCkI for ; Mon, 1 Sep 2014 13:56:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F89E1A0708 for ; Mon, 1 Sep 2014 13:56:54 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s81KurA9003858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Sep 2014 20:56:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s81Kuq0Y006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Sep 2014 20:56:52 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s81KupvH016209 for ; Mon, 1 Sep 2014 20:56:51 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Sep 2014 13:56:51 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <20140901205217.23951.26977.idtracker@ietfa.amsl.com> Date: Mon, 1 Sep 2014 13:56:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140901205217.23951.26977.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/O6Kpi8Bm-91_He5wn9knHh8lB_U Subject: Re: [scim] I-D Action: draft-ietf-scim-api-10.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:56:56 -0000 FYI, this document as well as Friday=92s submission of core-schema = represent some minor edits and restructuring to improve readability and = consistency. Please see the change-log at the end of each document for more details. Apologies. Some how some garbage got in the title of the API document. = This will be corrected on the next update. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 1, 2014, at 1:52 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management = 0;,Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Technology Nexus > Chuck Mortimore > Filename : draft-ietf-scim-api-10.txt > Pages : 77 > Date : 2014-09-01 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is an HTTP based protocol that makes managing identities in multi- > domain scenarios easier to support through a standardized services. > Examples include but are not limited to enterprise to cloud service > providers, and inter-cloud based scenarios. The specification suite > seeks to build upon experience with existing schemas and = deployments, > placing specific emphasis on simplicity of development and > integration, while applying existing authentication, authorization, > and privacy models. SCIM's intent is to reduce the cost and > complexity of user management operations by providing a common user > schema and extension model and a service protocol defined by this > document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 3 09:25:33 2014 Return-Path: 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 6C42C1A0024 for ; Wed, 3 Sep 2014 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 ESnDPzs06Qgp for ; Wed, 3 Sep 2014 09:25:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3491A000E for ; Wed, 3 Sep 2014 09:25:30 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83GPT9S023438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Sep 2014 16:25:30 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83GPSWH017675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Sep 2014 16:25:29 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83GPSjQ017669 for ; Wed, 3 Sep 2014 16:25:28 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 09:25:28 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_B686BC94-6198-4902-8959-77554168A8AA" Date: Wed, 3 Sep 2014 09:25:26 -0700 To: SCIM WG Message-Id: <5F765DA4-87D8-4AD5-8F4B-BB9C83C7BD07@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/yStNwc2Am7tNyXwx5Jgy4GcSVdY Subject: [scim] Value of schemas when returned X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:25:32 -0000 --Apple-Mail=_B686BC94-6198-4902-8959-77554168A8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have had some question on what the value of schemas should be in = response requests. Should it change according to the attributes = returned or should it always be the same? E.g. if there are no = extension attributes, then should schemas still include any extension = schema values? My feeling is that changing schemas to reflect the attributes that are = present makes schemas behave in a special way compared to other = attributes and would be inconsistent.=20 =93schemas=94 should reflect the state that is on the server and not the = state of the attributes in the json structure being returned. Thus =93schemas=94 should always be the same. Unless I hear some disagreement, I will make the following change... OLD TEXT: 4.2. "schemas" Attribute The "schemas" attribute is a REQUIRED attribute and is an array of Strings containing URIs which are used to indicate the namespace of SCIM schema as well as any schema extensions that together defines the attributes in a resource. Each String value must be a unique URI. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. The schemas attribute for a resource MUST only contain values defined as "schema" and "schemaExtensions" for the resource's "resourceType". Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. NEW TEXT: 4.2. "schemas" Attribute The "schemas" attribute is a REQUIRED attribute and is an array of Strings containing URIs which are used to indicate the namespace of SCIM schema as well as any schema extensions that together defines the attributes in a resource. Each String value must be a unique URI. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. The schemas attribute for a resource MUST only contain values defined as "schema" and "schemaExtensions" for the resource's "resourceType". Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. When displayed as part of a server response, =93schemas=94 SHOULD = reflect the state of the resource on the SCIM Service Provider and SHOULD NOT=20= change to reflect the attributes present in the JSON response. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_B686BC94-6198-4902-8959-77554168A8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = had some question on what the value of schemas should be in response = requests.  Should it change according to the attributes returned or = should it always be the same?  E.g. if there are no extension = attributes, then should schemas still include any extension schema = values?

My feeling is that changing schemas to = reflect the attributes that are present makes schemas behave in a = special way compared to other attributes and would be = inconsistent. 

=93schemas=94 should = reflect the state that is on the server and not the state of the = attributes in the json structure being = returned.

Thus =93schemas=94 should always be = the same.

Unless I hear some disagreement, I = will make the following change...

OLD = TEXT:
4.2.  "schemas" =
Attribute


   The "schemas" attribute is a REQUIRED attribute and is an array of
   Strings containing URIs which are used to indicate the namespace of
   SCIM schema as well as any schema extensions that together defines
   the attributes in a resource.  Each String value must be a unique
   URI.  All representations of SCIM schema MUST include a non-zero
   value array with value(s) of the URIs supported by that
   representation.  The schemas attribute for a resource MUST only
   contain values defined as "schema" and "schemaExtensions" for =
the
   resource's "resourceType".  Duplicate =
values MUST NOT be included.

   Value order is not =
specified and MUST not impact behavior.

NEW = TEXT:
4.2.  "schemas" =
Attribute


   The "schemas" attribute is a REQUIRED attribute and is an array of
   Strings containing URIs which are used to indicate the namespace of
   SCIM schema as well as any schema extensions that together defines
   the attributes in a resource.  Each String value must be a unique
   URI.  All representations of SCIM schema MUST include a non-zero
   value array with value(s) of the URIs supported by that
   representation.  The schemas attribute for a resource MUST only
   contain values defined as "schema" and "schemaExtensions" for =
the
   resource's "resourceType".  Duplicate =
values MUST NOT be included.

   Value order is not =
specified and MUST not impact behavior.

   When displayed as part of a server =
response, =93schemas=94 SHOULD reflect
   the state of the resource on the SCIM =
Service Provider and SHOULD NOT 
   change to reflect the attributes present in the JSON =
response.


= --Apple-Mail=_B686BC94-6198-4902-8959-77554168A8AA-- From nobody Wed Sep 3 11:26:01 2014 Return-Path: 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 9AA9F1A04E9 for ; Wed, 3 Sep 2014 11:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 I7JgydJ1qae8 for ; Wed, 3 Sep 2014 11:25:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7761A04F6 for ; Wed, 3 Sep 2014 11:25:54 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 18:25:51 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.24]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.24]) with mapi id 15.00.1019.015; Wed, 3 Sep 2014 18:25:50 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] Value of schemas when returned Thread-Index: AQHPx5Oz2LaCpnJiDUKS8z9qo5hX35vvuOPg Date: Wed, 3 Sep 2014 18:25:50 +0000 Message-ID: References: <5F765DA4-87D8-4AD5-8F4B-BB9C83C7BD07@oracle.com> In-Reply-To: <5F765DA4-87D8-4AD5-8F4B-BB9C83C7BD07@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0A3F1DC2007FFE0A3F1F0F x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(189002)(377454003)(81342001)(101416001)(107046002)(107886001)(83322001)(106356001)(79102001)(15975445006)(19625215002)(86362001)(21056001)(19609705001)(16236675004)(19580395003)(19580405001)(80022001)(85306004)(108616004)(92566001)(83072002)(2656002)(106116001)(85852003)(90102001)(81542001)(20776003)(66066001)(15202345003)(87936001)(33646002)(95666004)(64706001)(50986999)(105586002)(16601075003)(99286002)(54356999)(76176999)(76576001)(46102001)(99396002)(4396001)(31966008)(74316001)(77982001)(76482001)(19300405004)(77096002)(19617315012)(74662001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d2ab481b942843e4b6a6620f7230ee30BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/38mDjRCQhBjObNB9gyIv8RC3uVk Subject: Re: [scim] Value of schemas when returned X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 18:25:58 -0000 --_000_d2ab481b942843e4b6a6620f7230ee30BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IIRC the schemas attribute was initially introduced as something synonymous= with the xmlns construct in the XML representation. To me, this is just a = matter of data representation ... not actually server state. When the clie= nt POSTs/PUTs data, it must include each of the schemas that is used. When= the server returns results, it must include each of the schemas that is us= ed. Each of these would be limited to only include the schemas that are ac= tually being used in the representation. My two cents... --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, September 03, 2014 11:25 AM To: SCIM WG Subject: [scim] Value of schemas when returned I have had some question on what the value of schemas should be in response= requests. Should it change according to the attributes returned or should= it always be the same? E.g. if there are no extension attributes, then sh= ould schemas still include any extension schema values? My feeling is that changing schemas to reflect the attributes that are pres= ent makes schemas behave in a special way compared to other attributes and = would be inconsistent. "schemas" should reflect the state that is on the server and not the state = of the attributes in the json structure being returned. Thus "schemas" should always be the same. Unless I hear some disagreement, I will make the following change... OLD TEXT: 4.2= . "schemas" Attribute The "schemas" attribute is a REQUIRED attribute and is an array of Strings containing URIs which are used to indicate the namespace of SCIM schema as well as any schema extensions that together defines the attributes in a resource. Each String value must be a unique URI. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. The schemas attribute for a resource MUST only contain values defined as "schema" and "schemaExtensions" for the resource's "resourceType". Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. NEW TEXT: 4.2= . "schemas" Attribute The "schemas" attribute is a REQUIRED attribute and is an array of Strings containing URIs which are used to indicate the namespace of SCIM schema as well as any schema extensions that together defines the attributes in a resource. Each String value must be a unique URI. All representations of SCIM schema MUST include a non-zero value array with value(s) of the URIs supported by that representation. The schemas attribute for a resource MUST only contain values defined as "schema" and "schemaExtensions" for the resource's "resourceType". Duplicate values MUST NOT be included. Value order is not specified and MUST not impact behavior. When displayed as part of a server response, "schemas" SHOULD reflect the state of the resource on the SCIM Service Provider and SHOULD NOT change to reflect the attributes present in the JSON response. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_d2ab481b942843e4b6a6620f7230ee30BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IIRC the schemas attribut= e was initially introduced as something synonymous with the xmlns construct= in the XML representation. To me, this is just a matter of data representation … not actually server state.  When the c= lient POSTs/PUTs data, it must include each of the schemas that is used. &n= bsp;When the server returns results, it must include each of the schemas th= at is used.  Each of these would be limited to only include the schemas that are actually being used in the representation.

 <= /p>

My two cents…<= /o:p>

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, September 03, 2014 11:25 AM
To: SCIM WG
Subject: [scim] Value of schemas when returned

 

I have had some question on what the value of schema= s should be in response requests.  Should it change according to the a= ttributes returned or should it always be the same?  E.g. if there are= no extension attributes, then should schemas still include any extension schema values?

 

My feeling is that changing schemas to reflect the a= ttributes that are present makes schemas behave in a special way compared t= o other attributes and would be inconsistent. 

 

“schemas” should reflect the state that = is on the server and not the state of the attributes in the json structure = being returned.

 

Thus “schemas” should always be the same= .

 

Unless I hear some disagreement, I will make the fol= lowing change...

 

OLD TEXT:

4.2.  "schemas" Attribute

 
 
&n=
bsp;  The "schemas" attribute is a REQUIRED attribute and is=
 an array of
&n=
bsp;  Strings containing URIs which are used to indicate the namespace=
 of
&n=
bsp;  SCIM schema as well as any schema extensions that together defin=
es
&n=
bsp;  the attributes in a resource.  Each String value must be a =
unique
&n=
bsp;  URI.  All representations of SCIM schema MUST include a non=
-zero
&n=
bsp;  value array with value(s) of the URIs supported by that
&n=
bsp;  representation.  The schemas attribute for a resource MUST =
only
&n=
bsp;  contain values defined as "schema" and "schemaExt=
ensions" for the
&n=
bsp;  resource's "resourceType".  Duplicate values MUST=
 NOT be included.
&n=
bsp;  Value order is not specified and MUST not impact behavior.<=
/o:p>

 

NEW TEXT:

4.2.  "schemas" Attribute

 
 
&n=
bsp;  The "schemas" attribute is a REQUIRED attribute and is=
 an array of
&n=
bsp;  Strings containing URIs which are used to indicate the namespace=
 of
&n=
bsp;  SCIM schema as well as any schema extensions that together defin=
es
&n=
bsp;  the attributes in a resource.  Each String value must be a =
unique
&n=
bsp;  URI.  All representations of SCIM schema MUST include a non=
-zero
&n=
bsp;  value array with value(s) of the URIs supported by that
&n=
bsp;  representation.  The schemas attribute for a resource MUST =
only
&n=
bsp;  contain values defined as "schema" and "schemaExt=
ensions" for the
&n=
bsp;  resource's "resourceType".  Duplicate values MUST=
 NOT be included.
&n=
bsp;  Value order is not specified and MUST not impact behavior.<=
/o:p>

 
&n=
bsp;  When displayed as part of a server response, “schemas̶=
1; SHOULD reflect
&n=
bsp;  the state of the resource on the SCIM Service Provider and SHOUL=
D NOT 
&n=
bsp;  change to reflect the attributes present in the JSON response.

 

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_d2ab481b942843e4b6a6620f7230ee30BN1PR04MB392namprd04pro_-- From nobody Wed Sep 3 12:14:52 2014 Return-Path: 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 C2E291A0AFC for ; Wed, 3 Sep 2014 12:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 i4QMQwLZmyym for ; Wed, 3 Sep 2014 12:14:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED441A0704 for ; Wed, 3 Sep 2014 12:14:46 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83JEihi031235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 19:14:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JEi5x023331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 19:14:44 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JEiIL012702; Wed, 3 Sep 2014 19:14:44 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 12:14:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_26AA8598-B294-4D06-B230-68B10F054489" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Wed, 3 Sep 2014 12:14:41 -0700 Message-Id: <647EB64A-EAA7-4371-8807-6E5AB6DB23F2@oracle.com> References: <5F765DA4-87D8-4AD5-8F4B-BB9C83C7BD07@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/5mAzNVGu9dsKC4sb8OM5sU4xtaA Cc: SCIM WG Subject: Re: [scim] Value of schemas when returned X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:14:49 -0000 --Apple-Mail=_26AA8598-B294-4D06-B230-68B10F054489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Kelly, I agree. Keeping schemas as representative of state generates other = complications in the protocol such as is schemas mutable? I will propose new text that suggests it always reflects the current = message content. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 3, 2014, at 11:25 AM, Kelly Grizzle = wrote: > IIRC the schemas attribute was initially introduced as something = synonymous with the xmlns construct in the XML representation. To me, = this is just a matter of data representation =85 not actually server = state. When the client POSTs/PUTs data, it must include each of the = schemas that is used. When the server returns results, it must include = each of the schemas that is used. Each of these would be limited to = only include the schemas that are actually being used in the = representation. > =20 > My two cents=85 > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, September 03, 2014 11:25 AM > To: SCIM WG > Subject: [scim] Value of schemas when returned > =20 > I have had some question on what the value of schemas should be in = response requests. Should it change according to the attributes = returned or should it always be the same? E.g. if there are no = extension attributes, then should schemas still include any extension = schema values? > =20 > My feeling is that changing schemas to reflect the attributes that are = present makes schemas behave in a special way compared to other = attributes and would be inconsistent.=20 > =20 > =93schemas=94 should reflect the state that is on the server and not = the state of the attributes in the json structure being returned. > =20 > Thus =93schemas=94 should always be the same. > =20 > Unless I hear some disagreement, I will make the following change... > =20 > OLD TEXT: > 4.2. "schemas" Attribute >=20 > =20 > =20 > The "schemas" attribute is a REQUIRED attribute and is an array of > Strings containing URIs which are used to indicate the namespace of > SCIM schema as well as any schema extensions that together defines > the attributes in a resource. Each String value must be a unique > URI. All representations of SCIM schema MUST include a non-zero > value array with value(s) of the URIs supported by that > representation. The schemas attribute for a resource MUST only > contain values defined as "schema" and "schemaExtensions" for the > resource's "resourceType". Duplicate values MUST NOT be included. > Value order is not specified and MUST not impact behavior. > =20 > NEW TEXT: > 4.2. "schemas" Attribute >=20 > =20 > =20 > The "schemas" attribute is a REQUIRED attribute and is an array of > Strings containing URIs which are used to indicate the namespace of > SCIM schema as well as any schema extensions that together defines > the attributes in a resource. Each String value must be a unique > URI. All representations of SCIM schema MUST include a non-zero > value array with value(s) of the URIs supported by that > representation. The schemas attribute for a resource MUST only > contain values defined as "schema" and "schemaExtensions" for the > resource's "resourceType". Duplicate values MUST NOT be included. > Value order is not specified and MUST not impact behavior. >=20 > When displayed as part of a server response, =93schemas=94 SHOULD = reflect > the state of the resource on the SCIM Service Provider and SHOULD = NOT=20 > change to reflect the attributes present in the JSON response. > =20 > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_26AA8598-B294-4D06-B230-68B10F054489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks = Kelly,

I agree. Keeping schemas as representative of = state generates other complications in the protocol such as is schemas = mutable?

I will propose new text that suggests = it always reflects the current message content.


On Sep 3, 2014, at 11:25 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

IIRC the schemas attribute was initially = introduced as something synonymous with the xmlns construct in the XML = representation. To me, this is just a matter of data representation =85 not actually server state.  When the = client POSTs/PUTs data, it must include each of the schemas that is = used.  When the server returns results, it must include each of the = schemas that is used.  Each of these would be limited to only include the schemas that are actually being used in the = representation.

 

My two cents=85

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, September 03, 2014 11:25 AM
To: SCIM WG
Subject: [scim] Value of schemas when = returned

 

I= have had some question on what the value of schemas should be in = response requests.  Should it change according to the attributes = returned or should it always be the same?  E.g. if there are no = extension attributes, then should schemas still include any extension schema values?

 

My feeling is that changing schemas to = reflect the attributes that are present makes schemas behave in a = special way compared to other attributes and would be = inconsistent. 

 

=93schemas=94 should reflect the state that = is on the server and not the state of the attributes in the json = structure being returned.

 

Thus =93schemas=94 should always be the = same.

 

Unless I hear some disagreement, I will make = the following change...

 

OLD TEXT:

4.2.  "schemas" Attribute

 
 
   The "schemas" attribute is a =
REQUIRED attribute and is an array of
   Strings containing URIs which =
are used to indicate the namespace of
   SCIM schema as well as any =
schema extensions that together defines
   the attributes in a =
resource.  Each String value must be a =
unique
   URI.  All representations =
of SCIM schema MUST include a non-zero
   value array with value(s) of the =
URIs supported by that
   representation.  The =
schemas attribute for a resource MUST only
   contain values defined as =
"schema" and "schemaExtensions" for the
   resource's "resourceType".  =
Duplicate values MUST NOT be included.
   Value order is not specified and =
MUST not impact behavior.

 

NEW TEXT:

4.2.  "schemas" Attribute

 
 
   The "schemas" attribute is a =
REQUIRED attribute and is an array of
   Strings containing URIs which =
are used to indicate the namespace of
   SCIM schema as well as any =
schema extensions that together defines
   the attributes in a =
resource.  Each String value must be a =
unique
   URI.  All representations =
of SCIM schema MUST include a non-zero
   value array with value(s) of the =
URIs supported by that
   representation.  The =
schemas attribute for a resource MUST only
   contain values defined as =
"schema" and "schemaExtensions" for the
   resource's "resourceType".  =
Duplicate values MUST NOT be included.
   Value order is not specified and =
MUST not impact behavior.

 
   When displayed as part of a =
server response, =93schemas=94 SHOULD reflect
   the state of the resource on the =
SCIM Service Provider and SHOULD NOT 
   change to reflect the attributes =
present in the JSON response.

 

 

 

 

 

_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_26AA8598-B294-4D06-B230-68B10F054489-- From nobody Fri Sep 5 01:20:11 2014 Return-Path: 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 6A3D81A0645 for ; Fri, 5 Sep 2014 01:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.261 X-Spam-Level: * X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=no 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 XOOgeyD__Qbt for ; Fri, 5 Sep 2014 01:20:07 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 90ADF1A063D for ; Fri, 5 Sep 2014 01:20:06 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s858K4EG011068 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Sep 2014 10:20:04 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s858K2BR010409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Sep 2014 10:20:04 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [109.105.104.216] ([109.105.104.216]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128 bits)) for scim@ietf.org; Fri, 5 Sep 2014 10:20:00 +0200 Message-ID: <54097230.5080204@sunet.se> Date: Fri, 05 Sep 2014 10:20:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MLkk4lv - a4dfbbe21c81 - 20140905 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/y_ReE8-gHtqTJUSmzCo9Og-3Hmg Subject: [scim] requested session for Hawaii X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 08:20:07 -0000 I have requested a session matching what we had in Toronto. Please submit your agenda requests! Remember that we hope to be in or past WGLC for the core documents so we should begin to think about our next steps as a WG. Cheers Leif From nobody Fri Sep 5 08:30:52 2014 Return-Path: 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 ADA2D1A06F6 for ; Fri, 5 Sep 2014 08:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 p5sVJjq_bxHY for ; Fri, 5 Sep 2014 08:30:48 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CED21A02FC for ; Fri, 5 Sep 2014 08:30:47 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so11940053wes.21 for ; Fri, 05 Sep 2014 08:30:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=zWEOJzVHYOShdUihtnIBw7+J7yHI3iFB1rg9y3jknq8=; b=bTFPxXwWT7X7wL50ORfdE7G6Y3xs+NEgIq5i7tdUwr8y6YjKyO58S2V8+WzgSxVZpD K6nP03FJiiK5MlSbNX2KxYMD+dPBUkdE0+gTcPww/odChjrTkmzOoByZDMLMvrIE3x1J N6jTjlv8rhb90JPnIzkU7AJRpPI69Vco/o5yLunQ4s9ztnzEQAQRWGyLZL91ksDd/+S+ Z5G7x0EOwHFkp0OSRanuBOQ5EWnobYcEio9jyt3iB3hZomBhAFgjyJW+Zb6+ElyZSkpm Xudt4vaBqTsOrJKbJoR9j+ZGjYcjAXDgrubYUstPdEMhdHP9yRFV+nIcD5jcOu8mAcxx lLpw== X-Gm-Message-State: ALoCoQlEfFJ7gseH1ZJrmJYZY5CNlrq2p4Sc9KqWrXX/C9dLXSV/jPF01aABYzPX/gSH/8afId08 X-Received: by 10.194.110.135 with SMTP id ia7mr15312665wjb.128.1409931041008; Fri, 05 Sep 2014 08:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.27.71 with HTTP; Fri, 5 Sep 2014 08:30:20 -0700 (PDT) From: Ian Glazer Date: Fri, 5 Sep 2014 11:30:20 -0400 Message-ID: To: "scim@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7bf10a84db972a05025326b6 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/pN2NH8oZNLUcq_BxesLyv6Y0Jk0 Subject: [scim] Comments on Bulk X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:30:50 -0000 --047d7bf10a84db972a05025326b6 Content-Type: text/plain; charset=UTF-8 Here's a few comments and questions on the new Bulk section... which I generally like a lot. 1 - bulkId "REQUIRED when method is POST." Curiously, why wouldn't bulkId be required on things like PUT or PATCH? 2 - Is GET permitted? I don't think it makes sense but I just wanted to check. 3 - 3.5.2 - Can I send different bulkId's per operation in a bulk transaction? I believe the answer is yes and I think that is demonstrated in the Circular Reference section. 3.5.2 doesn't make that point clear. 4 - 3.5.2 It isn't obvious in the example that Alice is user "92b725cd-9465-4e7d-8c16-01f8e146b87a" I think we need a sentence before the "A subsequent GET request for the 'Tour Guides' Group..." that explains Alice has been created with the id... 5 - 3.5.4 - How would the client learn of the provider's maximum number of operations and payload size? Are these new configuration attributes? -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --047d7bf10a84db972a05025326b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's a few comments and questions on the new Bu= lk section... which I generally like a lot.

1 - bu= lkId "REQUIRED when method is POST." Curiously, why wouldn't = bulkId be required on things like PUT or PATCH?

2 - Is GET permitted? I don't think it makes sense but I just wanted = to check.

3 - 3.5.2 - Can I send different bulkId&= #39;s per operation in a bulk transaction? I believe the answer is yes and = I think that is demonstrated in the Circular Reference section. 3.5.2 doesn= 't make that point clear.

4 - 3.5.2 It isn'= ;t obvious in the example that Alice is user "92b725cd-9465-4e7d-8c16-= 01f8e146b87a" I think we need a sentence before the "A subsequent= GET request for the 'Tour Guides' Group..." that explains Ali= ce has been created with the id...

5 - 3.5.4 - How= would the client learn of the provider's maximum number of operations = and payload size? Are these new configuration attributes?





-- <= br>
Ian Glazer
Senior Director, Identity=
+1 202 255 3166
--047d7bf10a84db972a05025326b6-- From nobody Fri Sep 5 09:08:48 2014 Return-Path: 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 6A6BD1A071C for ; Fri, 5 Sep 2014 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 lcYfHNIr9KB5 for ; Fri, 5 Sep 2014 09:08:21 -0700 (PDT) Received: from mail-ie0-f200.google.com (mail-ie0-f200.google.com [209.85.223.200]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFFF1A034D for ; Fri, 5 Sep 2014 09:08:21 -0700 (PDT) Received: by mail-ie0-f200.google.com with SMTP id at20so59185301iec.11 for ; Fri, 05 Sep 2014 09:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bOb741JtyP3rVthBSae37R75dFEhy5gJn6L88DinhgY=; b=AGCPd8tosqXb0nJzQcKMnip+g9TUP3gbuzRHN2Onf7DEIKZf1PuZfTSl4f7mfFAvMO TSNB5YlElFEBaZGBtozfkQkbHnlNV2q3YaiuDoUuU8DrlDo4Ydb+KzYqyMAvYOavBfHU 0y6qC+dSjXaduVqdCpgZuNH7QQjlf3grKaSK1WhixdxHHOfv8SFfvab+F2ECU25QIpMw TJgatfY6mU29GiBh2sKhCz1x8UhIioCRAGT/r+kLhlxdj0gu75Dh9RIQ4UvVua2ERFtK 4kW1O6Kt4XiTYgYlVvIKH+r79GvvdAo/dqrWOND0zI9u2EI6YmAXIxpnGU2Yax0xi218 WYXA== X-Gm-Message-State: ALoCoQlNos/IQeEXsNQvcVaI24wm259VHlE+4TfENHL0YCsuL9i04AU8JX4JjJT7oDOZeTJ0KkZA X-Received: by 10.50.57.68 with SMTP id g4mr6213931igq.48.1409933300932; Fri, 05 Sep 2014 09:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.23.233 with HTTP; Fri, 5 Sep 2014 09:08:00 -0700 (PDT) In-Reply-To: <647EB64A-EAA7-4371-8807-6E5AB6DB23F2@oracle.com> References: <5F765DA4-87D8-4AD5-8F4B-BB9C83C7BD07@oracle.com> <647EB64A-EAA7-4371-8807-6E5AB6DB23F2@oracle.com> From: Thomas Krille Date: Fri, 5 Sep 2014 18:08:00 +0200 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7bdc0d9e8f512f050253ad82 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/A3i_QKJ3kmOPKUDeqRzdOo5Me5I Cc: SCIM WG , Kelly Grizzle Subject: Re: [scim] Value of schemas when returned X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:08:27 -0000 --047d7bdc0d9e8f512f050253ad82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for reflection of current message content only Thomas Krille Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-128 Telefax +49 (0) 228 54881-235 t.krille@tarent.de Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale= xander Steeg 2014-09-03 21:14 GMT+02:00 Phil Hunt : > Thanks Kelly, > > I agree. Keeping schemas as representative of state generates other > complications in the protocol such as is schemas mutable? > > I will propose new text that suggests it always reflects the current > message content. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Sep 3, 2014, at 11:25 AM, Kelly Grizzle > wrote: > > IIRC the schemas attribute was initially introduced as something > synonymous with the xmlns construct in the XML representation. To me, thi= s > is just a matter of data representation =E2=80=A6 not actually server sta= te. When > the client POSTs/PUTs data, it must include each of the schemas that is > used. When the server returns results, it must include each of the schem= as > that is used. Each of these would be limited to only include the schemas > that are actually being used in the representation. > > > > My two cents=E2=80=A6 > > > > --Kelly > > > > *From:* scim [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Phil Hunt > *Sent:* Wednesday, September 03, 2014 11:25 AM > *To:* SCIM WG > *Subject:* [scim] Value of schemas when returned > > > > I have had some question on what the value of schemas should be in > response requests. Should it change according to the attributes returned > or should it always be the same? E.g. if there are no extension > attributes, then should schemas still include any extension schema values= ? > > > > My feeling is that changing schemas to reflect the attributes that are > present makes schemas behave in a special way compared to other attribute= s > and would be inconsistent. > > > > =E2=80=9Cschemas=E2=80=9D should reflect the state that is on the server = and not the state > of the attributes in the json structure being returned. > > > > Thus =E2=80=9Cschemas=E2=80=9D should always be the same. > > > > Unless I hear some disagreement, I will make the following change... > > > > OLD TEXT: > 4.2 > . > "schemas" Attribute > > > > > > The "schemas" attribute is a REQUIRED attribute and is an array of > > Strings containing URIs which are used to indicate the namespace of > > SCIM schema as well as any schema extensions that together defines > > the attributes in a resource. Each String value must be a unique > > URI. All representations of SCIM schema MUST include a non-zero > > value array with value(s) of the URIs supported by that > > representation. The schemas attribute for a resource MUST only > > contain values defined as "schema" and "schemaExtensions" for the > > resource's "resourceType". Duplicate values MUST NOT be included. > > Value order is not specified and MUST not impact behavior. > > > > NEW TEXT: > 4.2 > . > "schemas" Attribute > > > > > > The "schemas" attribute is a REQUIRED attribute and is an array of > > Strings containing URIs which are used to indicate the namespace of > > SCIM schema as well as any schema extensions that together defines > > the attributes in a resource. Each String value must be a unique > > URI. All representations of SCIM schema MUST include a non-zero > > value array with value(s) of the URIs supported by that > > representation. The schemas attribute for a resource MUST only > > contain values defined as "schema" and "schemaExtensions" for the > > resource's "resourceType". Duplicate values MUST NOT be included. > > Value order is not specified and MUST not impact behavior. > > > When displayed as part of a server response, =E2=80=9Cschemas=E2=80= =9D SHOULD reflect > > the state of the resource on the SCIM Service Provider and SHOULD NOT > > change to reflect the attributes present in the JSON response. > > > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --047d7bdc0d9e8f512f050253ad82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for reflection of current message content only

Thomas Krille
= Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 1388= 03-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de

Rochusstra=C3=9Fe 2-= 4, D-53123 Bonn =E2=80=A2=C2=A0http://www.tarent.de/
Tel: +4= 9 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 =E2=80= =A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Bart= h, Kai Ebenrett, Boris Esser, Alexander Steeg


2014-09-03 21:14 GMT+02:00 Phil Hunt <phil.hunt@oracle.com>:
Thanks Kelly,

I agree.= Keeping schemas as representative of state generates other complications i= n the protocol such as is schemas mutable?

I will = propose new text that suggests it always reflects the current message conte= nt.


On Sep 3, 2014, at 11:25 AM, Kelly Gri= zzle <k= elly.grizzle@sailpoint.com> wrote:

IIRC the schemas att= ribute was initially introduced as something synonymous with the xmlns cons= truct in the XML representation. To me, this is just a matter of data representation =E2=80=A6 not actually server state.=C2=A0 When the= client POSTs/PUTs data, it must include each of the schemas that is used. = =C2=A0When the server returns results, it must include each of the schemas = that is used.=C2=A0 Each of these would be limited to only include the schemas that are actually being used in the representation.=

=C2= =A0

My two cent= s=E2=80=A6

=C2=A0

=C2=A0

From: scim [mailto:s= cim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, September 03, 2014 11:25 AM
To: SCIM WG
Subject: [scim] Value of schemas when returned<= /p>

=C2=A0

I have had some question on what the value of schemas should be in respons= e requests. =C2=A0Should it change according to the attributes returned or = should it always be the same? =C2=A0E.g. if there are no extension attribut= es, then should schemas still include any extension schema values?

=C2=A0

My feeling is that changing schemas to reflect = the attributes that are present makes schemas behave in a special way compa= red to other attributes and would be inconsistent.=C2=A0

=C2=A0

=E2=80=9Cschemas=E2=80=9D should reflect the st= ate that is on the server and not the state of the attributes in the json s= tructure being returned.

=C2=A0

Thus =E2=80=9Cschemas=E2=80=9D should always be= the same.

=C2=A0

Unless I hear some disagreement, I will make th= e following change...

=C2=A0

OLD TEXT:

4.2= .=C2=A0 "schemas" Attribute

=C2=A0
=C2=A0
=C2=A0=C2=A0 The "schemas" =
attribute is a REQUIRED attribute and is an array of

=C2=A0=C2=A0 Strings containing URIs =
which are used to indicate the namespace of


=C2=A0=C2=A0 SCIM schema as well as a=
ny schema extensions that together defines


=C2=A0=C2=A0 the attributes in a reso=
urce.=C2=A0 Each String value must be a unique


=C2=A0=C2=A0 URI.=C2=A0 All represent=
ations of SCIM schema MUST include a non-zero


=C2=A0=C2=A0 value array with value(s=
) of the URIs supported by that


=C2=A0=C2=A0 representation.=C2=A0 Th=
e schemas attribute for a resource MUST only


=C2=A0=C2=A0 contain values defined a=
s "schema" and "schemaExtensions" for the=



=C2=A0=C2=A0 resource's "res=
ourceType".=C2=A0 Duplicate values MUST NOT be included.=



=C2=A0=C2=A0 Value order is not speci=
fied and MUST not impact behavior.


=C2=A0




NEW TEXT:






=
4.2.=C2=A0
 "schemas" Attribute


=C2=A0


=C2=A0


=C2=A0=C2=A0 The "schemas" =
attribute is a REQUIRED attribute and is an array of

=C2=A0=C2=A0 Strings containing URIs =
which are used to indicate the namespace of


=C2=A0=C2=A0 SCIM schema as well as a=
ny schema extensions that together defines


=C2=A0=C2=A0 the attributes in a reso=
urce.=C2=A0 Each String value must be a unique


=C2=A0=C2=A0 URI.=C2=A0 All represent=
ations of SCIM schema MUST include a non-zero


=C2=A0=C2=A0 value array with value(s=
) of the URIs supported by that


=C2=A0=C2=A0 representation.=C2=A0 Th=
e schemas attribute for a resource MUST only


=C2=A0=C2=A0 contain values defined a=
s "schema" and "schemaExtensions" for the=



=C2=A0=C2=A0 resource's "res=
ourceType".=C2=A0 Duplicate values MUST NOT be included.=



=C2=A0=C2=A0 Value order is not speci=
fied and MUST not impact behavior.





=C2=A0=C2=A0 When displayed as part o=
f a server response, =E2=80=9Cschemas=E2=80=9D SHOULD reflect=



=C2=A0=C2=A0 the state of the resourc=
e on the SCIM Service Provider and SHOULD NOT=C2=A0

=C2=A0=C2=A0 change to reflect the at=
tributes present in the JSON response.




=C2=A0




=C2=A0
























Phil




=C2=A0




@independentid





phil.hunt@orac=
le.com




=C2=A0














=C2=A0


=C2=A0
_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim


_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim


--047d7bdc0d9e8f512f050253ad82-- From nobody Fri Sep 5 10:45:06 2014 Return-Path: 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 938C11A0B80 for ; Fri, 5 Sep 2014 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 V-ojK4Yd0Qf6 for ; Fri, 5 Sep 2014 10:45:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BEB1A0B74 for ; Fri, 5 Sep 2014 10:45:01 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s85HixRc010810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Sep 2014 17:45:00 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s85HixSj009164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 17:44:59 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s85HiwFP029681; Fri, 5 Sep 2014 17:44:58 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Sep 2014 10:44:56 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5FFF598B-B931-4DD3-A3FD-FF26BA16B6A4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Fri, 5 Sep 2014 10:44:48 -0700 Message-Id: <605AADE0-861C-4DAC-8434-764D7F8DBFE7@oracle.com> References: To: Ian Glazer X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/v6agGYmcGraEcjm0m-wBLWgSarE Cc: "scim@ietf.org WG" Subject: Re: [scim] Comments on Bulk X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:45:03 -0000 --Apple-Mail=_5FFF598B-B931-4DD3-A3FD-FF26BA16B6A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, Thanks for the comments. Good to know! See my responses in line=85 Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 5, 2014, at 8:30 AM, Ian Glazer wrote: > Here's a few comments and questions on the new Bulk section... which I = generally like a lot. >=20 > 1 - bulkId "REQUIRED when method is POST." Curiously, why wouldn't = bulkId be required on things like PUT or PATCH? In POST, there is no known identifier before the request. With PUT and = PATCH you have to be modifying a pre-existing object. >=20 > 2 - Is GET permitted? I don't think it makes sense but I just wanted = to check. According to the spec, the only methods permitted are: POST, PUT, = PATCH, or DELETED (see method on page 41) >=20 > 3 - 3.5.2 - Can I send different bulkId's per operation in a bulk = transaction? I believe the answer is yes and I think that is = demonstrated in the Circular Reference section. 3.5.2 doesn't make that = point clear. Agreed. Will add some text. >=20 > 4 - 3.5.2 It isn't obvious in the example that Alice is user = "92b725cd-9465-4e7d-8c16-01f8e146b87a" I think we need a sentence before = the "A subsequent GET request for the 'Tour Guides' Group..." that = explains Alice has been created with the id=85 Ok. Will clarify. >=20 > 5 - 3.5.4 - How would the client learn of the provider's maximum = number of operations and payload size? Are these new configuration = attributes? I will put a reference back to core-schema. But the attributes are: = bulk.supported, bulk.maxOperations and bulk.maxPayloadSize >=20 >=20 >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_5FFF598B-B931-4DD3-A3FD-FF26BA16B6A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ian,

Thanks for the comments. = Good to know!

See my responses in = line=85


On Sep 5, 2014, at 8:30 AM, Ian Glazer <iglazer@salesforce.com> = wrote:

Here's a few comments and questions = on the new Bulk section... which I generally like a = lot.

1 - bulkId "REQUIRED when method is POST." = Curiously, why wouldn't bulkId be required on things like PUT or = PATCH?

In POST, there is no = known identifier before the request. With PUT and PATCH you have to be = modifying a pre-existing object.

2 - Is GET permitted? I don't think it = makes sense but I just wanted to = check.

According to the spec, the = only methods permitted are:  POST, PUT, PATCH, or DELETED (see = method on page 41)

3 - 3.5.2 - Can I send different = bulkId's per operation in a bulk transaction? I believe the answer is = yes and I think that is demonstrated in the Circular Reference section. = 3.5.2 doesn't make that point = clear.

Agreed. Will add some = text.

4 = - 3.5.2 It isn't obvious in the example that Alice is user = "92b725cd-9465-4e7d-8c16-01f8e146b87a" I think we need a sentence before = the "A subsequent GET request for the 'Tour Guides' Group..." that = explains Alice has been created with the = id=85

Ok. Will = clarify.

5 - 3.5.4 - How would the client learn = of the provider's maximum number of operations and payload size? Are = these new configuration = attributes?

I will put a = reference back to core-schema.  But the attributes are: = bulk.supported, bulk.maxOperations and = bulk.maxPayloadSize






--
Ian = Glazer
Senior Director, Identity
+1 202 255 = 3166
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_5FFF598B-B931-4DD3-A3FD-FF26BA16B6A4-- From nobody Fri Sep 5 16:30:49 2014 Return-Path: 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 853EF1A015F for ; Fri, 5 Sep 2014 16:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 gnkI1cLEyeUZ for ; Fri, 5 Sep 2014 16:30:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3303E1A00D4 for ; Fri, 5 Sep 2014 16:30:46 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s85NUi4C003262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Sep 2014 23:30:45 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s85NUia4020659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Sep 2014 23:30:44 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s85NUiOZ013654 for ; Fri, 5 Sep 2014 23:30:44 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Sep 2014 16:30:44 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_8CAC242A-3255-4ADE-A60C-4F541905C523" Message-Id: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> Date: Fri, 5 Sep 2014 16:30:42 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lrmCTvTIfIacTvSnQN_x0ZYnns8 Subject: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 23:30:47 -0000 --Apple-Mail=_8CAC242A-3255-4ADE-A60C-4F541905C523 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looking at the definition for the externalId attribute, I see: { "name" : "externalId", "type" : "string", "multiValued" : false, "description" : "An identifier for the Resource as defined by = the Service Consumer.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Is this correct. Should it not be multi-valued and unique (although = enforcement is assumed to be the client)? I=92m thinking multi-valued because there may be multiple clients = associating with the same resource in the cloud. Each clients wants to = leave a unique identifier in externalId. Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_8CAC242A-3255-4ADE-A60C-4F541905C523 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Looking at the definition for the externalId = attribute, I see:
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : false,
        "description" : "An identifier for the Resource as defined by =
the Service Consumer.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Is this correct. Should it not be multi-valued = and unique (although enforcement is assumed to be the = client)?

I=92m thinking multi-valued because = there may be multiple clients associating with the same resource in the = cloud.  Each clients wants to leave a unique identifier in = externalId.

Any = objections?

= --Apple-Mail=_8CAC242A-3255-4ADE-A60C-4F541905C523-- From nobody Sat Sep 6 01:15:27 2014 Return-Path: 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 A070C1A0032 for ; Sat, 6 Sep 2014 01:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 PMF2fCQrfMar for ; Sat, 6 Sep 2014 01:15:22 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B381A0031 for ; Sat, 6 Sep 2014 01:15:21 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so3947277lam.0 for ; Sat, 06 Sep 2014 01:15:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HiYwpiuzjqVCnrXhprAIiDT3TZcBYquFw8tm1hxuvFY=; b=IEvZRq/x8v+NPKWyaizMYyI3q+O7eV1AUDeWlgPYnd7DoF3gr9zPkIN/K/suj2tHoV dnDX9sUY7IykvOii71QuTB1Xpon1yIDbg/XqYTrc6p0AL3sQDOl1ezrPr7ozZwtYgA4q o0L14FDitSy6MYJsQGC6V6cJwYD+0Ge5jOLkd1ap4BTdhEQZCJT3ZD1B8jSMiQQU84Dx lRSbMNq4tKky0YWvsxZE6v4/7uenmvaeD+tgc+3BhSt7NQx85Y5dM4DFKBoFMH1L4FnK GcaLdpkjI/7A4lLgN0JP9qQGcueV6wqBVf+XFuVWg9sULTGOfcLknhrD8IHTW8rx+SjO c9ng== X-Gm-Message-State: ALoCoQkA7ke7c7bV/NO4Jp6KPeQEg8qH7g/8MO7GmWBM9RfbPDFBaKLiiYXAG5lKZrUCK6RNAg9t X-Received: by 10.152.25.170 with SMTP id d10mr16216401lag.37.1409991319794; Sat, 06 Sep 2014 01:15:19 -0700 (PDT) Received: from [172.20.10.3] (2.64.136.246.mobile.tre.se. [2.64.136.246]) by mx.google.com with ESMTPSA id ai1sm1499218lbd.12.2014.09.06.01.15.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Sep 2014 01:15:19 -0700 (PDT) Message-ID: <540AC296.4090703@mnt.se> Date: Sat, 06 Sep 2014 10:15:18 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: scim@ietf.org References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> In-Reply-To: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/_3yWqqcGjZPf-KyuZXT8k3GhIOA Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 08:15:23 -0000 On 2014-09-06 01:30, Phil Hunt wrote: > Looking at the definition for the externalId attribute, I see: > > { > "name" : "externalId", > "type" : "string", > "multiValued" : false, > "description" : "An identifier for the Resource as defined by the Service Consumer.", > "required" : true, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > Is this correct. Should it not be multi-valued and unique (although > enforcement is assumed to be the client)? > ... no hats ... > I’m thinking multi-valued because there may be multiple clients > associating with the same resource in the cloud. Each clients wants to > leave a unique identifier in externalId. Clearly you are correct. > > Any objections? None. Good catch! From nobody Sun Sep 7 02:58:09 2014 Return-Path: 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 05C4E1A010C for ; Sun, 7 Sep 2014 02:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 W665X5X8HcEu for ; Sun, 7 Sep 2014 02:58:06 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A961A00FB for ; Sun, 7 Sep 2014 02:58:04 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sun, 7 Sep 2014 11:58:22 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Sun, 7 Sep 2014 11:58:04 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] ExternalId - characteristics. Thread-Index: AQHPyWGNPW6mqnfcxEStKJRB5tfEdJv1T/iA Date: Sun, 7 Sep 2014 09:58:03 +0000 Message-ID: <68EDBF00-7606-4806-9C48-8945DA1EE55C@nexusgroup.com> References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> In-Reply-To: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_68EDBF00760648069C488945DA1EE55Cnexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/S0d8WJQv2z6dGDAh0lz_TjnCKS8 Cc: SCIM WG Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 09:58:08 -0000 --_000_68EDBF00760648069C488945DA1EE55Cnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Current core spec states that the externalID is scoped to the client=92s te= nant. So it=92s up to an implementor to handle multiple client=92s external= Id. Feels like a multiValued attribute bleeds information about different c= lients representations. Makes me think of transient/persistant IDs in SAML. =93=85The service provider MUST always interpret the externalId as scoped t= o the client=92s tenant=85" I would like to keep it as single valued attribute. / Erik On 06 Sep 2014, at 01:30, Phil Hunt > wrote: Looking at the definition for the externalId attribute, I see: { "name" : "externalId", "type" : "string", "multiValued" : false, "description" : "An identifier for the Resource as defined by the S= ervice Consumer.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Is this correct. Should it not be multi-valued and unique (although enforce= ment is assumed to be the client)? I=92m thinking multi-valued because there may be multiple clients associati= ng with the same resource in the cloud. Each clients wants to leave a uniq= ue identifier in externalId. Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_68EDBF00760648069C488945DA1EE55Cnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Current core spec states that the externalID is scoped to the client= =92s tenant. So it=92s up to an implementor to handle multiple client=92s e= xternalId. Feels like a multiValued attribute bleeds information about diff= erent clients representations. Makes me think of transient/persistant IDs in SAML.

=93=85The service provider MUST alway=
s interpret the externalId as scoped to the client=92s tenant=85"

I would like to keep it as single valued attribute.

/ Erik


On 06 Sep 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com> wrote:

Looking at the definition for the externalId attribute, I see: 
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : false,
        "description" : "An identifier for the Resource as d=
efined by the Service Consumer.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Is this correct. Should it not be multi-valued and unique (although en= forcement is assumed to be the client)?

I=92m thinking multi-valued because there may be multiple clients asso= ciating with the same resource in the cloud.  Each clients wants to le= ave a unique identifier in externalId.

Any objections?

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_68EDBF00760648069C488945DA1EE55Cnexusgroupcom_-- From nobody Sun Sep 7 18:59:12 2014 Return-Path: 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 6BAB01A0B12 for ; Sun, 7 Sep 2014 18:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 jMgF8CmUB1xv for ; Sun, 7 Sep 2014 18:59:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A631A0AE5 for ; Sun, 7 Sep 2014 18:59:08 -0700 (PDT) Received: from CO1PR04MB393.namprd04.prod.outlook.com (10.141.75.16) by CO1PR04MB396.namprd04.prod.outlook.com (10.141.75.12) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 8 Sep 2014 01:59:05 +0000 Received: from CO1PR04MB393.namprd04.prod.outlook.com ([169.254.6.137]) by CO1PR04MB393.namprd04.prod.outlook.com ([169.254.6.137]) with mapi id 15.00.1024.012; Mon, 8 Sep 2014 01:59:05 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "Phil Hunt" Thread-Topic: [scim] ExternalId - characteristics. Thread-Index: AQHPyWFwR3IZbtmuqE6o88nYWyIbbpv1caqAgAELzjA= Date: Mon, 8 Sep 2014 01:59:04 +0000 Message-ID: References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <68EDBF00-7606-4806-9C48-8945DA1EE55C@nexusgroup.com> In-Reply-To: <68EDBF00-7606-4806-9C48-8945DA1EE55C@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 06AB73CB00806206AB7518 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [70.114.158.171] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019017)(189002)(24454002)(377454003)(199003)(81542001)(85306004)(46102001)(16236675004)(86362001)(79102001)(74316001)(108616004)(76576001)(54356999)(101416001)(76176999)(76482001)(50986999)(77982001)(19609705001)(21056001)(20776003)(4396001)(15975445006)(19300405004)(64706001)(19625215002)(106116001)(105586002)(106356001)(87936001)(15202345003)(95666004)(99396002)(107046002)(85852003)(99286002)(83072002)(81342001)(77096002)(90102001)(19617315012)(66066001)(74502001)(19580395003)(83322001)(80022001)(33646002)(74662001)(2656002)(19580405001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR04MB396; H:CO1PR04MB393.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_fe3378b2f1f8498ea8f0269553f10522CO1PR04MB393namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/GFJRp1ZwZ19MXPhOkW2XUIgZ6sw Cc: SCIM WG Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 01:59:11 -0000 --_000_fe3378b2f1f8498ea8f0269553f10522CO1PR04MB393namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Erik. We have gone back and forth over this a number of times= . The question about a multi-valued attribute is how do we represent the c= lient for each value? Perhaps through the "type" sub-attribute, but - as E= rik mentioned - this could leak data between clients. My vote would be to = keep it single valued and leave it up to the server to handle the correct v= alue for the client that is requesting. --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m Sent: Sunday, September 07, 2014 4:58 AM To: Phil Hunt Cc: SCIM WG Subject: Re: [scim] ExternalId - characteristics. Current core spec states that the externalID is scoped to the client's tena= nt. So it's up to an implementor to handle multiple client's externalId. Fe= els like a multiValued attribute bleeds information about different clients= representations. Makes me think of transient/persistant IDs in SAML. "...The service provider MUST always interpret the externalId as scoped to = the client's tenant..." I would like to keep it as single valued attribute. / Erik On 06 Sep 2014, at 01:30, Phil Hunt > wrote: Looking at the definition for the externalId attribute, I see: { "name" : "externalId", "type" : "string", "multiValued" : false, "description" : "An identifier for the Resource as defined by the S= ervice Consumer.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Is this correct. Should it not be multi-valued and unique (although enforce= ment is assumed to be the client)? I'm thinking multi-valued because there may be multiple clients associating= with the same resource in the cloud. Each clients wants to leave a unique= identifier in externalId. Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_fe3378b2f1f8498ea8f0269553f10522CO1PR04MB393namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with Erik.  = We have gone back and forth over this a number of times.  The question= about a multi-valued attribute is how do we represent the client for each value?  Perhaps through the “type” sub-attribute= , but – as Erik mentioned – this could leak data between client= s.  My vote would be to keep it single valued and leave it up to the s= erver to handle the correct value for the client that is requesting.

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m
Sent: Sunday, September 07, 2014 4:58 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] ExternalId - characteristics.<= /p>

 

Current core spec states that the externalID is scop= ed to the client’s tenant. So it’s up to an implementor to hand= le multiple client’s externalId. Feels like a multiValued attribute b= leeds information about different clients representations. Makes me think of transient/persistant IDs in SAML.

 

&#=
8220;…The service provider MUST always interpret the externalId as sc=
oped to the client’s tenant…"

 

I would like to keep it as single valued attribute.<= o:p>

 

/ Erik

 

 

On 06 Sep 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com> wrote:<= /p>



Looking at the definition for the externalId attribu= te, I see: 

&n=
bsp;     {
&n=
bsp;       "name" : "externalI=
d",
&n=
bsp;       "type" : "string&qu=
ot;,
&n=
bsp;       "multiValued" : false,
&n=
bsp;       "description" : "An=
 identifier for the Resource as defined by the Service Consumer.",
&n=
bsp;       "required" : true,<=
/o:p>
&n=
bsp;       "caseExact" : false,
&n=
bsp;       "mutability" : "rea=
dWrite",
&n=
bsp;       "returned" : "defau=
lt",
&n=
bsp;       "uniqueness" : "non=
e"
&n=
bsp;     },

 

Is this correct. Should it not be multi-valued and u= nique (although enforcement is assumed to be the client)?

 

I’m thinking multi-valued because there may be= multiple clients associating with the same resource in the cloud.  Ea= ch clients wants to leave a unique identifier in externalId.

 

Any objections?

 

 

 

 

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

 

--_000_fe3378b2f1f8498ea8f0269553f10522CO1PR04MB393namprd04pro_-- From nobody Mon Sep 8 00:12:59 2014 Return-Path: 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 303961A6F2E for ; Mon, 8 Sep 2014 00:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 yiH1weGcnTnL for ; Mon, 8 Sep 2014 00:12:55 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE2A1A6F27 for ; Mon, 8 Sep 2014 00:12:54 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so2062880wib.10 for ; Mon, 08 Sep 2014 00:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SAaeA8vWFZYn4XOnvKSo+V1noUUWdHp/hPjl99yO/yc=; b=BwfTD3mvFlhfxCvHUKd95f6hJ0sVo07v6+aIYg3GqonC6tFVyWXLeFKCwihKel4mD6 y8P7HAiBfg+PRGZ63M09+SHC/mLdi/lZ2Y2qh4MNoH8yWfG325Dk24EBGl86wWjazwrZ 8KqZ5Qr3ihHulQrU8iyPj08ThhAUMt4l1hnUn9GVxKuCPwWkPwxvdMOTREi1Hjni6fAI s0JBnJv61AQjYh3/E1OkuO3Dp2P+oxjh/cl2qdw51RpkxR76u2yapm34e9f500ZZHHEW eF5htau4vpq7YgjX1KTrf/4o+XrdNFNgEcoVA81CV2XZi5fO77tSAuIW5lnZxVUdGIZ8 s59Q== X-Gm-Message-State: ALoCoQlnAtd0DeB6d9HqRaru4kpJsyC1zfmiFMu1MCQToNqydgGc9O38a9fxHYoez71dy3tmw1+m X-Received: by 10.180.19.10 with SMTP id a10mr19934101wie.49.1410160373452; Mon, 08 Sep 2014 00:12:53 -0700 (PDT) Received: from [172.24.12.173] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id gl10sm10194711wib.1.2014.09.08.00.12.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 00:12:52 -0700 (PDT) Message-ID: <540D56F3.4020002@tarent.de> Date: Mon, 08 Sep 2014 09:12:51 +0200 From: =?windows-1252?Q?David_M=F6bius?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: scim@ietf.org References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> In-Reply-To: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ytDprnzB_sryZ0ai1BekmGYxbNg Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 07:12:57 -0000 +1 for multivalue and that it can have a name for each client. Doesn anyone has a idear how to solve the problems if one user belongs to several clients but not all values should be seen by all clients? David On 06.09.2014 01:30, Phil Hunt wrote: > Looking at the definition for the externalId attribute, I see: > > { > "name" : "externalId", > "type" : "string", > "multiValued" : false, > "description" : "An identifier for the Resource as defined by the Service Consumer.", > "required" : true, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > Is this correct. Should it not be multi-valued and unique (although > enforcement is assumed to be the client)? > > I’m thinking multi-valued because there may be multiple clients > associating with the same resource in the cloud. Each clients wants to > leave a unique identifier in externalId. > > Any objections? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Mon Sep 8 07:11:49 2014 Return-Path: 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 0268B1A8828 for ; Mon, 8 Sep 2014 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 ga_QHNIdHbSZ for ; Mon, 8 Sep 2014 07:11:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7E41A87EC for ; Mon, 8 Sep 2014 07:11:46 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s88EBiRo007470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Sep 2014 14:11:45 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s88EBgjh022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Sep 2014 14:11:44 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s88EBfvj006261; Mon, 8 Sep 2014 14:11:42 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Sep 2014 07:11:41 -0700 References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> Mime-Version: 1.0 (1.0) In-Reply-To: <540D56F3.4020002@tarent.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 8 Sep 2014 07:11:39 -0700 To: =?utf-8?Q?David_M=C3=B6bius?= X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/yulJS8fw9a301RJMWMLlPJsoLL4 Cc: "scim@ietf.org" Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:11:49 -0000 I think the idea that certain values may need to be restricted to certain cl= ients is an enhancement. It sounds like an access control feature.=20 That said, it sounds like a security considerations issue.=20 Phil > On Sep 8, 2014, at 0:12, David M=C3=B6bius wrote: >=20 > +1 >=20 > for multivalue and that it can have a name for each client. >=20 > Doesn anyone has a idear how to solve the problems if one user belongs to s= everal clients but not all values should be seen by all clients? >=20 > David >=20 >> On 06.09.2014 01:30, Phil Hunt wrote: >> Looking at the definition for the externalId attribute, I see: >>=20 >> { >> "name" : "externalId", >> "type" : "string", >> "multiValued" : false, >> "description" : "An identifier for the Resource as defined by the= Service Consumer.", >> "required" : true, >> "caseExact" : false, >> "mutability" : "readWrite", >> "returned" : "default", >> "uniqueness" : "none" >> }, >>=20 >>=20 >> Is this correct. Should it not be multi-valued and unique (although >> enforcement is assumed to be the client)? >>=20 >> I=E2=80=99m thinking multi-valued because there may be multiple clients >> associating with the same resource in the cloud. Each clients wants to >> leave a unique identifier in externalId. >>=20 >> Any objections? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 8 12:52:54 2014 Return-Path: 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 334CC1A037B for ; Mon, 8 Sep 2014 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 uSftnDCON_Ik for ; Mon, 8 Sep 2014 12:52:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D136A1A0379 for ; Mon, 8 Sep 2014 12:52:46 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s88Jqj73027530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Sep 2014 19:52:46 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s88Jqiv3027937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Sep 2014 19:52:45 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s88Jqhju010170 for ; Mon, 8 Sep 2014 19:52:44 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Sep 2014 12:52:43 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_49869B91-BFFF-437B-9FE5-07BDBFE2C6A3" Message-Id: Date: Mon, 8 Sep 2014 12:52:41 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2sicGi4i6j48MuHIvlYPBJBrM5I Subject: [scim] Common attributes repeated in schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 19:52:50 -0000 --Apple-Mail=_49869B91-BFFF-437B-9FE5-07BDBFE2C6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 First, some background: I am working on a new revision of the = core-schema draft document that will also clean up some terminology = (e.g. confusing use of =91core=92: core-schema, vs core-attributes, vs. = core-resource etc) and better explain how resourceTypes are established = and defined. So far, the changes have been clarifying only, but I ran = into this item which suggests we may want to make some subtle changes. Reviewing the Schema section of the core-schema draft, I see that the = common attributes like id and externalId are repeated in each schema. = For example in the definition for Group, we have=85 { "id" : "urn:ietf:params:scim:schemas:core:2.0:Group", "name" : "Group", "description" : "Group", "attributes" : [ { "name" : "id", "type" : "string", "multiValued" : false, "description" : "Unique identifier for the SCIM resource as = defined by the Service Provider. Each representation of the resource = MUST include a non-empty id value. This identifier MUST be unique across = the Service Provider's entire set of resources. It MUST be a stable, = non-reassignable identifier that does not change when the same resource = is returned in subsequent requests. The value of the id attribute is = always issued by the Service Provider and MUST never be specified by the = Service Consumer. REQUIRED.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "always", "uniqueness" : "server" }, { "name" : "externalId", "type" : "string", "multiValued" : true, "description" : "An identifier for the Resource as defined by = the Service Consumer.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, =85. and so on into the group specific attrs If you look at the other schemas like the one for User, you will see = these same attributes repeated. Because of this, I am worried about the possibility that there may be = conflicting definitions of attribute characteristics between schemas. = E.g. externalId is multi-valued in one, but not another. This could lead = to configuration conflicts between schemas. I=92m wondering if we should create a new schema called =93Common=94 = which is a mandatory schema to any object schema. Its URI does not need = to be included in the schemas attribute, but is always assumed present. urn:ietf:params:scim:schemas:core:2.0:Common As well, while this schema looks like an extension, all of its = attributes belong at the =93top=94 level json structure within the = resource rather than in an extension URI based grouping (e.g. as we do = with enterprise User extension attributes). Maybe since there are only a couple of common attributes I am = overstating the problem and this won=92t be an issue in practice.=20 Is there a better way to express this? =20 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_49869B91-BFFF-437B-9FE5-07BDBFE2C6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
First, some background: I am working on a new revision of the = core-schema draft document that will also clean up some terminology = (e.g. confusing use of =91core=92: core-schema, vs core-attributes, vs. = core-resource etc) and better explain how resourceTypes are established = and defined. So far, the changes have been clarifying only, but I ran = into this item which suggests we may want to make some subtle = changes.

Reviewing the Schema section of the core-schema = draft, I see that the common attributes like id and externalId are = repeated in each schema. For example in the definition for Group, we = have=85
  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "id",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the SCIM resource as =
defined by the Service Provider. Each representation of the resource =
MUST include a non-empty id value. This identifier MUST be unique across =
the Service Provider's entire set of resources. It MUST be a stable, =
non-reassignable identifier that does not change when the same resource =
is returned in subsequent requests. The value of the id attribute is =
always issued by the Service Provider and MUST never be specified by the =
Service Consumer. REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "always",
        "uniqueness" : "server"
      },
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : true,
        "description" : "An identifier for the Resource as defined by =
the Service Consumer.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
=85. and so on into the group specific = attrs

If you look at the other schemas like the = one for User, you will see these same attributes = repeated.

Because of this, I am worried about = the possibility that there may be conflicting definitions of attribute = characteristics between schemas.  E.g. externalId is multi-valued = in one, but not another. This could lead to configuration conflicts = between schemas.

I=92m = wondering if we should create a new schema called =93Common=94 which is = a mandatory schema to any object schema. Its URI does not need to be = included in the schemas attribute, but is always assumed = present.
urn:ietf:params:scim:schemas:core:2.0:Common
As = well, while this schema looks like an extension, all of its attributes = belong at the =93top=94 level json structure within the resource rather = than in an extension URI based grouping (e.g. as we do with enterprise = User extension attributes).

Maybe since = there are only a couple of common attributes I am overstating the = problem and this won=92t be an issue in = practice. 

Is there a better way to = express this? =  

Phil

@independent= id
phil.hunt@oracle.com



= --Apple-Mail=_49869B91-BFFF-437B-9FE5-07BDBFE2C6A3-- From nobody Mon Sep 8 13:15:25 2014 Return-Path: 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 9B8BA1A02F2 for ; Mon, 8 Sep 2014 13:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 dpyf92EAga-g for ; Mon, 8 Sep 2014 13:15:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A610A1A026C for ; Mon, 8 Sep 2014 13:15:19 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s88KFIub021649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Sep 2014 20:15:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s88KFHSu027378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Sep 2014 20:15:18 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s88KFH6V016132 for ; Mon, 8 Sep 2014 20:15:17 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Sep 2014 13:15:17 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_1879A77F-AA0A-44CD-A5F7-B6307C21DBD7" Message-Id: <00C8B171-86B7-4FB2-88F0-541CC87DDC02@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 8 Sep 2014 13:15:15 -0700 References: To: SCIM WG In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LDriQAkzObRWsWhxUgx91J5yzuk Subject: Re: [scim] Common attributes repeated in schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:15:22 -0000 --Apple-Mail=_1879A77F-AA0A-44CD-A5F7-B6307C21DBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 One other issue I noticed. While =93id=94 and =93externalId=94 are = defined as part of User and Group, the =93meta=94 attribute is not = defined. I propose that as part of creating this special =93Common=94 schema, we = include the complex attribute =93meta=94 in that definition. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 8, 2014, at 12:52 PM, Phil Hunt wrote: > First, some background: I am working on a new revision of the = core-schema draft document that will also clean up some terminology = (e.g. confusing use of =91core=92: core-schema, vs core-attributes, vs. = core-resource etc) and better explain how resourceTypes are established = and defined. So far, the changes have been clarifying only, but I ran = into this item which suggests we may want to make some subtle changes. >=20 > Reviewing the Schema section of the core-schema draft, I see that the = common attributes like id and externalId are repeated in each schema. = For example in the definition for Group, we have=85 > { > "id" : "urn:ietf:params:scim:schemas:core:2.0:Group", > "name" : "Group", > "description" : "Group", > "attributes" : [ > { > "name" : "id", > "type" : "string", > "multiValued" : false, > "description" : "Unique identifier for the SCIM resource as = defined by the Service Provider. Each representation of the resource = MUST include a non-empty id value. This identifier MUST be unique across = the Service Provider's entire set of resources. It MUST be a stable, = non-reassignable identifier that does not change when the same resource = is returned in subsequent requests. The value of the id attribute is = always issued by the Service Provider and MUST never be specified by the = Service Consumer. REQUIRED.", > "required" : true, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "always", > "uniqueness" : "server" > }, > { > "name" : "externalId", > "type" : "string", > "multiValued" : true, > "description" : "An identifier for the Resource as defined by = the Service Consumer.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > =85. and so on into the group specific attrs >=20 > If you look at the other schemas like the one for User, you will see = these same attributes repeated. >=20 > Because of this, I am worried about the possibility that there may be = conflicting definitions of attribute characteristics between schemas. = E.g. externalId is multi-valued in one, but not another. This could lead = to configuration conflicts between schemas. >=20 > I=92m wondering if we should create a new schema called =93Common=94 = which is a mandatory schema to any object schema. Its URI does not need = to be included in the schemas attribute, but is always assumed present. > urn:ietf:params:scim:schemas:core:2.0:Common > As well, while this schema looks like an extension, all of its = attributes belong at the =93top=94 level json structure within the = resource rather than in an extension URI based grouping (e.g. as we do = with enterprise User extension attributes). >=20 > Maybe since there are only a couple of common attributes I am = overstating the problem and this won=92t be an issue in practice.=20 >=20 > Is there a better way to express this? =20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_1879A77F-AA0A-44CD-A5F7-B6307C21DBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 One = other issue I noticed.  While =93id=94 and =93externalId=94 are = defined as part of User and Group, the =93meta=94 attribute is not = defined.

I propose that as part of creating this = special =93Common=94 schema, we include the complex attribute =93meta=94 = in that definition.


On Sep 8, 2014, at 12:52 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

First, some background: I am working on a new revision of the = core-schema draft document that will also clean up some terminology = (e.g. confusing use of =91core=92: core-schema, vs core-attributes, vs. = core-resource etc) and better explain how resourceTypes are established = and defined. So far, the changes have been clarifying only, but I ran = into this item which suggests we may want to make some subtle = changes.

Reviewing the Schema section of the core-schema = draft, I see that the common attributes like id and externalId are = repeated in each schema. For example in the definition for Group, we = have=85
  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "id",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the SCIM resource as =
defined by the Service Provider. Each representation of the resource =
MUST include a non-empty id value. This identifier MUST be unique across =
the Service Provider's entire set of resources. It MUST be a stable, =
non-reassignable identifier that does not change when the same resource =
is returned in subsequent requests. The value of the id attribute is =
always issued by the Service Provider and MUST never be specified by the =
Service Consumer. REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "always",
        "uniqueness" : "server"
      },
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : true,
        "description" : "An identifier for the Resource as defined by =
the Service Consumer.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
=85. and so on into the group specific = attrs

If you look at the other schemas like the = one for User, you will see these same attributes = repeated.

Because of this, I am worried about = the possibility that there may be conflicting definitions of attribute = characteristics between schemas.  E.g. externalId is multi-valued = in one, but not another. This could lead to configuration conflicts = between schemas.

I=92m wondering if we should = create a new schema called =93Common=94 which is a mandatory schema to = any object schema. Its URI does not need to be included in the schemas = attribute, but is always assumed present.
urn:ietf:params:scim:schemas:core:2.0:Common
As = well, while this schema looks like an extension, all of its attributes = belong at the =93top=94 level json structure within the resource rather = than in an extension URI based grouping (e.g. as we do with enterprise = User extension attributes).

Maybe since = there are only a couple of common attributes I am overstating the = problem and this won=92t be an issue in = practice. 

Is there a better way to = express this? =  

Phil

@independent= id
phil.hunt@oracle.com


=
_______________________________________________
s= cim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_1879A77F-AA0A-44CD-A5F7-B6307C21DBD7-- From nobody Tue Sep 9 10:31:54 2014 Return-Path: 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 9ED0E1A8725 for ; Tue, 9 Sep 2014 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 lYrBDj2iZYd0 for ; Tue, 9 Sep 2014 10:31:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF441A702D for ; Tue, 9 Sep 2014 10:31:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s89HVjPp012336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Sep 2014 17:31:46 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s89HVjwh024823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2014 17:31:45 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s89HVjI5007733 for ; Tue, 9 Sep 2014 17:31:45 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Sep 2014 10:31:44 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_0F76D35C-781C-4C62-8F46-B440D045A469" Date: Tue, 9 Sep 2014 10:31:42 -0700 To: SCIM WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zyaj1vCE7UZ4U6vea_q-JysvUbA Subject: [scim] Missing "operations": attribute in SCIM PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:31:48 -0000 --Apple-Mail=_0F76D35C-781C-4C62-8F46-B440D045A469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 WG Members: Just to let the group know, there is a JSON bug in the current API = (draft 10) regarding PATCH. When we moved the =93schemas=94 attribute to the top of the message we = forgot to prefix the array of operations with an attribute. The result = is that Draft 10=92s PATCH messages will not validate in JSON. To fix the problem, I propose we add the attribute =93Operations=94 = (which is consistent with Bulk). See example below: PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" {=20 "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op":"replace", "path":"emails[type eq \"work\"].value", "value":"bjenson@example.com" }] } Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_0F76D35C-781C-4C62-8F46-B440D045A469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
WG Members:

Just to let the = group know, there is a JSON bug in the current API (draft 10) regarding = PATCH.

When we moved the =93schemas=94 attribute to = the top of the message we forgot to prefix the array of operations with = an attribute.  The result is that Draft 10=92s PATCH messages will = not validate in JSON.

To fix the problem, I = propose we add the attribute =93Operations=94 (which is consistent with = Bulk). See example below:

PATCH = /Users/2819c223-7f76-453a-919d-413861904646
Accept: application/scim+json
Content-Type: = application/scim+json
Authorization:= Bearer h480djs93hd8
If-Match: = W/"a330bc54f0671c9"

{ 
  = "schemas": = ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{
    "op":"replace",
    "path":"emails[type eq = \"work\"].value",
    = "value":"bjenson@example.com"
<= div>  }]
}

= --Apple-Mail=_0F76D35C-781C-4C62-8F46-B440D045A469-- From nobody Tue Sep 9 10:37:05 2014 Return-Path: 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 5E91D1A700B for ; Tue, 9 Sep 2014 10:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 xeIbU89pTA5I for ; Tue, 9 Sep 2014 10:36:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEDB1A8549 for ; Tue, 9 Sep 2014 10:36:53 -0700 (PDT) Received: from BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) by BN1PR04MB407.namprd04.prod.outlook.com (10.141.60.20) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 9 Sep 2014 17:36:30 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 9 Sep 2014 17:36:29 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.169]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.169]) with mapi id 15.00.1024.012; Tue, 9 Sep 2014 17:36:29 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] Missing "operations": attribute in SCIM PATCH Thread-Index: AQHPzFP21J0WEG0iYUaSEn0RFc8N8Jv5EIEg Date: Tue, 9 Sep 2014 17:36:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0474088F0080C0047409DC x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019018)(199003)(189002)(377454003)(19625215002)(19609705001)(15975445006)(20776003)(74662001)(74502001)(64706001)(79102001)(4396001)(2656002)(76576001)(105586002)(101416001)(106116001)(90102001)(106356001)(107046002)(19617315012)(16601075003)(33646002)(108616004)(46102001)(107886001)(95666004)(99286002)(50986999)(85852003)(76176999)(83072002)(99396002)(16236675004)(76482001)(85306004)(86362001)(87936001)(97736003)(15202345003)(92566001)(74316001)(66066001)(31966008)(81342001)(81542001)(80022001)(77982001)(54356999)(77096002)(19580405001)(21056001)(19580395003)(19300405004)(83322001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e86b367461954c47a326a70459622ec0BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/sz3lXd8rGGn-iZBsPmWBB_9c3f4 Subject: Re: [scim] Missing "operations": attribute in SCIM PATCH X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:36:57 -0000 --_000_e86b367461954c47a326a70459622ec0BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, September 09, 2014 12:32 PM To: SCIM WG Subject: [scim] Missing "operations": attribute in SCIM PATCH WG Members: Just to let the group know, there is a JSON bug in the current API (draft 1= 0) regarding PATCH. When we moved the "schemas" attribute to the top of the message we forgot t= o prefix the array of operations with an attribute. The result is that Dra= ft 10's PATCH messages will not validate in JSON. To fix the problem, I propose we add the attribute "Operations" (which is c= onsistent with Bulk). See example below: PATCH /Users/2819c223-7f76-453a-919d-413861904646 Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 If-Match: W/"a330bc54f0671c9" { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op":"replace", "path":"emails[type eq \"work\"].value", "value":"bjenson@example.com" }] } Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_e86b367461954c47a326a70459622ec0BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, September 09, 2014 12:32 PM
To: SCIM WG
Subject: [scim] Missing "operations": attribute in SCIM PA= TCH

 

WG Members:

 

Just to let the group know, there is a JSON bug in t= he current API (draft 10) regarding PATCH.

 

When we moved the “schemas” attribute to= the top of the message we forgot to prefix the array of operations with an= attribute.  The result is that Draft 10’s PATCH messages will n= ot validate in JSON.

 

To fix the problem, I propose we add the attribute &= #8220;Operations” (which is consistent with Bulk). See example below:=

 

PATCH /Users/2819c223-7f76-453a-919d-413861904646

Accept: application/scim+json

Content-Type: application/scim+json

Authorization: Bearer h480djs93hd8

If-Match: W/"a330bc54f0671c9"

 

{ 

  "schemas": ["urn:ietf:params:scim:api:mes= sages:2.0:PatchOp"],

  "Operations": [{

    "op":"replace",

    "path":"emails[type eq \"work= \"].value",

    "value":"bjenson@example.com"

  }]

}

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

--_000_e86b367461954c47a326a70459622ec0BN1PR04MB392namprd04pro_-- From nobody Wed Sep 10 11:18:10 2014 Return-Path: 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 2362C1A06F9 for ; Wed, 10 Sep 2014 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 cxbVB4Ju8yMt for ; Wed, 10 Sep 2014 11:18:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DB11A00D2 for ; Wed, 10 Sep 2014 11:18:05 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8AII4Nj012740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Sep 2014 18:18:05 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8AII3e0028576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Sep 2014 18:18:04 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8AII2bZ004453 for ; Wed, 10 Sep 2014 18:18:02 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Sep 2014 11:18:01 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Wed, 10 Sep 2014 11:17:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> To: "scim@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/R_pTDn_3TYcao6IALsRIWxVQHtM Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:18:08 -0000 Any feedback on this topic? I=92ve heard very different conflicting = opinions on whether externalId should be multi-valued. Further, in the multi-value option you could say you say that each value = should have a type. I think we need more clarification on how this is to be used. I am concerned that the notion that a single client controls externalId = is fits only an initial deployment. I would expect that over time, mxn = relationships will emerge where many clients connect or reference the = same cloud user. Having a separate externalId assigned by each = different client involves a data type or access control model that SCIM = currently doesn=92t support. For me, I can go either way=85but that=92s mainly because externalId is = a bit mysterious to me. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: > I think the idea that certain values may need to be restricted to = certain clients is an enhancement. It sounds like an access control = feature.=20 >=20 > That said, it sounds like a security considerations issue.=20 >=20 > Phil >=20 >> On Sep 8, 2014, at 0:12, David M=F6bius wrote: >>=20 >> +1 >>=20 >> for multivalue and that it can have a name for each client. >>=20 >> Doesn anyone has a idear how to solve the problems if one user = belongs to several clients but not all values should be seen by all = clients? >>=20 >> David >>=20 >>> On 06.09.2014 01:30, Phil Hunt wrote: >>> Looking at the definition for the externalId attribute, I see: >>>=20 >>> { >>> "name" : "externalId", >>> "type" : "string", >>> "multiValued" : false, >>> "description" : "An identifier for the Resource as defined by = the Service Consumer.", >>> "required" : true, >>> "caseExact" : false, >>> "mutability" : "readWrite", >>> "returned" : "default", >>> "uniqueness" : "none" >>> }, >>>=20 >>>=20 >>> Is this correct. Should it not be multi-valued and unique (although >>> enforcement is assumed to be the client)? >>>=20 >>> I=92m thinking multi-valued because there may be multiple clients >>> associating with the same resource in the cloud. Each clients wants = to >>> leave a unique identifier in externalId. >>>=20 >>> Any objections? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 10 12:08:33 2014 Return-Path: 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 2300B1A0659 for ; Wed, 10 Sep 2014 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 DtnFzwyF3XwG for ; Wed, 10 Sep 2014 12:08:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588FE1A8764 for ; Wed, 10 Sep 2014 12:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3816; q=dns/txt; s=iport; t=1410376080; x=1411585680; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rKqARhktwwmJ2MUjXnxhDsiThYowlGl6Jn6HBXsAmkE=; b=a1w/OcnTn1OjAwMKs/8KU3aBbGob2J5nZD3U1mL+eAV2ExqfdRYbbM6i 4jFwFhXdRbHhYzx10eSg952IFOOc5CDjWRoxZgcD30+RviqBhIYgOCq+2 NbspIVqalbW0eWnM41AZ+0DhK1adsRhi5KsL7VuA27sg+0Fbw0qMMpVU+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFACOhEFStJV2R/2dsb2JhbABWCYMNU1vKNgqHTQGBEhZ4hAQBAQQBAQFGJQQXAgEIGCcHJwsUEQIEARKIQg2/CwEXjnIoOoRMBZFJizOVOYNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,500,1406592000"; d="scan'208";a="76699517" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 10 Sep 2014 19:07:59 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8AJ7xdc002265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 19:07:59 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 14:07:58 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt , "scim@ietf.org" Thread-Topic: [scim] ExternalId - characteristics. Thread-Index: AQHPyWFwAT3uMx3xY0yBdLRpVkk8v5v3KamAgAB1AoCAA2l9gP//mJwA Date: Wed, 10 Sep 2014 19:07:58 +0000 Message-ID: References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> In-Reply-To: <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.85.45] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7AB93D4067A96549B5B227EA07AFA9FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/0z4EAc91oBaOW5YLT984CuqmzOA Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:08:15 -0000 Wearing chair hat: I think we need to let use cases drive this. What are the use cases for defining externalId as a multi-valued attribute or turning it into a complex attribute? Now with implementor hat: in almost all cases I have come across, there is a single authoritative source for the identity and hence a single value for the externalID with no semantics to be enforced by the service provider (etc. uniqueness) is all that is needed. I am sure if we dig we can come up with use cases in the larger context this would need to be more complex, but why couldn=B9t that be handled as an extension? Cheers, Morteza On 9/10/14, 11:17 AM, "Phil Hunt" wrote: >Any feedback on this topic? I=B9ve heard very different conflicting >opinions on whether externalId should be multi-valued. > >Further, in the multi-value option you could say you say that each value >should have a type. > >I think we need more clarification on how this is to be used. > >I am concerned that the notion that a single client controls externalId >is fits only an initial deployment. I would expect that over time, mxn >relationships will emerge where many clients connect or reference the >same cloud user. Having a separate externalId assigned by each different >client involves a data type or access control model that SCIM currently >doesn=B9t support. > >For me, I can go either way=8Abut that=B9s mainly because externalId is a = bit >mysterious to me. > >Phil > >@independentid >www.independentid.com >phil.hunt@oracle.com > > > >On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: > >> I think the idea that certain values may need to be restricted to >>certain clients is an enhancement. It sounds like an access control >>feature.=20 >>=20 >> That said, it sounds like a security considerations issue. >>=20 >> Phil >>=20 >>> On Sep 8, 2014, at 0:12, David M=F6bius wrote: >>>=20 >>> +1 >>>=20 >>> for multivalue and that it can have a name for each client. >>>=20 >>> Doesn anyone has a idear how to solve the problems if one user belongs >>>to several clients but not all values should be seen by all clients? >>>=20 >>> David >>>=20 >>>> On 06.09.2014 01:30, Phil Hunt wrote: >>>> Looking at the definition for the externalId attribute, I see: >>>>=20 >>>> { >>>> "name" : "externalId", >>>> "type" : "string", >>>> "multiValued" : false, >>>> "description" : "An identifier for the Resource as defined by >>>>the Service Consumer.", >>>> "required" : true, >>>> "caseExact" : false, >>>> "mutability" : "readWrite", >>>> "returned" : "default", >>>> "uniqueness" : "none" >>>> }, >>>>=20 >>>>=20 >>>> Is this correct. Should it not be multi-valued and unique (although >>>> enforcement is assumed to be the client)? >>>>=20 >>>> I=B9m thinking multi-valued because there may be multiple clients >>>> associating with the same resource in the cloud. Each clients wants >>>>to >>>> leave a unique identifier in externalId. >>>>=20 >>>> Any objections? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 10 12:25:49 2014 Return-Path: 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 AAD671A8733 for ; Wed, 10 Sep 2014 12:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 ZoWlkvAfQ50G for ; Wed, 10 Sep 2014 12:25:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95F81A014E for ; Wed, 10 Sep 2014 12:25:45 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8AJPilv031474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Sep 2014 19:25:44 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8AJPhee010611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2014 19:25:44 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8AJPhRI010607; Wed, 10 Sep 2014 19:25:43 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Sep 2014 12:25:43 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Wed, 10 Sep 2014 12:25:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> To: Morteza Ansari X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9mPdOX03ecFXluAqNAuwbkpR5lA Cc: "scim@ietf.org" Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:25:47 -0000 Coud to cloud is the use case I was thinking of. But its not clear to me the enterprise side of this is thought out well = yet either =97 at least as far as privacy and security considerations = go. ExternalIds sound a lot like connector Ids. A bit scary, because in = meta-directory days, accounts very quickly tended to have a connecter ID = per relationship. There is a lot of good and bad experiences here. :-) That=92s why I=92d like to have stronger definition of this value, its = purpose, and security considerations. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar) = wrote: > Wearing chair hat: I think we need to let use cases drive this. What = are > the use cases for defining externalId as a multi-valued attribute or > turning it into a complex attribute? >=20 > Now with implementor hat: in almost all cases I have come across, = there is > a single authoritative source for the identity and hence a single = value > for the externalID with no semantics to be enforced by the service > provider (etc. uniqueness) is all that is needed. I am sure if we dig = we > can come up with use cases in the larger context this would need to be > more complex, but why couldn=B9t that be handled as an extension? >=20 >=20 > Cheers, > Morteza >=20 > On 9/10/14, 11:17 AM, "Phil Hunt" wrote: >=20 >> Any feedback on this topic? I=B9ve heard very different conflicting >> opinions on whether externalId should be multi-valued. >>=20 >> Further, in the multi-value option you could say you say that each = value >> should have a type. >>=20 >> I think we need more clarification on how this is to be used. >>=20 >> I am concerned that the notion that a single client controls = externalId >> is fits only an initial deployment. I would expect that over time, = mxn >> relationships will emerge where many clients connect or reference the >> same cloud user. Having a separate externalId assigned by each = different >> client involves a data type or access control model that SCIM = currently >> doesn=B9t support. >>=20 >> For me, I can go either way=8Abut that=B9s mainly because externalId = is a bit >> mysterious to me. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: >>=20 >>> I think the idea that certain values may need to be restricted to >>> certain clients is an enhancement. It sounds like an access control >>> feature.=20 >>>=20 >>> That said, it sounds like a security considerations issue. >>>=20 >>> Phil >>>=20 >>>> On Sep 8, 2014, at 0:12, David M=F6bius = wrote: >>>>=20 >>>> +1 >>>>=20 >>>> for multivalue and that it can have a name for each client. >>>>=20 >>>> Doesn anyone has a idear how to solve the problems if one user = belongs >>>> to several clients but not all values should be seen by all = clients? >>>>=20 >>>> David >>>>=20 >>>>> On 06.09.2014 01:30, Phil Hunt wrote: >>>>> Looking at the definition for the externalId attribute, I see: >>>>>=20 >>>>> { >>>>> "name" : "externalId", >>>>> "type" : "string", >>>>> "multiValued" : false, >>>>> "description" : "An identifier for the Resource as defined = by >>>>> the Service Consumer.", >>>>> "required" : true, >>>>> "caseExact" : false, >>>>> "mutability" : "readWrite", >>>>> "returned" : "default", >>>>> "uniqueness" : "none" >>>>> }, >>>>>=20 >>>>>=20 >>>>> Is this correct. Should it not be multi-valued and unique = (although >>>>> enforcement is assumed to be the client)? >>>>>=20 >>>>> I=B9m thinking multi-valued because there may be multiple clients >>>>> associating with the same resource in the cloud. Each clients = wants >>>>> to >>>>> leave a unique identifier in externalId. >>>>>=20 >>>>> Any objections? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 From nobody Wed Sep 10 12:43:07 2014 Return-Path: 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 6CCCE1A8827 for ; Wed, 10 Sep 2014 12:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 gh5tT7OndYtE for ; Wed, 10 Sep 2014 12:43:04 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id D38B21A014E for ; Wed, 10 Sep 2014 12:43:02 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g12.aset.psu.edu (8.14.3/8.14.3) with ESMTP id s8AJh17Q3543154 for ; Wed, 10 Sep 2014 15:43:01 -0400 Date: Wed, 10 Sep 2014 15:43:00 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <1685031078.1148897.1410378180017.JavaMail.zimbra@psu.edu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.25.8.227] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: scim Digest, Vol 33, Issue 11 Thread-Index: J1yTUmIl8zDh0NElNgwWGtTLdec/7g== X-Virus-Scanned: by amavisd-new Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aEpfhR3V_DtBI5n9SimO0jG44VM Subject: Re: [scim] scim Digest, Vol 33, Issue 11 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:43:06 -0000 We've got a system deployed based on the preliminary SCIM specification wit= h about 2.5M users ... I think we could live with externalId being multi-va= lued as long as it is both typed *and* has a primary flag. Our SCIM users = are mapped to LDAP attributes and externalId becomes uid and is part of a u= ser's DN, so any changes to the externalId field will require code changes = for us (we knew it was a preliminary specification when we started). Thanks to everyone for the extensive discussion ... we're going to have som= ething wonderful in the end! Steve Moyer -- =E2=80=9CThe mark of the immature man is that he wants to die nobly for a c= ause, while the mark of the mature man is that he wants to live humbly for = one.=E2=80=9D - Wilhelm Stekel ----- Original Message ----- From: scim-request@ietf.org To: scim@ietf.org Sent: Wednesday, September 10, 2014 3:01:21 PM Subject: scim Digest, Vol 33, Issue 11 Send scim mailing list submissions to =09scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =09https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to =09scim-request@ietf.org You can reach the person managing the list at =09scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: ExternalId - characteristics. (Phil Hunt) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Sep 2014 11:17:59 -0700 From: Phil Hunt To: "scim@ietf.org" Subject: Re: [scim] ExternalId - characteristics. Message-ID: <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> Content-Type: text/plain; charset=3Dwindows-1252 Any feedback on this topic? I?ve heard very different conflicting opinions = on whether externalId should be multi-valued. Further, in the multi-value option you could say you say that each value sh= ould have a type. I think we need more clarification on how this is to be used. I am concerned that the notion that a single client controls externalId is = fits only an initial deployment. I would expect that over time, mxn relatio= nships will emerge where many clients connect or reference the same cloud u= ser. Having a separate externalId assigned by each different client involv= es a data type or access control model that SCIM currently doesn?t support. For me, I can go either way?but that?s mainly because externalId is a bit m= ysterious to me. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: > I think the idea that certain values may need to be restricted to certain= clients is an enhancement. It sounds like an access control feature.=20 >=20 > That said, it sounds like a security considerations issue.=20 >=20 > Phil >=20 >> On Sep 8, 2014, at 0:12, David M?bius wrote: >>=20 >> +1 >>=20 >> for multivalue and that it can have a name for each client. >>=20 >> Doesn anyone has a idear how to solve the problems if one user belongs t= o several clients but not all values should be seen by all clients? >>=20 >> David >>=20 >>> On 06.09.2014 01:30, Phil Hunt wrote: >>> Looking at the definition for the externalId attribute, I see: >>>=20 >>> { >>> "name" : "externalId", >>> "type" : "string", >>> "multiValued" : false, >>> "description" : "An identifier for the Resource as defined by th= e Service Consumer.", >>> "required" : true, >>> "caseExact" : false, >>> "mutability" : "readWrite", >>> "returned" : "default", >>> "uniqueness" : "none" >>> }, >>>=20 >>>=20 >>> Is this correct. Should it not be multi-valued and unique (although >>> enforcement is assumed to be the client)? >>>=20 >>> I?m thinking multi-valued because there may be multiple clients >>> associating with the same resource in the cloud. Each clients wants to >>> leave a unique identifier in externalId. >>>=20 >>> Any objections? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim ------------------------------ Subject: Digest Footer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------------------------------ End of scim Digest, Vol 33, Issue 11 ************************************ From nobody Wed Sep 10 16:43:57 2014 Return-Path: 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 40AF21A0394 for ; Wed, 10 Sep 2014 16:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 XVD0mFXitjKJ for ; Wed, 10 Sep 2014 16:43:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D591A0320 for ; Wed, 10 Sep 2014 16:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6972; q=dns/txt; s=iport; t=1410392632; x=1411602232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aPNG2ReOsjwPExxdzgNI7cmlUgq6SDHCDr7axbpOJ0U=; b=UAjh76gpNoV90EJXRsLjygE4lQIrpW7qLruvymPC2it0cgO6UKTFEbV9 InQwoVM5qAJgVESUGHoktfC47FPIvC6obwr1H2EkOh3Po1NiEC65mii+6 iJ2LrEdA216KmAHbLZ6oSWzk/QMwo00p3ONE3E8pZaakff6o7MTlvGJ37 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAJXhEFStJA2E/2dsb2JhbABXCYMNU1uCeMdECodNARl3FniEBAEBBAEBASARFSUEBxACAQgYAgIjAwICAiULFAEQAgQOBYhCDaoIlT4BF4EsjUYoGBsHgnmBUwWRSYszlTmDYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="354269749" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 10 Sep 2014 23:43:51 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8ANhpKw012403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 23:43:51 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 18:43:51 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt Thread-Topic: [scim] ExternalId - characteristics. Thread-Index: AQHPyWFwAT3uMx3xY0yBdLRpVkk8v5v3KamAgAB1AoCAA2l9gP//mJwAgAB6TQD//9LIgA== Date: Wed, 10 Sep 2014 23:43:50 +0000 Message-ID: References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> In-Reply-To: <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.85.45] Content-Type: text/plain; charset="utf-8" Content-ID: <51E90099157C124CB344D478DFFD22EB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LOkTkwDhP6UH0kHWfDkaDTy-H0Y Cc: "scim@ietf.org" Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:43:54 -0000 VG90YWxseSBhZ3JlZSBvbiBpbXByb3ZpbmcgdGhlIGxhbmd1YWdlIHRvIGdldCB0byBhIG1vcmUg Y2xlYXIgZGVmaW5pdGlvbi4NCg0KQ2FuIHlvdSBleHBhbmQgdGhlIGNsb3VkIHRvIGNsb3VkIHVz ZSBjYXNlPyAgSSBhY3R1YWxseSBkb27igJl0IHNlZSB3aHkgdGhhdA0Kd291bGQgcmVxdWlyZSBt dWx0aS12YWx1ZWQgYXR0cmlidXRlIGZvciB0aGF0Lg0KDQoNCkNoZWVycywNCk1vcnRlemENCg0K T24gOS8xMC8xNCwgMTI6MjUgUE0sICJQaGlsIEh1bnQiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4g d3JvdGU6DQoNCj5Db3VkIHRvIGNsb3VkIGlzIHRoZSB1c2UgY2FzZSBJIHdhcyB0aGlua2luZyBv Zi4NCj4NCj5CdXQgaXRzIG5vdCBjbGVhciB0byBtZSB0aGUgZW50ZXJwcmlzZSBzaWRlIG9mIHRo aXMgaXMgdGhvdWdodCBvdXQgd2VsbA0KPnlldCBlaXRoZXIg4oCUIGF0IGxlYXN0IGFzIGZhciBh cyBwcml2YWN5IGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBnby4NCj4NCj5FeHRlcm5hbElk cyBzb3VuZCBhIGxvdCBsaWtlIGNvbm5lY3RvciBJZHMuIEEgYml0IHNjYXJ5LCBiZWNhdXNlIGlu DQo+bWV0YS1kaXJlY3RvcnkgZGF5cywgYWNjb3VudHMgdmVyeSBxdWlja2x5IHRlbmRlZCB0byBo YXZlIGEgY29ubmVjdGVyIElEDQo+cGVyIHJlbGF0aW9uc2hpcC4NCj4NCj5UaGVyZSBpcyBhIGxv dCBvZiBnb29kIGFuZCBiYWQgZXhwZXJpZW5jZXMgaGVyZS4gIDotKQ0KPg0KPlRoYXTigJlzIHdo eSBJ4oCZZCBsaWtlIHRvIGhhdmUgc3Ryb25nZXIgZGVmaW5pdGlvbiBvZiB0aGlzIHZhbHVlLCBp dHMNCj5wdXJwb3NlLCBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQo+DQo+UGhpbA0KPg0K PkBpbmRlcGVuZGVudGlkDQo+d3d3LmluZGVwZW5kZW50aWQuY29tDQo+cGhpbC5odW50QG9yYWNs ZS5jb20NCj4NCj4NCj4NCj5PbiBTZXAgMTAsIDIwMTQsIGF0IDEyOjA3IFBNLCBNb3J0ZXphIEFu c2FyaSAobW9yYW5zYXIpDQo+PG1vcmFuc2FyQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PiBXZWFy aW5nIGNoYWlyIGhhdDogSSB0aGluayB3ZSBuZWVkIHRvIGxldCB1c2UgY2FzZXMgZHJpdmUgdGhp cy4gIFdoYXQNCj4+YXJlDQo+PiB0aGUgdXNlIGNhc2VzIGZvciBkZWZpbmluZyBleHRlcm5hbElk IGFzIGEgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZSBvcg0KPj4gdHVybmluZyBpdCBpbnRvIGEgY29t cGxleCBhdHRyaWJ1dGU/DQo+PiANCj4+IE5vdyB3aXRoIGltcGxlbWVudG9yIGhhdDogaW4gYWxt b3N0IGFsbCBjYXNlcyBJIGhhdmUgY29tZSBhY3Jvc3MsIHRoZXJlDQo+PmlzDQo+PiBhIHNpbmds ZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBmb3IgdGhlIGlkZW50aXR5IGFuZCBoZW5jZSBhIHNpbmds ZSB2YWx1ZQ0KPj4gZm9yIHRoZSBleHRlcm5hbElEIHdpdGggbm8gc2VtYW50aWNzIHRvIGJlIGVu Zm9yY2VkIGJ5IHRoZSBzZXJ2aWNlDQo+PiBwcm92aWRlciAoZXRjLiB1bmlxdWVuZXNzKSBpcyBh bGwgdGhhdCBpcyBuZWVkZWQuICBJIGFtIHN1cmUgaWYgd2UgZGlnDQo+PndlDQo+PiBjYW4gY29t ZSB1cCB3aXRoIHVzZSBjYXNlcyBpbiB0aGUgbGFyZ2VyIGNvbnRleHQgdGhpcyB3b3VsZCBuZWVk IHRvIGJlDQo+PiBtb3JlIGNvbXBsZXgsIGJ1dCB3aHkgY291bGRuwrl0IHRoYXQgYmUgaGFuZGxl ZCBhcyBhbiBleHRlbnNpb24/DQo+PiANCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTW9ydGV6YQ0KPj4g DQo+PiBPbiA5LzEwLzE0LCAxMToxNyBBTSwgIlBoaWwgSHVudCIgPHBoaWwuaHVudEBvcmFjbGUu Y29tPiB3cm90ZToNCj4+IA0KPj4+IEFueSBmZWVkYmFjayBvbiB0aGlzIHRvcGljPyBJwrl2ZSBo ZWFyZCB2ZXJ5IGRpZmZlcmVudCBjb25mbGljdGluZw0KPj4+IG9waW5pb25zIG9uIHdoZXRoZXIg ZXh0ZXJuYWxJZCBzaG91bGQgYmUgbXVsdGktdmFsdWVkLg0KPj4+IA0KPj4+IEZ1cnRoZXIsIGlu IHRoZSBtdWx0aS12YWx1ZSBvcHRpb24geW91IGNvdWxkIHNheSB5b3Ugc2F5IHRoYXQgZWFjaA0K Pj4+dmFsdWUNCj4+PiBzaG91bGQgaGF2ZSBhIHR5cGUuDQo+Pj4gDQo+Pj4gSSB0aGluayB3ZSBu ZWVkIG1vcmUgY2xhcmlmaWNhdGlvbiBvbiBob3cgdGhpcyBpcyB0byBiZSB1c2VkLg0KPj4+IA0K Pj4+IEkgYW0gY29uY2VybmVkIHRoYXQgdGhlIG5vdGlvbiB0aGF0IGEgc2luZ2xlIGNsaWVudCBj b250cm9scyBleHRlcm5hbElkDQo+Pj4gaXMgZml0cyBvbmx5IGFuIGluaXRpYWwgZGVwbG95bWVu dC4gSSB3b3VsZCBleHBlY3QgdGhhdCBvdmVyIHRpbWUsIG14bg0KPj4+IHJlbGF0aW9uc2hpcHMg d2lsbCBlbWVyZ2Ugd2hlcmUgbWFueSBjbGllbnRzIGNvbm5lY3Qgb3IgcmVmZXJlbmNlIHRoZQ0K Pj4+IHNhbWUgY2xvdWQgdXNlci4gIEhhdmluZyBhIHNlcGFyYXRlIGV4dGVybmFsSWQgYXNzaWdu ZWQgYnkgZWFjaA0KPj4+ZGlmZmVyZW50DQo+Pj4gY2xpZW50IGludm9sdmVzIGEgZGF0YSB0eXBl IG9yIGFjY2VzcyBjb250cm9sIG1vZGVsIHRoYXQgU0NJTSBjdXJyZW50bHkNCj4+PiBkb2VzbsK5 dCBzdXBwb3J0Lg0KPj4+IA0KPj4+IEZvciBtZSwgSSBjYW4gZ28gZWl0aGVyIHdhecWgYnV0IHRo YXTCuXMgbWFpbmx5IGJlY2F1c2UgZXh0ZXJuYWxJZCBpcyBhDQo+Pj5iaXQNCj4+PiBteXN0ZXJp b3VzIHRvIG1lLg0KPj4+IA0KPj4+IFBoaWwNCj4+PiANCj4+PiBAaW5kZXBlbmRlbnRpZA0KPj4+ IHd3dy5pbmRlcGVuZGVudGlkLmNvbQ0KPj4+IHBoaWwuaHVudEBvcmFjbGUuY29tDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gT24gU2VwIDgsIDIwMTQsIGF0IDc6MTEgQU0sIFBoaWwgSHVudCA8cGhp bC5odW50QG9yYWNsZS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiBJIHRoaW5rIHRoZSBpZGVhIHRo YXQgY2VydGFpbiB2YWx1ZXMgbWF5IG5lZWQgdG8gYmUgcmVzdHJpY3RlZCB0bw0KPj4+PiBjZXJ0 YWluIGNsaWVudHMgaXMgYW4gZW5oYW5jZW1lbnQuIEl0IHNvdW5kcyBsaWtlIGFuIGFjY2VzcyBj b250cm9sDQo+Pj4+IGZlYXR1cmUuIA0KPj4+PiANCj4+Pj4gVGhhdCBzYWlkLCBpdCBzb3VuZHMg bGlrZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzc3VlLg0KPj4+PiANCj4+Pj4gUGhpbA0K Pj4+PiANCj4+Pj4+IE9uIFNlcCA4LCAyMDE0LCBhdCAwOjEyLCBEYXZpZCBNw7ZiaXVzIDxkLm1v ZWJpdXNAdGFyZW50LmRlPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gKzENCj4+Pj4+IA0KPj4+Pj4g Zm9yIG11bHRpdmFsdWUgYW5kIHRoYXQgaXQgY2FuIGhhdmUgYSBuYW1lIGZvciBlYWNoIGNsaWVu dC4NCj4+Pj4+IA0KPj4+Pj4gRG9lc24gYW55b25lIGhhcyBhIGlkZWFyIGhvdyB0byBzb2x2ZSB0 aGUgcHJvYmxlbXMgaWYgb25lIHVzZXINCj4+Pj4+YmVsb25ncw0KPj4+Pj4gdG8gc2V2ZXJhbCBj bGllbnRzIGJ1dCBub3QgYWxsIHZhbHVlcyBzaG91bGQgYmUgc2VlbiBieSBhbGwgY2xpZW50cz8N Cj4+Pj4+IA0KPj4+Pj4gRGF2aWQNCj4+Pj4+IA0KPj4+Pj4+IE9uIDA2LjA5LjIwMTQgMDE6MzAs IFBoaWwgSHVudCB3cm90ZToNCj4+Pj4+PiBMb29raW5nIGF0IHRoZSBkZWZpbml0aW9uIGZvciB0 aGUgZXh0ZXJuYWxJZCBhdHRyaWJ1dGUsIEkgc2VlOg0KPj4+Pj4+IA0KPj4+Pj4+ICAgICB7DQo+ Pj4+Pj4gICAgICAgIm5hbWUiIDogImV4dGVybmFsSWQiLA0KPj4+Pj4+ICAgICAgICJ0eXBlIiA6 ICJzdHJpbmciLA0KPj4+Pj4+ICAgICAgICJtdWx0aVZhbHVlZCIgOiBmYWxzZSwNCj4+Pj4+PiAg ICAgICAiZGVzY3JpcHRpb24iIDogIkFuIGlkZW50aWZpZXIgZm9yIHRoZSBSZXNvdXJjZSBhcyBk ZWZpbmVkIGJ5DQo+Pj4+Pj4gdGhlIFNlcnZpY2UgQ29uc3VtZXIuIiwNCj4+Pj4+PiAgICAgICAi cmVxdWlyZWQiIDogdHJ1ZSwNCj4+Pj4+PiAgICAgICAiY2FzZUV4YWN0IiA6IGZhbHNlLA0KPj4+ Pj4+ICAgICAgICJtdXRhYmlsaXR5IiA6ICJyZWFkV3JpdGUiLA0KPj4+Pj4+ICAgICAgICJyZXR1 cm5lZCIgOiAiZGVmYXVsdCIsDQo+Pj4+Pj4gICAgICAgInVuaXF1ZW5lc3MiIDogIm5vbmUiDQo+ Pj4+Pj4gICAgIH0sDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gSXMgdGhpcyBjb3JyZWN0LiBT aG91bGQgaXQgbm90IGJlIG11bHRpLXZhbHVlZCBhbmQgdW5pcXVlIChhbHRob3VnaA0KPj4+Pj4+ IGVuZm9yY2VtZW50IGlzIGFzc3VtZWQgdG8gYmUgdGhlIGNsaWVudCk/DQo+Pj4+Pj4gDQo+Pj4+ Pj4gScK5bSB0aGlua2luZyBtdWx0aS12YWx1ZWQgYmVjYXVzZSB0aGVyZSBtYXkgYmUgbXVsdGlw bGUgY2xpZW50cw0KPj4+Pj4+IGFzc29jaWF0aW5nIHdpdGggdGhlIHNhbWUgcmVzb3VyY2UgaW4g dGhlIGNsb3VkLiAgRWFjaCBjbGllbnRzIHdhbnRzDQo+Pj4+Pj4gdG8NCj4+Pj4+PiBsZWF2ZSBh IHVuaXF1ZSBpZGVudGlmaWVyIGluIGV4dGVybmFsSWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQW55IG9i amVjdGlvbnM/DQo+Pj4+Pj4gDQo+Pj4+Pj4gUGhpbA0KPj4+Pj4+IA0KPj4+Pj4+IEBpbmRlcGVu ZGVudGlkDQo+Pj4+Pj4gd3d3LmluZGVwZW5kZW50aWQuY29tIDxodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tPg0KPj4+Pj4+IHBoaWwuaHVudEBvcmFjbGUuY29tIDxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+PiBzY2ltIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNjaW1AaWV0Zi5vcmcNCj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCj4+Pj4+IA0KPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNj aW0gbWFpbGluZyBsaXN0DQo+Pj4+PiBzY2ltQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNjaW0gbWFpbGluZyBsaXN0DQo+ Pj4gc2NpbUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2NpbQ0KPj4gDQo+DQoNCg== From nobody Wed Sep 10 16:45:56 2014 Return-Path: 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 C93701A03CF for ; Wed, 10 Sep 2014 16:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Zz-1eBzK8u5I for ; Wed, 10 Sep 2014 16:45:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3241A0320 for ; Wed, 10 Sep 2014 16:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1345; q=dns/txt; s=iport; t=1410392753; x=1411602353; h=from:to:subject:date:message-id:mime-version; bh=CMgA5SuV47fCHRQOIznavbClu3K5bIR7P2DBojyOhhM=; b=Yd8nHz8eZ1J1kKAJkRDXLJIR5By93uJLQ/qROJpqsrSVI+flG01kDc2Y kfFskqYECIkCLbXxtwlt+n9onoltv2dfS1JIhFZmQ8z8in8NuHF5T2RQ9 1GG/4byD8hAI+RK27HjFg1qTJV6Hf2QSe+dlv4c98BB/rbA3GZSuDgVHs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABLiEFStJA2E/2dsb2JhbABggkdGgS7TJRZ4g3oQgQsBCwF0JwSIVZphpHIBF5QgBZFJizOVOYNhgjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208,217";a="354220099" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 10 Sep 2014 23:45:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8ANjpLk013716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Sep 2014 23:45:51 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 18:45:50 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Ung== Date: Wed, 10 Sep 2014 23:45:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.85.45] Content-Type: multipart/alternative; boundary="_000_D03630BDFB207moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uuml6aXY8xB73ONT91gFQM6VB6o Subject: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:45:53 -0000 --_000_D03630BDFB207moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to ask anyone that have real use cases for multi-valued or typ= ed/complex externalID to bring them to the WG. I think it would greatly he= lp better define this and make a decision on whether we need to extend the = current definition or just clarify it. Cheers, Morteza --_000_D03630BDFB207moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <54B884F381A88B4295D0948B517B5DE9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I would like to ask anyone that have real use cases for multi-valued o= r typed/complex externalID to bring them to the WG.  I think it would = greatly help better define this and make a decision on whether we need to e= xtend the current definition or just clarify it.


Cheers,
Morteza
--_000_D03630BDFB207moransarciscocom_-- From nobody Wed Sep 10 16:48:24 2014 Return-Path: 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 8BC571A0408 for ; Wed, 10 Sep 2014 16:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 XgtqOmytFnKr for ; Wed, 10 Sep 2014 16:48:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDEE1A03F7 for ; Wed, 10 Sep 2014 16:48:20 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8ANmH28010586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Sep 2014 23:48:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8ANmGCG007649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2014 23:48:17 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8ANmGCE005474; Wed, 10 Sep 2014 23:48:16 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Sep 2014 16:48:16 -0700 References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE69AC4-3C11-4832-8FF5-DA334D825048@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Wed, 10 Sep 2014 16:48:13 -0700 To: "Morteza Ansari (moransar)" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qZ7y8OS8bFQZLl6SMWEbPmrtqbU Cc: "scim@ietf.org" Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:48:22 -0000 In the cloud, ownership becomes less clear. There may be many relationships w= ith nodes acting more as peers. Is externalId even intended to be used here?= Phil > On Sep 10, 2014, at 16:43, "Morteza Ansari (moransar)" wrote: >=20 > Totally agree on improving the language to get to a more clear definition.= >=20 > Can you expand the cloud to cloud use case? I actually don=E2=80=99t see w= hy that > would require multi-valued attribute for that. >=20 >=20 > Cheers, > Morteza >=20 >> On 9/10/14, 12:25 PM, "Phil Hunt" wrote: >>=20 >> Coud to cloud is the use case I was thinking of. >>=20 >> But its not clear to me the enterprise side of this is thought out well >> yet either =E2=80=94 at least as far as privacy and security consideratio= ns go. >>=20 >> ExternalIds sound a lot like connector Ids. A bit scary, because in >> meta-directory days, accounts very quickly tended to have a connecter ID >> per relationship. >>=20 >> There is a lot of good and bad experiences here. :-) >>=20 >> That=E2=80=99s why I=E2=80=99d like to have stronger definition of this v= alue, its >> purpose, and security considerations. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar) >> wrote: >>=20 >>> Wearing chair hat: I think we need to let use cases drive this. What >>> are >>> the use cases for defining externalId as a multi-valued attribute or >>> turning it into a complex attribute? >>>=20 >>> Now with implementor hat: in almost all cases I have come across, there >>> is >>> a single authoritative source for the identity and hence a single value >>> for the externalID with no semantics to be enforced by the service >>> provider (etc. uniqueness) is all that is needed. I am sure if we dig >>> we >>> can come up with use cases in the larger context this would need to be >>> more complex, but why couldn=C2=B9t that be handled as an extension? >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>>> On 9/10/14, 11:17 AM, "Phil Hunt" wrote: >>>>=20 >>>> Any feedback on this topic? I=C2=B9ve heard very different conflicting >>>> opinions on whether externalId should be multi-valued. >>>>=20 >>>> Further, in the multi-value option you could say you say that each >>>> value >>>> should have a type. >>>>=20 >>>> I think we need more clarification on how this is to be used. >>>>=20 >>>> I am concerned that the notion that a single client controls externalId= >>>> is fits only an initial deployment. I would expect that over time, mxn >>>> relationships will emerge where many clients connect or reference the >>>> same cloud user. Having a separate externalId assigned by each >>>> different >>>> client involves a data type or access control model that SCIM currently= >>>> doesn=C2=B9t support. >>>>=20 >>>> For me, I can go either way=C5=A0but that=C2=B9s mainly because externa= lId is a >>>> bit >>>> mysterious to me. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>> On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: >>>>>=20 >>>>> I think the idea that certain values may need to be restricted to >>>>> certain clients is an enhancement. It sounds like an access control >>>>> feature.=20 >>>>>=20 >>>>> That said, it sounds like a security considerations issue. >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Sep 8, 2014, at 0:12, David M=C3=B6bius wrot= e: >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> for multivalue and that it can have a name for each client. >>>>>>=20 >>>>>> Doesn anyone has a idear how to solve the problems if one user >>>>>> belongs >>>>>> to several clients but not all values should be seen by all clients? >>>>>>=20 >>>>>> David >>>>>>=20 >>>>>>> On 06.09.2014 01:30, Phil Hunt wrote: >>>>>>> Looking at the definition for the externalId attribute, I see: >>>>>>>=20 >>>>>>> { >>>>>>> "name" : "externalId", >>>>>>> "type" : "string", >>>>>>> "multiValued" : false, >>>>>>> "description" : "An identifier for the Resource as defined by >>>>>>> the Service Consumer.", >>>>>>> "required" : true, >>>>>>> "caseExact" : false, >>>>>>> "mutability" : "readWrite", >>>>>>> "returned" : "default", >>>>>>> "uniqueness" : "none" >>>>>>> }, >>>>>>>=20 >>>>>>>=20 >>>>>>> Is this correct. Should it not be multi-valued and unique (although >>>>>>> enforcement is assumed to be the client)? >>>>>>>=20 >>>>>>> I=C2=B9m thinking multi-valued because there may be multiple clients= >>>>>>> associating with the same resource in the cloud. Each clients wants= >>>>>>> to >>>>>>> leave a unique identifier in externalId. >>>>>>>=20 >>>>>>> Any objections? >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> scim mailing list >>>>>>> scim@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>>=20 >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 10 16:48:57 2014 Return-Path: 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 C8C931A03F8 for ; Wed, 10 Sep 2014 16:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.353 X-Spam-Level: X-Spam-Status: No, score=-14.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 v18ZQoKagZmY for ; Wed, 10 Sep 2014 16:48:52 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823E01A03F7 for ; Wed, 10 Sep 2014 16:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5498; q=dns/txt; s=iport; t=1410392932; x=1411602532; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uNU6P+eW57iiSMkyji4S8Y/rbEK0GyTyxv3yvYhLA94=; b=ieoiZ5EGPHFaTVF2l+uyW/hnqukBiRkZ45Q1Db6SfsF/6A25YrP5NWe8 p6/BalOmNCrLFbsZkcngm3GmF4WHzg2+h5aDvr/Zl5tR8vz0KhpUarigJ ZugROr8h3GUuaaVplCg+UKE10SPAx582zxoSWBTG7hxBAs9UmUW64oWaC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAE7iEFStJV2R/2dsb2JhbABgDoJ/U1vKPAqHTYESFniEAwEBAQQBAQFLIAQTBgEIDgMDAQEBAQwbLgoBFAkKBAESHQSIIQ2/RQEXjmsRAV2ERgWGHYRjhkmLM5U5gx9CbIEPOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="76831212" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 10 Sep 2014 23:48:51 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8ANmpwr019551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 23:48:51 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 18:48:51 -0500 From: "Morteza Ansari (moransar)" To: Steve Moyer , "scim@ietf.org" Thread-Topic: [scim] scim Digest, Vol 33, Issue 11 Thread-Index: AQHPzVHFHElIb6vrakSVmJ5VASzWGQ== Date: Wed, 10 Sep 2014 23:48:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.85.45] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <980C670D47F05146ADF66E9E71561675@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/oHgrSJTEb1ZWLCVs0vtvPerApXg Subject: Re: [scim] scim Digest, Vol 33, Issue 11 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:48:55 -0000 Steve, Can you clarify this a bit please? Does this mean your current implementation treat externalId as a single valued attribute? Cheers, Morteza On 9/10/14, 12:43 PM, "Steve Moyer" wrote: >We've got a system deployed based on the preliminary SCIM specification >with about 2.5M users ... I think we could live with externalId being >multi-valued as long as it is both typed *and* has a primary flag. Our >SCIM users are mapped to LDAP attributes and externalId becomes uid and >is part of a user's DN, so any changes to the externalId field will >require code changes for us (we knew it was a preliminary specification >when we started). > >Thanks to everyone for the extensive discussion ... we're going to have >something wonderful in the end! > >Steve Moyer > >-- > >=B3The mark of the immature man is that he wants to die nobly for a cause, >while the mark of the mature man is that he wants to live humbly for >one.=B2 - Wilhelm Stekel > >----- Original Message ----- >From: scim-request@ietf.org >To: scim@ietf.org >Sent: Wednesday, September 10, 2014 3:01:21 PM >Subject: scim Digest, Vol 33, Issue 11 > >Send scim mailing list submissions to > scim@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim >or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > >You can reach the person managing the list at > scim-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of scim digest..." > > >Today's Topics: > > 1. Re: ExternalId - characteristics. (Phil Hunt) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 10 Sep 2014 11:17:59 -0700 >From: Phil Hunt >To: "scim@ietf.org" >Subject: Re: [scim] ExternalId - characteristics. >Message-ID: <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> >Content-Type: text/plain; charset=3Dwindows-1252 > >Any feedback on this topic? I?ve heard very different conflicting >opinions on whether externalId should be multi-valued. > >Further, in the multi-value option you could say you say that each value >should have a type. > >I think we need more clarification on how this is to be used. > >I am concerned that the notion that a single client controls externalId >is fits only an initial deployment. I would expect that over time, mxn >relationships will emerge where many clients connect or reference the >same cloud user. Having a separate externalId assigned by each different >client involves a data type or access control model that SCIM currently >doesn?t support. > >For me, I can go either way?but that?s mainly because externalId is a bit >mysterious to me. > >Phil > >@independentid >www.independentid.com >phil.hunt@oracle.com > > > >On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: > >> I think the idea that certain values may need to be restricted to >>certain clients is an enhancement. It sounds like an access control >>feature.=20 >>=20 >> That said, it sounds like a security considerations issue. >>=20 >> Phil >>=20 >>> On Sep 8, 2014, at 0:12, David M?bius wrote: >>>=20 >>> +1 >>>=20 >>> for multivalue and that it can have a name for each client. >>>=20 >>> Doesn anyone has a idear how to solve the problems if one user belongs >>>to several clients but not all values should be seen by all clients? >>>=20 >>> David >>>=20 >>>> On 06.09.2014 01:30, Phil Hunt wrote: >>>> Looking at the definition for the externalId attribute, I see: >>>>=20 >>>> { >>>> "name" : "externalId", >>>> "type" : "string", >>>> "multiValued" : false, >>>> "description" : "An identifier for the Resource as defined by >>>>the Service Consumer.", >>>> "required" : true, >>>> "caseExact" : false, >>>> "mutability" : "readWrite", >>>> "returned" : "default", >>>> "uniqueness" : "none" >>>> }, >>>>=20 >>>>=20 >>>> Is this correct. Should it not be multi-valued and unique (although >>>> enforcement is assumed to be the client)? >>>>=20 >>>> I?m thinking multi-valued because there may be multiple clients >>>> associating with the same resource in the cloud. Each clients wants >>>>to >>>> leave a unique identifier in externalId. >>>>=20 >>>> Any objections? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim > > >------------------------------ > >End of scim Digest, Vol 33, Issue 11 >************************************ > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 10 16:54:27 2014 Return-Path: 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 0EB181A0408 for ; Wed, 10 Sep 2014 16:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bWbeqp-lpgz6 for ; Wed, 10 Sep 2014 16:54:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064D51A03CF for ; Wed, 10 Sep 2014 16:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19892; q=dns/txt; s=iport; t=1410393256; x=1411602856; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=I5j+6RYBGqkaS0OxKA2MmWHXGwGFEK6JHc2IICnxFZM=; b=igUMQ9QFC8HE/SzKmcbT9q23tTY/DwUsHOquMHVAs07suQ4Qjovh6l0D D/PK78f5Sop3I1akoZjYEJOcJ4l5ePXhV4FW276rvMPLsimzvKrUrrSy6 10cQcsSWzalo+8DIAucLWsP+hqYjJhe6F7G7YpSuGRyCQ5li6hHkJ4Mfp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFACvkEFStJV2d/2dsb2JhbABggkdGU1vKPAEJh00BgREWeIQDAQEBBAEBAUYlGwIBCAcKAwECKAcnCxQJCAIEARIfiCMNv0gBF4oAhTwNCgGETAWRSYszlTmDYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208,217";a="354271956" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 10 Sep 2014 23:54:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8ANsFoc021306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 23:54:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 18:54:14 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt , SCIM WG Thread-Topic: [scim] Common attributes repeated in schemas Thread-Index: AQHPy55+pz/aWVwTckeMvJpE5/yI6pv3/8iAgALsfgA= Date: Wed, 10 Sep 2014 23:54:13 +0000 Message-ID: References: <00C8B171-86B7-4FB2-88F0-541CC87DDC02@oracle.com> In-Reply-To: <00C8B171-86B7-4FB2-88F0-541CC87DDC02@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.85.45] Content-Type: multipart/alternative; boundary="_000_D036322CFB215moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NgMipeLaeLlOwpPkrg2Jak7W2-M Subject: Re: [scim] Common attributes repeated in schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:54:23 -0000 --_000_D036322CFB215moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an implementor, given the small number of resource types and s= mall number of common attributes, I rather keep it simple and duplicate the= definition. Purely from readability/simplicity point of view. Also I don= =92t think we can assume all extension types will have the same common attr= ibutes. I do agree we should better define =93meta=94 though. Cheers, Morteza From: Phil Hunt > Date: Monday, September 8, 2014 at 1:15 PM To: "scim@ietf.org" > Subject: Re: [scim] Common attributes repeated in schemas One other issue I noticed. While =93id=94 and =93externalId=94 are defined= as part of User and Group, the =93meta=94 attribute is not defined. I propose that as part of creating this special =93Common=94 schema, we inc= lude the complex attribute =93meta=94 in that definition. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 8, 2014, at 12:52 PM, Phil Hunt > wrote: First, some background: I am working on a new revision of the core-schema d= raft document that will also clean up some terminology (e.g. confusing use = of =91core=92: core-schema, vs core-attributes, vs. core-resource etc) and = better explain how resourceTypes are established and defined. So far, the c= hanges have been clarifying only, but I ran into this item which suggests w= e may want to make some subtle changes. Reviewing the Schema section of the core-schema draft, I see that the commo= n attributes like id and externalId are repeated in each schema. For exampl= e in the definition for Group, we have=85 { "id" : "urn:ietf:params:scim:schemas:core:2.0:Group", "name" : "Group", "description" : "Group", "attributes" : [ { "name" : "id", "type" : "string", "multiValued" : false, "description" : "Unique identifier for the SCIM resource as defined= by the Service Provider. Each representation of the resource MUST include = a non-empty id value. This identifier MUST be unique across the Service Pro= vider's entire set of resources. It MUST be a stable, non-reassignable iden= tifier that does not change when the same resource is returned in subsequen= t requests. The value of the id attribute is always issued by the Service P= rovider and MUST never be specified by the Service Consumer. REQUIRED.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "always", "uniqueness" : "server" }, { "name" : "externalId", "type" : "string", "multiValued" : true, "description" : "An identifier for the Resource as defined by the S= ervice Consumer.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, =85. and so on into the group specific attrs If you look at the other schemas like the one for User, you will see these = same attributes repeated. Because of this, I am worried about the possibility that there may be confl= icting definitions of attribute characteristics between schemas. E.g. exte= rnalId is multi-valued in one, but not another. This could lead to configur= ation conflicts between schemas. I=92m wondering if we should create a new schema called =93Common=94 which = is a mandatory schema to any object schema. Its URI does not need to be inc= luded in the schemas attribute, but is always assumed present. urn:ietf:params:scim:schemas:core:2.0:Common As well, while this schema looks like an extension, all of its attributes b= elong at the =93top=94 level json structure within the resource rather than= in an extension URI based grouping (e.g. as we do with enterprise User ext= ension attributes). Maybe since there are only a couple of common attributes I am overstating t= he problem and this won=92t be an issue in practice. Is there a better way to express this? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D036322CFB215moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <46EE3BD52A98B24F8B083F66D10EAE67@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Speaking as an implementor, given the small number of  resource t= ypes and small number of common attributes, I rather keep it simple and dup= licate the definition.  Purely from readability/simplicity point of vi= ew.  Also I don=92t think we can assume all extension types will have the same common attributes.

I do agree we should better define =93meta=94 though.


Cheers,
Morteza

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, September 8, 2014 at = 1:15 PM
To: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] Common attribut= es repeated in schemas

One other issue I noticed.  While =93id=94 and =93externalId=94 are de= fined as part of User and Group, the =93meta=94 attribute is not defined.

I propose that as part of creating this special =93Common=94 schema, w= e include the complex attribute =93meta=94 in that definition.


On Sep 8, 2014, at 12:52 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

First, some background: I = am working on a new revision of the core-schema draft document that will al= so clean up some terminology (e.g. confusing use of =91core=92: core-schema= , vs core-attributes, vs. core-resource etc) and better explain how resourceTypes are established and defined. So far, = the changes have been clarifying only, but I ran into this item which sugge= sts we may want to make some subtle changes.

Reviewing the Schema section of the core-schema draft, I see that the commo= n attributes like id and externalId are repeated in each schema. For exampl= e in the definition for Group, we have=85 
  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group"=
;,
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "id",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the SCIM reso=
urce as defined by the Service Provider. Each representation of the resourc=
e MUST include a non-empty id value. This identifier MUST be unique across =
the Service Provider's entire set of resources. It MUST be a stable, non-re=
assignable identifier that does not change when the same resource is return=
ed in subsequent requests. The value of the id attribute is always issued b=
y the Service Provider and MUST never be specified by the Service Consumer.=
 REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "always",
        "uniqueness" : "server"
      },
      {
        "name" : "externalId",
        "type" : "string",
        "multiValued" : true,
        "description" : "An identifier for the Resource as d=
efined by the Service Consumer.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
=85. and so on into the group specific attrs

If you look at the other schemas like the one for User, you will see t= hese same attributes repeated.

Because of this, I am worried about the possibility that there may be = conflicting definitions of attribute characteristics between schemas.  = ;E.g. externalId is multi-valued in one, but not another. This could lead t= o configuration conflicts between schemas.

I=92m wondering if we should create a new schema called =93Common=94 w= hich is a mandatory schema to any object schema. Its URI does not need to b= e included in the schemas attribute, but is always assumed present.
urn:ietf:params:scim:schemas:core:2.0:Common
As well, while this schema looks like an extension, all of its attribu= tes belong at the =93top=94 level json structure within the resource rather= than in an extension URI based grouping (e.g. as we do with enterprise Use= r extension attributes).

Maybe since there are only a couple of common attributes I am overstat= ing the problem and this won=92t be an issue in practice. 

Is there a better way to express this?  

Phil

@independentid
phil.hunt@oracle.com



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

--_000_D036322CFB215moransarciscocom_-- From nobody Wed Sep 10 22:58:41 2014 Return-Path: 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 20C941A046C for ; Wed, 10 Sep 2014 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 NpmOKkUwHh71 for ; Wed, 10 Sep 2014 22:58:39 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFACB1A0464 for ; Wed, 10 Sep 2014 22:58:38 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so14026235obc.19 for ; Wed, 10 Sep 2014 22:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c/MqwkwSQjdeu/Q7/2OiuGVpJ0pe8umLP1A0Lz3cTJE=; b=oMGSa4Bpf4ZbdvlBfJKjjT/nKqZHGlsToCy0VbY0+ukBncRfjZaNNreUv2Ssh959PY weFUCkla3CX7Un6RwIrNXKCdjnsFqb9J3nVINuEZkc5E6qn4YQ6q+PPvBD48FHuFbr3D GCuX3YTx+bYzXQkh2emy3Pqw3IY5eJWtvQj5VfxpAWOm4jq+q3RtdkxlSP3I8NfCIMYU b2eODZ5ib5r+F6TEuQJo4oHQVWiCZ4eO83sm/I9MXqjprXRR+vg3u1YRVRLthMCL0Wql blSQR0QXx//7txE/m920Qv6i1qod9Zme3Ylo43p+fZVwOesrsb6tkwEXQGgLE9zBG4Cd IX5A== MIME-Version: 1.0 X-Received: by 10.182.18.101 with SMTP id v5mr21605253obd.64.1410415118227; Wed, 10 Sep 2014 22:58:38 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.43.225 with HTTP; Wed, 10 Sep 2014 22:58:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 15:58:38 +1000 X-Google-Sender-Auth: UztNRyUFC417x_CaGqjpZZ_lL0o Message-ID: From: Grahame Grieve To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Hk4Fl-7re4EfiRS93tQsHokJF7c Cc: "scim@ietf.org" Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 05:58:40 -0000 it's not clear what externalId is for. In a distributed system, it's not unlikely that there will be multiple relevant other identifiers - is there some notion of which is primary? For instance, I need to map between the User resource in the SCIM interface, and a Patient record in a different interface, so that the security engine knows that this user is the same as this patient. Should that be externalId, or should it be somewhere else (an extension?). I didn't think that the definition of external id was quite clear enough to be sure. But if I said to use externalId for that, what happens to other uses of externalId - same user on a different user record? (which is why I think I shouldn't use externalId for that) Earlier in the thread, someone said that multiple identifiers might leak between different clients. Well, you might want them to share the multiple identifiers, but limiting identifier to one doesn't solve the leakage problem - so I don't think it's a reason to limit it to one. Still, multiple identifiers are always a problem - how do you tell them apart? Actually, I looked for a set of links that identified related records to the user - e,g, href= + rel=. I would prefer this over the existing approach Grahame On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) wrote: > I would like to ask anyone that have real use cases for multi-valued or > typed/complex externalID to bring them to the WG. I think it would greatly > help better define this and make a decision on whether we need to extend the > current definition or just clarify it. > > > Cheers, > Morteza > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Thu Sep 11 01:13:54 2014 Return-Path: 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 266341A0667 for ; Thu, 11 Sep 2014 01:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 z0BsUhu9dUWm for ; Thu, 11 Sep 2014 01:13:48 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46811A0669 for ; Thu, 11 Sep 2014 01:13:47 -0700 (PDT) Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 11 Sep 2014 10:14:19 +0200 Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 11 Sep 2014 10:14:18 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Thu, 11 Sep 2014 10:14:18 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] ExternalId - characteristics. Thread-Index: AQHPyWGNPW6mqnfcxEStKJRB5tfEdJv2tFCAgAB1A4CAA2l8gIAADfcAgAAE8gCAAEgiAIAAATmAgACNOwA= Date: Thu, 11 Sep 2014 08:14:17 +0000 Message-ID: <73D43C2C-CD53-4C00-B224-1B2C26FF32ED@nexusgroup.com> References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> <9BE69AC4-3C11-4832-8FF5-DA334D825048@oracle.com> In-Reply-To: <9BE69AC4-3C11-4832-8FF5-DA334D825048@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.75.110.12] Content-Type: multipart/alternative; boundary="_000_73D43C2CCD534C00B2241B2C26FF32EDnexusgroupcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTtaIam4RmcbhSyCF9xE Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] ExternalId - characteristics. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:13:52 -0000 --_000_73D43C2CCD534C00B2241B2C26FF32EDnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think we are reading in more into the value then originally thought of. I= t=92s meant to keep things like the DN or GUID of the AD user when provisio= ning them to the cloud so that it=92s possible to use that attribute to ref= erence the User in the cloud using a filter. I just tried to figure out a n= ew name and renaming it to something more clear, but externalId is kinda go= od :) Maybe we should change the last sentence in the externalId description to m= ake it possible to have 2 different clients working against the same resour= ce in the same tenant (if that=92s a potential future use case). From: "The service provider MUST always interpret the externalId as scoped to the= client=92s tenant." To: "The service provider MUST always interpret the externalId as scoped to the= authenticated client." Just to make my self clear, I like the externalId to stay a singular attrib= ute. / Erik On 11 Sep 2014, at 01:48, Phil Hunt > wrote: In the cloud, ownership becomes less clear. There may be many relationships= with nodes acting more as peers. Is externalId even intended to be used he= re? Phil On Sep 10, 2014, at 16:43, "Morteza Ansari (moransar)" > wrote: Totally agree on improving the language to get to a more clear definition. Can you expand the cloud to cloud use case? I actually don=92t see why tha= t would require multi-valued attribute for that. Cheers, Morteza On 9/10/14, 12:25 PM, "Phil Hunt" > wrote: Coud to cloud is the use case I was thinking of. But its not clear to me the enterprise side of this is thought out well yet either =97 at least as far as privacy and security considerations go. ExternalIds sound a lot like connector Ids. A bit scary, because in meta-directory days, accounts very quickly tended to have a connecter ID per relationship. There is a lot of good and bad experiences here. :-) That=92s why I=92d like to have stronger definition of this value, its purpose, and security considerations. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar) wrote: Wearing chair hat: I think we need to let use cases drive this. What are the use cases for defining externalId as a multi-valued attribute or turning it into a complex attribute? Now with implementor hat: in almost all cases I have come across, there is a single authoritative source for the identity and hence a single value for the externalID with no semantics to be enforced by the service provider (etc. uniqueness) is all that is needed. I am sure if we dig we can come up with use cases in the larger context this would need to be more complex, but why couldn=B9t that be handled as an extension? Cheers, Morteza On 9/10/14, 11:17 AM, "Phil Hunt" wrote: Any feedback on this topic? I=B9ve heard very different conflicting opinions on whether externalId should be multi-valued. Further, in the multi-value option you could say you say that each value should have a type. I think we need more clarification on how this is to be used. I am concerned that the notion that a single client controls externalId is fits only an initial deployment. I would expect that over time, mxn relationships will emerge where many clients connect or reference the same cloud user. Having a separate externalId assigned by each different client involves a data type or access control model that SCIM currently doesn=B9t support. For me, I can go either way=8Abut that=B9s mainly because externalId is a bit mysterious to me. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 8, 2014, at 7:11 AM, Phil Hunt wrote: I think the idea that certain values may need to be restricted to certain clients is an enhancement. It sounds like an access control feature. That said, it sounds like a security considerations issue. Phil On Sep 8, 2014, at 0:12, David M=F6bius wrote: +1 for multivalue and that it can have a name for each client. Doesn anyone has a idear how to solve the problems if one user belongs to several clients but not all values should be seen by all clients? David On 06.09.2014 01:30, Phil Hunt wrote: Looking at the definition for the externalId attribute, I see: { "name" : "externalId", "type" : "string", "multiValued" : false, "description" : "An identifier for the Resource as defined by the Service Consumer.", "required" : true, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Is this correct. Should it not be multi-valued and unique (although enforcement is assumed to be the client)? I=B9m thinking multi-valued because there may be multiple clients associating with the same resource in the cloud. Each clients wants to leave a unique identifier in externalId. Any objections? Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_73D43C2CCD534C00B2241B2C26FF32EDnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I think we are reading in more into the value then originally thought of. I= t=92s meant to keep things like the DN or GUID of the AD user when provisio= ning them to the cloud so that it=92s possible to use that attribute to ref= erence the User in the cloud using a filter. I just tried to figure out a new name and renaming it to something= more clear, but externalId is kinda good :)

Maybe we should change the last sentence in the externalId description= to make it possible to have 2 different clients working against the same r= esource in the same tenant (if that=92s a potential future use case). =

From:
"The service provider MUST alway=
s interpret the externalId as scoped to the client=92s tenant."
To:
"The service provider MUST alway=
s interpret the externalId as scoped to the authenticated client."

Just to make my self clear, I like the externalId to stay a singular a= ttribute.
 
/ Erik

On 11 Sep 2014, at 01:48, Phil Hunt <phil.hunt@oracle.com> wrote:

In the cloud, ownership becomes less clear. There= may be many relationships with nodes acting more as peers. Is externalId e= ven intended to be used here?

Phil

On Sep 10, 2014, at 16:43, "Morteza Ansari (= moransar)" <moransar@cisco.co= m> wrote:

Totally agree on improving the language to get to a more clear definition.<= br>
Can you expand the cloud to cloud use case?  I actually don=92t see wh= y that
would require multi-valued attribute for that.


Cheers,
Morteza

On 9/10/14, 12:25 PM, "Phil Hunt" <<= a href=3D"mailto:phil.hunt@oracle.com">phil.hunt@oracle.com> wrote:<= br>
Coud to cloud is the use case I was thinking of.

But its not clear to me the enterprise side of this is thought out well
yet either =97 at least as far as privacy and security considerations go.
ExternalIds sound a lot like connector Ids. A bit scary, because in
meta-directory days, accounts very quickly tended to have a connecter ID per relationship.

There is a lot of good and bad experiences here.  :-)

That=92s why I=92d like to have stronger definition of this value, its
purpose, and security considerations.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar)
<moransar@cisco.com> wrote:

Wearing chair hat: I think we need to let use cas= es drive this.  What
are
the use cases for defining externalId as a multi-valued attribute or
turning it into a complex attribute?

Now with implementor hat: in almost all cases I have come across, there
is
a single authoritative source for the identity and hence a single value
for the externalID with no semantics to be enforced by the service
provider (etc. uniqueness) is all that is needed.  I am sure if we dig=
we
can come up with use cases in the larger context this would need to be
more complex, but why couldn=B9t that be handled as an extension?


Cheers,
Morteza

On 9/10/14, 11:17 AM, "Phil Hunt" <p= hil.hunt@oracle.com> wrote:

Any feedback on this topic? I=B9ve heard very different conflicting
opinions on whether externalId should be multi-valued.

Further, in the multi-value option you could say you say that each
value
should have a type.

I think we need more clarification on how this is to be used.

I am concerned that the notion that a single client controls externalId
is fits only an initial deployment. I would expect that over time, mxn
relationships will emerge where many clients connect or reference the
same cloud user.  Having a separate externalId assigned by each
different
client involves a data type or access control model that SCIM currently
doesn=B9t support.

For me, I can go either way=8Abut that=B9s mainly because externalId is a bit
mysterious to me.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 8, 2014, at 7:11 AM, Phil Hunt <phil.hu= nt@oracle.com> wrote:

I think the idea that certain values may need to be restricted to
certain clients is an enhancement. It sounds like an access control
feature.

That said, it sounds like a security considerations issue.

Phil

On Sep 8, 2014, at 0:12, David M=F6bius <d.moe= bius@tarent.de> wrote:

+1

for multivalue and that it can have a name for each client.

Doesn anyone has a idear how to solve the problems if one user
belongs
to several clients but not all values should be seen by all clients?

David

On 06.09.2014 01:30, Phil Hunt wrote:
Looking at the definition for the externalId attribute, I see:

  {
    "name" : "externalId",
    "type" : "string",
    "multiValued" : false,
    "description" : "An identifier for t= he Resource as defined by
the Service Consumer.",
    "required" : true,
    "caseExact" : false,
    "mutability" : "readWrite",
    "returned" : "default",
    "uniqueness" : "none"
  },


Is this correct. Should it not be multi-valued and unique (although
enforcement is assumed to be the client)?

I=B9m thinking multi-valued because there may be multiple clients
associating with the same resource in the cloud.  Each clients wants to
leave a unique identifier in externalId.

Any objections?

Phil

@independentid
www.independentid.com <http://www.independentid.com>
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_73D43C2CCD534C00B2241B2C26FF32EDnexusgroupcom_-- From nobody Thu Sep 11 05:09:27 2014 Return-Path: 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 D23C81A6F14 for ; Thu, 11 Sep 2014 05:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 KkpUw6qe7BNW for ; Thu, 11 Sep 2014 05:09:20 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A01A06F2 for ; Thu, 11 Sep 2014 05:09:17 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g12.aset.psu.edu (8.14.3/8.14.3) with ESMTP id s8BC9GBL2941098 for ; Thu, 11 Sep 2014 08:09:16 -0400 Date: Thu, 11 Sep 2014 08:09:15 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <1133230528.1743097.1410437355451.JavaMail.zimbra@psu.edu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.25.8.227] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: scim Digest, Vol 33, Issue 13 Thread-Index: EbIQfrrsHihBTsdC+IoIWURZqN1CKg== X-Virus-Scanned: by amavisd-new Archived-At: http://mailarchive.ietf.org/arch/msg/scim/gGoOqhQUrxBMVP615eeIYMS0dPA Subject: Re: [scim] scim Digest, Vol 33, Issue 13 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:09:24 -0000 Yes, our current implementation includes the externalId as a single-valued = attribute (which may be) included with any SCIM resource. I did however mi= sspeak yesterday when I stated that it's related to the uid (which is obvio= usly userName) and DN of the entry in our LDAP back-end. This field actual= ly contains a unique id assigned by another system here at the university. Steve Moyer -- =E2=80=9CThe mark of the immature man is that he wants to die nobly for a c= ause, while the mark of the mature man is that he wants to live humbly for = one.=E2=80=9D - Wilhelm Stekel From nobody Thu Sep 11 07:59:17 2014 Return-Path: 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 155CA1A6F66 for ; Thu, 11 Sep 2014 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no 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 yJ8IHtvJUqSV for ; Thu, 11 Sep 2014 07:59:12 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75F21A0382 for ; Thu, 11 Sep 2014 07:59:12 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id v10so14563203pde.17 for ; Thu, 11 Sep 2014 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=aGs5wSiGbwskUExoLPOOO9RwYcNYrLiZ6b6n/lYIRY0=; b=kP0h7th+9dUP0GA3nfDIapWBYDoH11gvd5XCPshTqacQiPrFL6M3ZaTjjMhIRbRwbI juJGEvt1kpYdC97iwmY7JYrds52ivoFGzg17mRHjUZy4q7cdNOLOysVeKTpQ9pdIy4Xh 3we2ZpATObTyz966+3gLlBnIlYsV99VjUgpnQW6N+cJcgAbufQ0pF3sxfXy39reIxU9A Abc6i+XSaDrniPmQNoynBULD8ESAiSTuWnBUaG0xDED6A8ifEePQVDjeabPsCpQy1QKl LA/RSLROTGyNRbUtIDE4y0rRHfz9q/fivXlp4MWhc1WrL8DbHoNYQvfyDsnXpyzQ+puS INJA== X-Received: by 10.70.52.199 with SMTP id v7mr2392192pdo.49.1410447552417; Thu, 11 Sep 2014 07:59:12 -0700 (PDT) Received: from [10.176.131.199] (mobile-166-171-250-031.mycingular.net. [166.171.250.31]) by mx.google.com with ESMTPSA id g13sm1377304pat.45.2014.09.11.07.59.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 07:59:11 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Chuck Mortimore Date: Thu, 11 Sep 2014 07:53:16 -0700 To: Grahame Grieve Archived-At: http://mailarchive.ietf.org/arch/msg/scim/dAwpMqSKZ50K4VoclvAlLnK7f7I Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:59:14 -0000 externalid is there to provide a surrogate primary key for the scim entity s= o it can be more easily addressed by scim consumers or federation services.=20= For example, if you are trying to provide single sign-on to a cloud service,= it is often more convenient for the IDP to use its local identifier for the= user, rather than to update its schema and store the identifier used by the= cloud service. So - it(or the provisions service it is paired with) would= use scim to set its primary id for the user as externalid and send that as t= he subject of a SAML assertion. =20 - cmort > On Sep 10, 2014, at 10:58 PM, Grahame Grieve wrote: >=20 > it's not clear what externalId is for. In a distributed system, it's > not unlikely that there will be multiple relevant other identifiers - > is there some notion of which is primary? For instance, I need to map > between the User resource in the SCIM interface, and a Patient record > in a different interface, so that the security engine knows that this > user is the same as this patient. Should that be externalId, or should > it be somewhere else (an extension?). I didn't think that the > definition of external id was quite clear enough to be sure. But if I > said to use externalId for that, what happens to other uses of > externalId - same user on a different user record? (which is why I > think I shouldn't use externalId for that) >=20 > Earlier in the thread, someone said that multiple identifiers might > leak between different clients. Well, you might want them to share the > multiple identifiers, but limiting identifier to one doesn't solve the > leakage problem - so I don't think it's a reason to limit it to one. >=20 > Still, multiple identifiers are always a problem - how do you tell > them apart? Actually, I looked for a set of links that identified > related records to the user - e,g, href=3D + rel=3D. I would prefer this > over the existing approach >=20 > Grahame >=20 >=20 > On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) > wrote: >> I would like to ask anyone that have real use cases for multi-valued or >> typed/complex externalID to bring them to the WG. I think it would great= ly >> help better define this and make a decision on whether we need to extend t= he >> current definition or just clarify it. >>=20 >>=20 >> Cheers, >> Morteza >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > ----- > http://www.healthintersections.com.au / > grahame@healthintersections.com.au / +61 411 867 065 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 15 13:05:15 2014 Return-Path: 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 347371A7015; Mon, 15 Sep 2014 13:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 POI0dQX8xcZz; Mon, 15 Sep 2014 13:05:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C4A1A7002; Mon, 15 Sep 2014 13:05:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140915200507.13631.94658.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 13:05:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/gRSEn4OxcC3wltp-DeOPmqIknb4 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-10.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:05:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Phil Hunt Kelly Grizzle Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-10.txt Pages : 66 Date : 2014-09-15 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 15 13:13:41 2014 Return-Path: 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 ED96C1A6FD4 for ; Mon, 15 Sep 2014 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 iOQ0H1KqVRFG for ; Mon, 15 Sep 2014 13:13:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970EC1A6FCE for ; Mon, 15 Sep 2014 13:13:29 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FKDSZW012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Sep 2014 20:13:28 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FKDRF8025223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Sep 2014 20:13:27 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FKDQZ8004395 for ; Mon, 15 Sep 2014 20:13:26 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Sep 2014 13:13:26 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <20140915200507.13631.94658.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 13:13:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C104137-6F82-4C94-88EE-4728A1E9ACB3@oracle.com> References: <20140915200507.13631.94658.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/moI7HFGc0lZ6cwzt8ewnEi7i24M Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-10.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:13:37 -0000 This draft includes some editorial changes to improve readability = specifically: * Simplified namespace definition for urn:ietf:params:scim * Clarified "schemas" attribute as representing the JSON body schema in = an HTTP Req/Resp * Reduced use of confusing term "core" in "Core User" and =93Core Group=94= vs core schema vs core attributes * Added clarifications and security considerations for externalId Finally, sections 3 and 4 were re-worked to make it clear how Resource = Types are defined and extended and the relationship and role of the = schemas attribute in JSON objects and messages. There were no normative changes other than clarifications. Comments appreciated. I will post the next API draft revision tomorrow. NOTE: as the discussion on externalId is still ongoing, I have not = changed the definition in this draft to multi-valued. I think we should = open a ticket for this one as I think there are a number of different = current uses (some of which may require multi-values). We may even want = to use =93type=94 from the multi-valued attribute type definition. OR, = we may want to talk about a more complex security context bound values = model (I am not sure how this would work). Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 1:05 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Phil Hunt > Kelly Grizzle > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-10.txt > Pages : 66 > Date : 2014-09-15 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) = specifications > are designed to make identity management in cloud based applications > and services easier. The specification suite builds upon experience > with existing schemas and deployments, placing specific emphasis on > simplicity of development and integration, while applying existing > authentication, authorization, and privacy models. Its intent is to > reduce the cost and complexity of user management operations by > providing a common user schema and extension model, as well as > binding documents to provide patterns for exchanging this schema > using HTTP protocol. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups and other resource types in JSON > format. This schema is intended for exchange and use with cloud > service providers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 17 10:24:54 2014 Return-Path: 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 6A7C11A03B5; Wed, 17 Sep 2014 10:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Eu6xTcgRoUdb; Wed, 17 Sep 2014 10:24:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 955291A0491; Wed, 17 Sep 2014 10:24:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917172451.829.84900.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 10:24:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VhcFE1cyNayOaUZgQA-o1N2swXQ Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-11.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:24:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-11.txt Pages : 80 Date : 2014-09-17 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized services. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model and a service protocol defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 17 10:50:17 2014 Return-Path: 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 9F9CB1A06FA for ; Wed, 17 Sep 2014 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 0QGgIGz9T6JV for ; Wed, 17 Sep 2014 10:50:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088701A06F8 for ; Wed, 17 Sep 2014 10:50:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8HHoDMT006440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Sep 2014 17:50:13 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8HHoCAZ028375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Sep 2014 17:50:12 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8HHoBQ2025738 for ; Wed, 17 Sep 2014 17:50:11 GMT Received: from [192.168.1.133] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Sep 2014 10:50:11 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <20140917172451.829.84900.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 10:50:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140917172451.829.84900.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/wznh0mV8-lFdtj8xzP1UPQmNcPo Subject: Re: [scim] I-D Action: draft-ietf-scim-api-11.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:50:15 -0000 As I mentioned in my email on Monday, this is an update to the API draft = that includes a normative change to the PATCH command. In the previous draft, the JSON was malformed after we moved the = =93schemas=94 attribute to the outer element in JSON. To fix the = problem, the array of operations is now moved under an attribute called = =93Operations=94. =93Operations=94 was chosen to be consistent with = =93Operations=94 in the Bulk request. As always, feedback appreciated. Regards, Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 17, 2014, at 10:24 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Technology Nexus > Chuck Mortimore > Filename : draft-ietf-scim-api-11.txt > Pages : 80 > Date : 2014-09-17 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is an HTTP based protocol that makes managing identities in multi- > domain scenarios easier to support through a standardized services. > Examples include but are not limited to enterprise to cloud service > providers, and inter-cloud based scenarios. The specification suite > seeks to build upon experience with existing schemas and deployments, > placing specific emphasis on simplicity of development and > integration, while applying existing authentication, authorization, > and privacy models. SCIM's intent is to reduce the cost and > complexity of user management operations by providing a common user > schema and extension model and a service protocol defined by this > document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed Sep 17 10:50:37 2014 Return-Path: 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 D64641A0704 for ; Wed, 17 Sep 2014 10:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 zpiogCDKe4sD for ; Wed, 17 Sep 2014 10:50:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCDB1A0700 for ; Wed, 17 Sep 2014 10:50:20 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8HHoJah006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Sep 2014 17:50:20 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8HHoIph001977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Sep 2014 17:50:19 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8HHoIGb028676 for ; Wed, 17 Sep 2014 17:50:18 GMT Received: from [192.168.1.133] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Sep 2014 10:50:17 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_BD88F275-60C6-4102-B618-B6776C842CAB" Message-Id: <2F60197B-8C39-4F83-AAD2-4F569836F62D@oracle.com> Date: Wed, 17 Sep 2014 10:50:17 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/DW4nwDybK0nAGJ5t6f_-yZXQJNs Subject: [scim] New I-JSON draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:50:26 -0000 --Apple-Mail=_BD88F275-60C6-4102-B618-B6776C842CAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I wanted to bring to your attention the new I-JSON draft from Tim Bray. = This is now going through final IETF approval. https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ Much of the requirements in this draft are already covered in our specs.=20= However one major new issue that comes out of the i-JSON draft is to = reject repeated objects. At the least, this is probably a security = consideration. A big problem with current parsers appears to be inconsistent handling = of repeated objects. Some aggregate, some pick a random instance. This = leads to security problems since you don=92t know what you are getting = for sure in the final parsed set of values. Looking at Tim=92s comments to the JOSE group, he indicates adoption of = i-json will be an important way to pressure the common libraries and = development tools to fix the issue as soon as possible. Because we=92ve already covered most of the issues, it seems like it may = result in a lot of editorial changes to adopt. I=92m loathe to reference = yet another specification in our specification, yet it may not be = avoidable.=20 Does anyone have any experience with JSON parsers on this point? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_BD88F275-60C6-4102-B618-B6776C842CAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I wanted to bring to your = attention the new I-JSON draft from Tim Bray. This is now going through = final IETF approval.

<= div>Much of the requirements in this draft are already covered in our = specs. 

However one major new issue that = comes out of the i-JSON draft is to reject repeated objects. At the = least, this is probably a security = consideration.

A big problem with current = parsers appears to be inconsistent handling of repeated objects. Some = aggregate, some pick a random instance. This leads to security problems = since you don=92t know what you are getting for sure in the final parsed = set of values.

Looking at Tim=92s comments to = the JOSE group, he indicates adoption of i-json will be an important way = to pressure the common libraries and development tools to fix the issue = as soon as possible.

Because we=92ve already = covered most of the issues, it seems like it may result in a lot of = editorial changes to adopt. I=92m loathe to reference yet another = specification in our specification, yet it may not be = avoidable. 

Does anyone have any = experience with JSON parsers on this point?

= --Apple-Mail=_BD88F275-60C6-4102-B618-B6776C842CAB-- From nobody Sat Sep 20 07:00:11 2014 Return-Path: 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 7B1A41A013B for ; Sat, 20 Sep 2014 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 TQETEX3hkyNN for ; Sat, 20 Sep 2014 07:00:03 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5691A00B8 for ; Sat, 20 Sep 2014 07:00:02 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo20so2580552obc.41 for ; Sat, 20 Sep 2014 07:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zP/opxY6yzYwgbHrEHDgiRWl9vW+uUh9d/LC2TrStXc=; b=dq3yUW+6gB2OBzNf8VmA+QWawagmWrd8nxukCdY5VjWb4sNjIeK7wGRYA6nt4uju5r bZpCx4TExbFnf9BHW45zjXPeRNiItuszwwGs9E+lpFO2SfPWznXj20713S4R8W/YrEOl lSo6HrghNLHrZFpWK25LDcFneIngLJ0Y4l4hvb9AFl2Z+AnP0EKZIiAfgP7hk2/Tfkcp qNbo/lCnPqGouStQO6n9YIwjQy693iagJZSWk6Lgy5g+YtUOwn8Shizjserk3X2uc00S ZX52vtphPlBet3aqFtA2P57D6tBH6+HAWQFrrC+Ehof03G0Q053UgHZtZ5TJJknzp6tJ z79g== MIME-Version: 1.0 X-Received: by 10.60.41.65 with SMTP id d1mr8021598oel.32.1411221602119; Sat, 20 Sep 2014 07:00:02 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.60.7.5 with HTTP; Sat, 20 Sep 2014 07:00:02 -0700 (PDT) In-Reply-To: <2F60197B-8C39-4F83-AAD2-4F569836F62D@oracle.com> References: <2F60197B-8C39-4F83-AAD2-4F569836F62D@oracle.com> Date: Sun, 21 Sep 2014 00:00:02 +1000 X-Google-Sender-Auth: 3jrGq2b6cZ71DGlZv6YLt4yaZhg Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NrAER2j79Y7pSzgnaqhWv-0HIcM Cc: SCIM WG Subject: Re: [scim] New I-JSON draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:00:04 -0000 my experience is that various JSON parsers behave differently when property names are duplicated. However what Tim's draft recommends works with all the parsers that I know of. If SCIM has duplicate property names anywhere, I haven't found it Grahame On Thu, Sep 18, 2014 at 3:50 AM, Phil Hunt wrote: > I wanted to bring to your attention the new I-JSON draft from Tim Bray. T= his > is now going through final IETF approval. > https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > Much of the requirements in this draft are already covered in our specs. > > However one major new issue that comes out of the i-JSON draft is to reje= ct > repeated objects. At the least, this is probably a security consideration= . > > A big problem with current parsers appears to be inconsistent handling of > repeated objects. Some aggregate, some pick a random instance. This leads= to > security problems since you don=E2=80=99t know what you are getting for s= ure in the > final parsed set of values. > > Looking at Tim=E2=80=99s comments to the JOSE group, he indicates adoptio= n of i-json > will be an important way to pressure the common libraries and development > tools to fix the issue as soon as possible. > > Because we=E2=80=99ve already covered most of the issues, it seems like i= t may > result in a lot of editorial changes to adopt. I=E2=80=99m loathe to refe= rence yet > another specification in our specification, yet it may not be avoidable. > > Does anyone have any experience with JSON parsers on this point? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Mon Sep 22 10:43:11 2014 Return-Path: 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 C5BB81A1B4A for ; Mon, 22 Sep 2014 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 qsYtYZDXCChz for ; Mon, 22 Sep 2014 10:43:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6241A1B27 for ; Mon, 22 Sep 2014 10:43:07 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8MHh5Nm001139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Sep 2014 17:43:06 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MHh4Qi001277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Sep 2014 17:43:05 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MHh49Q025699 for ; Mon, 22 Sep 2014 17:43:04 GMT Received: from [192.168.1.133] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Sep 2014 10:43:02 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_A2DC9CEE-027E-4162-A769-6619E5E8A287" Message-Id: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> Date: Mon, 22 Sep 2014 10:42:56 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qvG-IGgFUuGioizbrZyQ1CIbAhc Subject: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:43:08 -0000 --Apple-Mail=_A2DC9CEE-027E-4162-A769-6619E5E8A287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I received a question from an implementer about how to indicate = non-supported attributes that are defined in core-schema. For example, a service provider doesn=92t want to use =93photos=94 as = defined in the core schemas.=20 Should it: 1. Do nothing. Just accept the values and then ignore them. 2. In schemas, mark the attribute as =93readOnly=94 and then ignore = them. (this is acceptable in the current rules) 3. Remove the attribute from Schemas. If it then receives a value = should it: a. Ignore the value b. Return a schema error. In general, should we be silently ignoring attributes that are included = in a JSON payload (e.g. on POST) that are not part of the schema? Or, = should the server throw an error? With my editor hat off, my personal reaction is that servers should be = flexible in what they accept and feel free to pick and choose data with = appropriate DoS considerations. I have a tendency to think that a server = can simply ignore data it does not understand or care about. Further = the server is free to alter any values it does accept as long as it = returns the new values in its response. That said, when we are talking about standard schema, it may be useful = to do 2 above which tells a client admin why a server may not be = appearing to accept an attribute value. We may actually want to have a = mutability of =93unsupported=94 which simply means the server will = ignore it entirely and will never return a value. This is a bit better = than =93readOnly=94 which says the server may set the value but the = client may not. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_A2DC9CEE-027E-4162-A769-6619E5E8A287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = received a question from an implementer about how to indicate = non-supported attributes that are defined in = core-schema.

For example, a service provider doesn=92t = want to use =93photos=94 as defined in the core = schemas. 

Should = it:

1.  Do nothing.  Just accept the = values and then ignore them.

2.  In = schemas, mark the attribute as =93readOnly=94 and then ignore them. = (this is acceptable in the current rules)

3. =  Remove the attribute from Schemas.  If it then receives a = value should it:
a. Ignore the value
b. Return a = schema error.

In general, should we be silently = ignoring attributes that are included in a JSON payload (e.g. on POST) = that are not part of the schema?  Or, should the server throw an = error?

With my editor hat off, my personal = reaction is that servers should be flexible in what they accept and feel = free to pick and choose data with appropriate DoS considerations. I have = a tendency to think that a server can simply ignore data it does not = understand or care about.  Further the server is free to alter any = values it does accept as long as it returns the new values in its = response.

That said, when we are talking about = standard schema, it may be useful to do 2 above which tells a client = admin why a server may not be appearing to accept an attribute value. =  We may actually want to have a mutability of =93unsupported=94 = which simply means the server will ignore it entirely and will never = return a value.  This is a bit better than =93readOnly=94 which = says the server may set the value but the client may = not.

= --Apple-Mail=_A2DC9CEE-027E-4162-A769-6619E5E8A287-- From nobody Mon Sep 22 10:56:52 2014 Return-Path: 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 C5E161A0158 for ; Mon, 22 Sep 2014 10:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 7akIfhbqHJoG for ; Mon, 22 Sep 2014 10:56:50 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4421A1B02 for ; Mon, 22 Sep 2014 10:56:49 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id b6so2028731lbj.26 for ; Mon, 22 Sep 2014 10:56:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ChZJpJGyp+fFzOkV01Qt5BGzaw7LvX8tVyZDZ9gh8tQ=; b=jBQ+EdLiL8+AntH0ibfkkwqiPB6D3q5BlPrpm5coLiXugmX+bEIXaRD2PXGL021mBf 3YXkEtWIlQgaqjuE4eRrHIMVPyvSldl6oqw39bmecGqHukB3NbCm9osvFqn5x9AEtjRr xDFkuk8cLuxZugC2v0jXitADUTWrO7R8bysE/HUo8hs3wREErB1phh7/UkUtg2pZUuG2 oTlTtjY0sY9XhdPjlE4lq5bTnyIX/OqCbBeGhfkrWVGQg17efpT/+Wn8snhqFtqcFYRv Ba3Mu2Bf1tJNs2nGrs0WIjba/VUl3/hOkvsjrn8kWuO+CZ2FzYHn4gYGJpMR2KyWJaCq h8XA== X-Gm-Message-State: ALoCoQluntooICopAwsg1bfYwj4QvBABE9SepJZG0lGPiIg039g7DC+RMLRdy9Xrp5q6C1aVpFZw X-Received: by 10.152.9.200 with SMTP id c8mr4672438lab.76.1411408608191; Mon, 22 Sep 2014 10:56:48 -0700 (PDT) Received: from [10.0.0.116] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id l1sm3993288lbj.20.2014.09.22.10.56.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 10:56:47 -0700 (PDT) Message-ID: <542062DF.6040002@mnt.se> Date: Mon, 22 Sep 2014 19:56:47 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: scim@ietf.org References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> In-Reply-To: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/X5YAuvpJyXwrUtcIaOzdADQzLcA Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:56:51 -0000 On 2014-09-22 19:42, Phil Hunt wrote: > I received a question from an implementer about how to indicate > non-supported attributes that are defined in core-schema. > > For example, a service provider doesn’t want to use “photos” as defined > in the core schemas. > speaking only as an individual... > Should it: > > 1. Do nothing. Just accept the values and then ignore them. > > 2. In schemas, mark the attribute as “readOnly” and then ignore them. > (this is acceptable in the current rules) > > 3. Remove the attribute from Schemas. If it then receives a value > should it: > a. Ignore the value > b. Return a schema error. My gut feeling is 3b. If you aren't willing to store it, you shouldn't pretend to. MVH leifj From nobody Mon Sep 22 12:02:44 2014 Return-Path: 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 DF8B01A1B60 for ; Mon, 22 Sep 2014 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] 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 rqaHlPJfpxX5 for ; Mon, 22 Sep 2014 12:02:40 -0700 (PDT) Received: from mail.cleargovsolutions.com (mail.cleargovsolutions.com [74.217.92.3]) (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 4F93B1A1B4F for ; Mon, 22 Sep 2014 12:02:40 -0700 (PDT) Received: from AlexisPC ([12.208.5.230]) by mail.cleargovsolutions.com (IceWarp 11.0.0.1 x64) with ASMTP id 201409221500531244; Mon, 22 Sep 2014 15:00:53 -0400 From: "Alexis Bor" To: "'Phil Hunt'" , "'SCIM WG'" References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> In-Reply-To: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> Date: Mon, 22 Sep 2014 14:02:18 -0500 Message-ID: <002101cfd697$bb4d3a00$31e7ae00$@cleargovsolutions.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CFD66D.D27BECF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEE3LpjRJYQUN2HX2mmKDtZ5qOhB52jc/Gg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/scim/tBkKA4oYAw9ZuWEYrA1jGnsYkOg Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:02:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CFD66D.D27BECF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Seems to me that the simplest is to just drop bits that you don't want. However, the reality of the situation could easily put you in a situation where your are logging the events and a large amount of unprocessed data gets stored in the event logs. It's not a long distance to push those events to Splunk and harvest the excess data. I would tend to want to return a message back to the user so that this issue is understood and hopefully adjusted. It will lower the amount of data coming in, processed, stored and logged. Alexis Bor From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Monday, September 22, 2014 12:43 PM To: SCIM WG Subject: [scim] Questions about defined vs. supported schema I received a question from an implementer about how to indicate non-supported attributes that are defined in core-schema. For example, a service provider doesn't want to use "photos" as defined in the core schemas. Should it: 1. Do nothing. Just accept the values and then ignore them. 2. In schemas, mark the attribute as "readOnly" and then ignore them. (this is acceptable in the current rules) 3. Remove the attribute from Schemas. If it then receives a value should it: a. Ignore the value b. Return a schema error. In general, should we be silently ignoring attributes that are included in a JSON payload (e.g. on POST) that are not part of the schema? Or, should the server throw an error? With my editor hat off, my personal reaction is that servers should be flexible in what they accept and feel free to pick and choose data with appropriate DoS considerations. I have a tendency to think that a server can simply ignore data it does not understand or care about. Further the server is free to alter any values it does accept as long as it returns the new values in its response. That said, when we are talking about standard schema, it may be useful to do 2 above which tells a client admin why a server may not be appearing to accept an attribute value. We may actually want to have a mutability of "unsupported" which simply means the server will ignore it entirely and will never return a value. This is a bit better than "readOnly" which says the server may set the value but the client may not. Phil @independentid www.independentid.com phil.hunt@oracle.com ------=_NextPart_000_0022_01CFD66D.D27BECF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems to me that the simplest is to just drop bits that you = don’t want.  However, the reality of the situation could = easily put you in a situation where your are logging the events and a = large amount of unprocessed data gets stored in the event logs.  = It’s not a long distance to push those events to Splunk and = harvest the excess data.

 

I would tend to want to return a message back to the user so that = this issue is understood and hopefully adjusted.  It will lower the = amount of data coming in, processed, stored and logged.  =

 

Alexis Bor

 

From: scim = [mailto:scim-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Monday, September 22, 2014 12:43 PM
To: = SCIM WG
Subject: [scim] Questions about defined vs. supported = schema

 

I received a = question from an implementer about how to indicate non-supported = attributes that are defined in core-schema.

 

For example, a service provider doesn’t want to = use “photos” as defined in the core = schemas. 

 

Should it:

 

1.  Do nothing.  Just accept the values and = then ignore them.

 

2.  In schemas, mark the attribute as = “readOnly” and then ignore them. (this is acceptable in the = current rules)

 

3.  Remove the attribute from Schemas.  If = it then receives a value should it:

a. Ignore the value

b. Return a schema error.

 

In general, should we be silently ignoring attributes = that are included in a JSON payload (e.g. on POST) that are not part of = the schema?  Or, should the server throw an = error?

 

With my editor hat off, my personal reaction is that = servers should be flexible in what they accept and feel free to pick and = choose data with appropriate DoS considerations. I have a tendency to = think that a server can simply ignore data it does not understand or = care about.  Further the server is free to alter any values it does = accept as long as it returns the new values in its = response.

 

That said, when we are talking about standard schema, = it may be useful to do 2 above which tells a client admin why a server = may not be appearing to accept an attribute value.  We may actually = want to have a mutability of “unsupported” which simply = means the server will ignore it entirely and will never return a value. =  This is a bit better than “readOnly” which says the = server may set the value but the client may = not.

 

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 

 

 

------=_NextPart_000_0022_01CFD66D.D27BECF0-- From nobody Mon Sep 22 12:29:24 2014 Return-Path: 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 0FF421A1BEA for ; Mon, 22 Sep 2014 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 UAziUPvGEBDd for ; Mon, 22 Sep 2014 12:29:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD661A1BF7 for ; Mon, 22 Sep 2014 12:28:52 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8MJSnFr023776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Sep 2014 19:28:49 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MJSmMW006949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2014 19:28:48 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MJSm9F013962; Mon, 22 Sep 2014 19:28:48 GMT Received: from [192.168.1.133] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Sep 2014 12:28:47 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF10FD2-2C47-4180-803C-5F3D4EBE2C28" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <002101cfd697$bb4d3a00$31e7ae00$@cleargovsolutions.com> Date: Mon, 22 Sep 2014 12:28:45 -0700 Message-Id: References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> <002101cfd697$bb4d3a00$31e7ae00$@cleargovsolutions.com> To: Alexis Bor X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/qwO84RduOl8KS8tig89hm2cD_f8 Cc: SCIM WG Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:29:22 -0000 --Apple-Mail=_DBF10FD2-2C47-4180-803C-5F3D4EBE2C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We=92ve had principles elsewhere that the server is free to ignore = undefined parameters (e.g. in the API requests such as retrieval). For payload, should service providers be consistent and ignore data that = is not understood/defined? Or should they be strict? Where this appears to break down, is that a SCIM client that sends = payload that is conformant to the spec could get penalized because the = server does not conform to the spec (it doesn=92t support all attributes = defined in the spec). In this case, if we follow your thought, then it = is more important that clients conform to individual servers rather than = the specification. This leads us to having to write more deployment = specific connectors because each connector must conform to the = deployment more than the spec. In general how should we draw the line on the REST principle of being = flexible in what is accepted? 3 possible options: 1. Strict - server specific: Clients must conform to the schema = published by individual servers. 2. Server Specific + Standard Schema: Clients can look at server schema = for extensions, but may use any published schema (the server does not = have to accept the values and will not throw errors). Clients MAY not = add attributes if they are not defined in the server schema or published = in core schema. 3. Loose: Clients can choose to add any attributes they want but the = server is free to ignore. Service providers should be careful not to log = requests in detail and must consider DoS ramifications. As an individual I think #2 strikes the right balance. Further I would = not force servers to throw an error (maybe it is a SHOULD?) Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 22, 2014, at 12:02 PM, Alexis Bor = wrote: > Seems to me that the simplest is to just drop bits that you don=92t = want. However, the reality of the situation could easily put you in a = situation where your are logging the events and a large amount of = unprocessed data gets stored in the event logs. It=92s not a long = distance to push those events to Splunk and harvest the excess data. > =20 > I would tend to want to return a message back to the user so that this = issue is understood and hopefully adjusted. It will lower the amount of = data coming in, processed, stored and logged.=20 > =20 > Alexis Bor > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Monday, September 22, 2014 12:43 PM > To: SCIM WG > Subject: [scim] Questions about defined vs. supported schema > =20 > I received a question from an implementer about how to indicate = non-supported attributes that are defined in core-schema. > =20 > For example, a service provider doesn=92t want to use =93photos=94 as = defined in the core schemas.=20 > =20 > Should it: > =20 > 1. Do nothing. Just accept the values and then ignore them. > =20 > 2. In schemas, mark the attribute as =93readOnly=94 and then ignore = them. (this is acceptable in the current rules) > =20 > 3. Remove the attribute from Schemas. If it then receives a value = should it: > a. Ignore the value > b. Return a schema error. > =20 > In general, should we be silently ignoring attributes that are = included in a JSON payload (e.g. on POST) that are not part of the = schema? Or, should the server throw an error? > =20 > With my editor hat off, my personal reaction is that servers should be = flexible in what they accept and feel free to pick and choose data with = appropriate DoS considerations. I have a tendency to think that a server = can simply ignore data it does not understand or care about. Further = the server is free to alter any values it does accept as long as it = returns the new values in its response. > =20 > That said, when we are talking about standard schema, it may be useful = to do 2 above which tells a client admin why a server may not be = appearing to accept an attribute value. We may actually want to have a = mutability of =93unsupported=94 which simply means the server will = ignore it entirely and will never return a value. This is a bit better = than =93readOnly=94 which says the server may set the value but the = client may not. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 --Apple-Mail=_DBF10FD2-2C47-4180-803C-5F3D4EBE2C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
We=92ve had principles elsewhere that the = server is free to ignore undefined parameters (e.g. in the API requests = such as retrieval).

For payload, should service = providers be consistent and ignore data that is not understood/defined? =  Or should they be strict?

Where this = appears to break down, is that a SCIM client that sends payload that is = conformant to the spec could get penalized because the server does not = conform to the spec (it doesn=92t support all attributes defined in the = spec).  In this case, if we follow your thought, then it is more = important that clients conform to individual servers rather than the = specification.  This leads us to having to write more deployment = specific connectors because each connector must conform to the = deployment more than the spec.

In general how = should we draw the line on the REST principle of being flexible in what = is accepted?

3 possible = options:

1.  Strict - server specific: = Clients must conform to the schema published by individual = servers.
2.  Server Specific + Standard Schema: Clients = can look at server schema for extensions, but may use any published = schema (the server does not have to accept the values and will not throw = errors).  Clients MAY not add attributes if they are not defined in = the server schema or published in core schema.
3.  Loose: = Clients can choose to add any attributes they want but the server is = free to ignore. Service providers should be careful not to log requests = in detail and must consider DoS = ramifications.

As an individual I think #2 = strikes the right balance.  Further I would not force servers to = throw an error (maybe it is a SHOULD?)

Phil

On Sep 22, 2014, at 12:02 PM, Alexis Bor <alexis.bor@cleargovsoluti= ons.com> wrote:

Seems to me that the simplest is to just drop bits = that you don=92t want.  However, the reality of the situation could = easily put you in a situation where your are logging the events and a = large amount of unprocessed data gets stored in the event logs.  = It=92s not a long distance to push those events to Splunk and harvest = the excess data.

 

I would tend to want to return a message back to = the user so that this issue is understood and hopefully adjusted.  = It will lower the amount of data coming in, processed, stored and = logged. 

 

Alexis Bor

 

From: scim [mailto:scim-bounces@ietf.org] = On Behalf Of Phil Hunt
Sent: Monday, September 22, 2014 = 12:43 PM
To: SCIM WG
Subject: [scim] Questions about = defined vs. supported schema

 

I = received a question from an implementer about how to indicate = non-supported attributes that are defined in = core-schema.

 

For example, a service provider doesn=92t want to = use =93photos=94 as defined in the core = schemas. 

 

Should it:

 

1.  Do nothing.  Just accept the values = and then ignore them.

 

2.  In schemas, mark the attribute as = =93readOnly=94 and then ignore them. (this is acceptable in the current = rules)

 

3.  Remove the attribute from Schemas.  If = it then receives a value should it:

a. Ignore the value

b. Return a schema = error.

 

In general, should we be silently ignoring = attributes that are included in a JSON payload (e.g. on POST) that are = not part of the schema?  Or, should the server throw an = error?

 

With my editor hat off, my personal reaction is that = servers should be flexible in what they accept and feel free to pick and = choose data with appropriate DoS considerations. I have a tendency to = think that a server can simply ignore data it does not understand or = care about.  Further the server is free to alter any values it does = accept as long as it returns the new values in its = response.

 

That said, when we are talking about standard = schema, it may be useful to do 2 above which tells a client admin why a = server may not be appearing to accept an attribute value.  We may = actually want to have a mutability of =93unsupported=94 which simply = means the server will ignore it entirely and will never return a value. =  This is a bit better than =93readOnly=94 which says the server may = set the value but the client may not.

 

 


= --Apple-Mail=_DBF10FD2-2C47-4180-803C-5F3D4EBE2C28-- From nobody Mon Sep 22 12:58:59 2014 Return-Path: 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 74E9B1A1B3D for ; Mon, 22 Sep 2014 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 11qvOfRe5Jms for ; Mon, 22 Sep 2014 12:58:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864E01A1B39 for ; Mon, 22 Sep 2014 12:58:56 -0700 (PDT) Received: from BY2PR03MB313.namprd03.prod.outlook.com (10.141.139.13) by BY2PR03MB314.namprd03.prod.outlook.com (10.141.139.19) with Microsoft SMTP Server (TLS) id 15.0.1039.12; Mon, 22 Sep 2014 19:58:33 +0000 Received: from BY2PR03MB313.namprd03.prod.outlook.com ([10.141.139.13]) by BY2PR03MB313.namprd03.prod.outlook.com ([10.141.139.13]) with mapi id 15.00.1039.011; Mon, 22 Sep 2014 19:58:33 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Questions about defined vs. supported schema Thread-Index: AQHP1oyvUS/ZaHK8LEeJAndmtALGV5wNcA6AgAAh2QA= Date: Mon, 22 Sep 2014 19:58:33 +0000 Message-ID: <1bdb29635b2b4fb6a0943d2d82a7d266@BY2PR03MB313.namprd03.prod.outlook.com> References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> <542062DF.6040002@mnt.se> In-Reply-To: <542062DF.6040002@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB314; x-forefront-prvs: 034215E98F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(189002)(377424004)(24454002)(199003)(13464003)(107046002)(107886001)(54356999)(50986999)(76176999)(77982003)(79102003)(46102003)(81342003)(74502003)(74662003)(81542003)(80022003)(33646002)(64706001)(20776003)(86612001)(99396002)(92566001)(101416001)(86362001)(76482002)(85852003)(106116001)(83072002)(106356001)(105586002)(31966008)(108616004)(76576001)(15975445006)(2656002)(87936001)(99286002)(19580395003)(120916001)(19580405001)(90102001)(83322001)(2501002)(97736003)(85306004)(21056001)(4396001)(74316001)(95666004)(3826002)(24736002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB314; H:BY2PR03MB313.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/5tZVE4hxrOiXGxhPjP_peEsnrZM Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:58:58 -0000 I have a tendency to agree for items in core schema=20 -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Monday, September 22, 2014 10:57 AM To: scim@ietf.org Subject: Re: [scim] Questions about defined vs. supported schema On 2014-09-22 19:42, Phil Hunt wrote: > I received a question from an implementer about how to indicate=20 > non-supported attributes that are defined in core-schema. >=20 > For example, a service provider doesn't want to use "photos" as=20 > defined in the core schemas. >=20 speaking only as an individual... > Should it: >=20 > 1. Do nothing. Just accept the values and then ignore them. >=20 > 2. In schemas, mark the attribute as "readOnly" and then ignore them. > (this is acceptable in the current rules) >=20 > 3. Remove the attribute from Schemas. If it then receives a value=20 > should it: > a. Ignore the value > b. Return a schema error. My gut feeling is 3b. If you aren't willing to store it, you shouldn't pret= end to. =09 MVH leifj _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 22 13:05:32 2014 Return-Path: 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 488BE1A1BA7 for ; Mon, 22 Sep 2014 13:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 KErIpjiA6lF5 for ; Mon, 22 Sep 2014 13:05:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5587D1A1BA6 for ; Mon, 22 Sep 2014 13:05:04 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id m15so3195183wgh.34 for ; Mon, 22 Sep 2014 13:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8JPBa1KyQSerOG6eaBEUgK9SNJWoBYkUSQmhGzuJ4qg=; b=psnB+pHOV8NY8iTCEscR/AFWpYPlVSORVBScnym0BlX4QZ2qikJ0tj+WVOesaz9GA1 /qjHVEZTEWepTboGLH+mQG4eTMVK6N1oOjUowjpQNOxYadfmX2yIyOzmV+Drb/8ogWdN HWdF7MFPv8b4RmpB3UGV4Ylnw/qgyUeDuyWPRVHylIYWcxy8us8kL5MglcFKY+QIYZdb Pc/AvTcw+w+BFBg+4m/6C3pdsn5OsLsNsrwFZgom4J+nAZz3o9mdQsl72swG7cEYWcrP XytUU3uVp2gLoGchddPN64D/UjlFGoXg3vkIpCR40Tdv76EFjCu6dhWOm0bCTNZ+e9Nt Urqg== MIME-Version: 1.0 X-Received: by 10.180.188.70 with SMTP id fy6mr18007292wic.25.1411416303195; Mon, 22 Sep 2014 13:05:03 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.77.199 with HTTP; Mon, 22 Sep 2014 13:05:03 -0700 (PDT) In-Reply-To: <1bdb29635b2b4fb6a0943d2d82a7d266@BY2PR03MB313.namprd03.prod.outlook.com> References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> <542062DF.6040002@mnt.se> <1bdb29635b2b4fb6a0943d2d82a7d266@BY2PR03MB313.namprd03.prod.outlook.com> Date: Tue, 23 Sep 2014 06:05:03 +1000 X-Google-Sender-Auth: cQfmQJMO9LNJodZMlbY0wb7AHl8 Message-ID: From: Grahame Grieve To: Anthony Nadalin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/H6vSdu8CJBfQzbOht9rw9jj6voI Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:05:28 -0000 in which case either the error has to computably tied to a particular element, or the schema has to be able to indicate what is not supported. Since the schema allows design or deployment time decision making it would much superior Grahame On Tue, Sep 23, 2014 at 5:58 AM, Anthony Nadalin wrote: > I have a tendency to agree for items in core schema > > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Monday, September 22, 2014 10:57 AM > To: scim@ietf.org > Subject: Re: [scim] Questions about defined vs. supported schema > > On 2014-09-22 19:42, Phil Hunt wrote: >> I received a question from an implementer about how to indicate >> non-supported attributes that are defined in core-schema. >> >> For example, a service provider doesn't want to use "photos" as >> defined in the core schemas. >> > > speaking only as an individual... > >> Should it: >> >> 1. Do nothing. Just accept the values and then ignore them. >> >> 2. In schemas, mark the attribute as "readOnly" and then ignore them. >> (this is acceptable in the current rules) >> >> 3. Remove the attribute from Schemas. If it then receives a value >> should it: >> a. Ignore the value >> b. Return a schema error. > > My gut feeling is 3b. If you aren't willing to store it, you shouldn't pretend to. > > MVH leifj > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Mon Sep 22 14:20:41 2014 Return-Path: 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 9C6D61A6F01 for ; Mon, 22 Sep 2014 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 K1IV_m651uq9 for ; Mon, 22 Sep 2014 14:20:34 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F411A6EFB for ; Mon, 22 Sep 2014 14:20:33 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so3417467wgg.32 for ; Mon, 22 Sep 2014 14:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kNijleFqbD68OwIMPNIaU9JUhGdnwsuSIOVPoDP9Vmo=; b=ZVyqPJmtQv/bfhr84XmucDScJPiKOM9n7woadxu7FfNBYZpz13M+j4x/0tLVZTyo/n 8s5djBU/DgBM7YC1yDDas8E8YrB7ch8P5K1v2I2E6QzJa/phInQqkMCDIRtE4zOQPnfX Am8fP1kzpu0G4TKroDcyjLn/xSIotl3lQWdDGwqaTEL+X9eX82gR14RhDQnxCZ4zMqcD oGyEkKUjP00u06W2FiNk8MhKXnJQiNu5MEB7Q7Z3dqcKdlFZk6UHTtSpa1lbqASQNXXV UYFZhf02uNvRCDUPDfp4fenbQPYy1bnjRC9mVpIQ5kxxbqUxc5S6td7ecNAIY637Yje/ i8SA== X-Gm-Message-State: ALoCoQmyQM5ITFPrGBVk3ucoPnSv46ycD2E173Y01h4e+qFpsKsEZGrNK1OAsa9qHI9N/wy9EvQN X-Received: by 10.194.243.161 with SMTP id wz1mr23865839wjc.0.1411420832492; Mon, 22 Sep 2014 14:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.108.10 with HTTP; Mon, 22 Sep 2014 14:20:12 -0700 (PDT) In-Reply-To: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> From: Ian Glazer Date: Mon, 22 Sep 2014 14:20:12 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0149360859a54f0503ae0593 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/mHJ--s3WNqW78hni6u38LxO7FZY Cc: SCIM WG Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:20:37 -0000 --089e0149360859a54f0503ae0593 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt wrote: > I received a question from an implementer about how to indicate > non-supported attributes that are defined in core-schema. > > For example, a service provider doesn=E2=80=99t want to use =E2=80=9Cphot= os=E2=80=9D as defined in > the core schemas. > > Should it: > > 1. Do nothing. Just accept the values and then ignore them. > > 2. In schemas, mark the attribute as =E2=80=9CreadOnly=E2=80=9D and then= ignore them. > (this is acceptable in the current rules) > > 3. Remove the attribute from Schemas. If it then receives a value shoul= d > it: > a. Ignore the value > b. Return a schema error. > > In general, should we be silently ignoring attributes that are included i= n > a JSON payload (e.g. on POST) that are not part of the schema? Or, shoul= d > the server throw an error? > > With my editor hat off, my personal reaction is that servers should be > flexible in what they accept and feel free to pick and choose data with > appropriate DoS considerations. I have a tendency to think that a server > can simply ignore data it does not understand or care about. Further the > server is free to alter any values it does accept as long as it returns t= he > new values in its response. > > That said, when we are talking about standard schema, it may be useful to > do 2 above which tells a client admin why a server may not be appearing t= o > accept an attribute value. We may actually want to have a mutability of > =E2=80=9Cunsupported=E2=80=9D which simply means the server will ignore i= t entirely and > will never return a value. This is a bit better than =E2=80=9CreadOnly= =E2=80=9D which says > the server may set the value but the client may not. > > Doing 2 seems like a workable hack but a hack nonetheless. I like the ide= a of an "unsupported" mutability - makes things a bit more clear > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --089e0149360859a54f0503ae0593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I received a question from an implementer about how to indi= cate non-supported attributes that are defined in core-schema.

For example, a service provider doesn=E2=80=99t want to use =E2=80= =9Cphotos=E2=80=9D as defined in the core schemas.=C2=A0

Should it:

1.=C2=A0 Do nothing.=C2=A0 Just = accept the values and then ignore them.

2.=C2=A0 I= n schemas, mark the attribute as =E2=80=9CreadOnly=E2=80=9D and then ignore= them. (this is acceptable in the current rules)

3= .=C2=A0 Remove the attribute from Schemas.=C2=A0 If it then receives a valu= e should it:
a. Ignore the value
b. Return a schema err= or.

In general, should we be silently ignoring att= ributes that are included in a JSON payload (e.g. on POST) that are not par= t of the schema?=C2=A0 Or, should the server throw an error?

=
With my editor hat off, my personal reaction is that servers sho= uld be flexible in what they accept and feel free to pick and choose data w= ith appropriate DoS considerations. I have a tendency to think that a serve= r can simply ignore data it does not understand or care about.=C2=A0 Furthe= r the server is free to alter any values it does accept as long as it retur= ns the new values in its response.

That said, when= we are talking about standard schema, it may be useful to do 2 above which= tells a client admin why a server may not be appearing to accept an attrib= ute value.=C2=A0 We may actually want to have a mutability of =E2=80=9Cunsu= pported=E2=80=9D which simply means the server will ignore it entirely and = will never return a value.=C2=A0 This is a bit better than =E2=80=9CreadOnl= y=E2=80=9D which says the server may set the value but the client may not.<= /div>

Doing 2 seems like a workable h= ack but a hack nonetheless. I like the idea of an "unsupported" m= utability - makes things a bit more clear
=C2=A0

_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
= +1 202 255 3166
--089e0149360859a54f0503ae0593-- From nobody Mon Sep 22 15:19:07 2014 Return-Path: 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 0AE0C1A1AAD for ; Mon, 22 Sep 2014 15:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 B9YeSAQL_D5b for ; Mon, 22 Sep 2014 15:19:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258931A1AA1 for ; Mon, 22 Sep 2014 15:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11240; q=dns/txt; s=iport; t=1411424341; x=1412633941; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=g7I7DMZYpqvUgTGkyTaws06eKQlDz1U+MFPRJLd1+9Q=; b=ka1Wi6zAZfNthGmEzBlVc8vD07myNiAeE/jphq6WcJU2TqC1rsb8NkEJ I+FctZouwrgwegzx9+bhrCqSZ8PWAzwvFVFQdwoflpUAZzhTtDQ4QH4Dl BkWA8Oe5jjpZrfwKVD63ErVTpFXtGL0yMNQFgvPGrLK8L2K9OAzp0g1d/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKqfIFStJV2d/2dsb2JhbABXBgOCSEZTVwTKRwEJh00BgRQWAXqEAwEBAQQBAQFGJQsQAgEIDgMDAQIoBycLFAkIAgQBDQWIPg3FNgEXihuFEEoBDAQHCQiEOgWRV4Q4hweVUoNhbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,574,1406592000"; d="scan'208,217";a="357322121" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 22 Sep 2014 22:19:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8MMIxKX023704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 22:18:59 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 17:18:59 -0500 From: "Morteza Ansari (moransar)" To: Ian Glazer , Phil Hunt Thread-Topic: [scim] Questions about defined vs. supported schema Thread-Index: AQHP1oyv1U9tSyV4mkeGKwNw44XFtJwN/LUA//+bEYA= Date: Mon, 22 Sep 2014 22:18:58 +0000 Message-ID: References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.78.186] Content-Type: multipart/alternative; boundary="_000_D045EDA0FC2FCmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/v1uF5QpXDkpPOf6b_S_0PBexuS8 Cc: SCIM WG Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:19:03 -0000 --_000_D045EDA0FC2FCmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an implementer: our current implementation is doing 3B. 2 is c= ertainly an option, but I like the idea of unsupported mutability the best.= The question is what is the semantics if a server defines =93photos=94 as = unsupported, but gets a put request with it? Does it ignore the value or r= eturn a schema error? I see pro/cons for both. Cheers, Morteza From: Ian Glazer > Date: Monday, September 22, 2014 at 2:20 PM To: Phil Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Questions about defined vs. supported schema On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt > wrote: I received a question from an implementer about how to indicate non-support= ed attributes that are defined in core-schema. For example, a service provider doesn=92t want to use =93photos=94 as defin= ed in the core schemas. Should it: 1. Do nothing. Just accept the values and then ignore them. 2. In schemas, mark the attribute as =93readOnly=94 and then ignore them. = (this is acceptable in the current rules) 3. Remove the attribute from Schemas. If it then receives a value should = it: a. Ignore the value b. Return a schema error. In general, should we be silently ignoring attributes that are included in = a JSON payload (e.g. on POST) that are not part of the schema? Or, should = the server throw an error? With my editor hat off, my personal reaction is that servers should be flex= ible in what they accept and feel free to pick and choose data with appropr= iate DoS considerations. I have a tendency to think that a server can simpl= y ignore data it does not understand or care about. Further the server is = free to alter any values it does accept as long as it returns the new value= s in its response. That said, when we are talking about standard schema, it may be useful to d= o 2 above which tells a client admin why a server may not be appearing to a= ccept an attribute value. We may actually want to have a mutability of =93= unsupported=94 which simply means the server will ignore it entirely and wi= ll never return a value. This is a bit better than =93readOnly=94 which sa= ys the server may set the value but the client may not. Doing 2 seems like a workable hack but a hack nonetheless. I like the idea = of an "unsupported" mutability - makes things a bit more clear Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D045EDA0FC2FCmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Speaking as an implementer: our current implementation is doing 3B. &n= bsp;2 is certainly an option, but I like the idea of unsupported mutability= the best. The question is what is the semantics if a server defines =93pho= tos=94 as unsupported, but gets a put request with it?  Does it ignore the value or return a schema error?  I = see pro/cons for both.


Cheers,
Morteza

From: Ian Glazer <iglazer@salesforce.com>
Date: Monday, September 22, 2014 at= 2:20 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] Questions about= defined vs. supported schema



On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt <phil.hunt@ora= cle.com> wrote:
I received a question from an implement= er about how to indicate non-supported attributes that are defined in core-= schema.

For example, a service provider doesn=92t want to use =93photos=94 as = defined in the core schemas. 

Should it:

1.  Do nothing.  Just accept the values and then ignore them= .

2.  In schemas, mark the attribute as =93readOnly=94 and then ign= ore them. (this is acceptable in the current rules)

3.  Remove the attribute from Schemas.  If it then receives = a value should it:
a. Ignore the value
b. Return a schema error.

In general, should we be silently ignoring attributes that are include= d in a JSON payload (e.g. on POST) that are not part of the schema?  O= r, should the server throw an error?

With my editor hat off, my personal reaction is that servers should be= flexible in what they accept and feel free to pick and choose data with ap= propriate DoS considerations. I have a tendency to think that a server can = simply ignore data it does not understand or care about.  Further the server is free to alter any values it doe= s accept as long as it returns the new values in its response.

That said, when we are talking about standard schema, it may be useful= to do 2 above which tells a client admin why a server may not be appearing= to accept an attribute value.  We may actually want to have a mutabil= ity of =93unsupported=94 which simply means the server will ignore it entirely and will never return a value.  Th= is is a bit better than =93readOnly=94 which says the server may set the va= lue but the client may not.

Doing 2 seems like a workable hack but a hack nonetheless. I like the = idea of an "unsupported" mutability - makes things a bit more cle= ar
 

_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
 --_000_D045EDA0FC2FCmoransarciscocom_-- From nobody Mon Sep 22 15:34:16 2014 Return-Path: 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 644F91A6F15 for ; Mon, 22 Sep 2014 15:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ZAGpdfr7fvZ1 for ; Mon, 22 Sep 2014 15:34:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D861A6F14 for ; Mon, 22 Sep 2014 15:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3313; q=dns/txt; s=iport; t=1411425253; x=1412634853; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RbGtSqnnTchCK9dLCyqokQ6rebzY3k8K+fz2DPQh11o=; b=Bj7zYOWreYZuEHo34K0rn4EtkD96TLr95b618QKmsqySgoalPukshLDW zPiGUj8aqcoyaVMbabZp1BVOg+RCyrX8w3TPr4v+08GT1VBHs+JduOZje 4eH8W3HRoM9WqetSGlfAGqbCht5u3JrBeqt+OXFeaIygbgFKZFGIJI6nX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAC+jIFStJA2G/2dsb2JhbABggw5TVwTKRwqHTQGBFRYBeoQEAQEEAQEBNzQLEAIBCA4KHhAhBgslAgQBDQWIKgMRDb4HDYcsAReNV4FYVweESwWRV4kvghCPDYZFg2FsgQdBgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,574,1406592000"; d="scan'208";a="80274666" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 22 Sep 2014 22:34:13 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8MMYDMj012931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 22:34:13 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 17:34:12 -0500 From: "Morteza Ansari (moransar)" To: Chuck Mortimore , Grahame Grieve Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgA== Date: Mon, 22 Sep 2014 22:34:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.78.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <228F55AE18FDB442868729E08DB19D81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/iTxxxxcrcZBQSw-yzOVK4dOG_2k Cc: "scim@ietf.org" Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:34:15 -0000 As far as I can tell nobody brought up any use cases for adding support for multi-valued or complex externalID. I take that as consensus to clarify the spec and stating this is a single valued attribute and move forward. If anyone objects to this, please speak up now. Cheers, Morteza On 9/11/14, 7:53 AM, "Chuck Mortimore" wrote: >externalid is there to provide a surrogate primary key for the scim >entity so it can be more easily addressed by scim consumers or federation >services.=20 > >For example, if you are trying to provide single sign-on to a cloud >service, it is often more convenient for the IDP to use its local >identifier for the user, rather than to update its schema and store the >identifier used by the cloud service. So - it(or the provisions service >it is paired with) would use scim to set its primary id for the user as >externalid and send that as the subject of a SAML assertion. > >- cmort > >> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >> wrote: >>=20 >> it's not clear what externalId is for. In a distributed system, it's >> not unlikely that there will be multiple relevant other identifiers - >> is there some notion of which is primary? For instance, I need to map >> between the User resource in the SCIM interface, and a Patient record >> in a different interface, so that the security engine knows that this >> user is the same as this patient. Should that be externalId, or should >> it be somewhere else (an extension?). I didn't think that the >> definition of external id was quite clear enough to be sure. But if I >> said to use externalId for that, what happens to other uses of >> externalId - same user on a different user record? (which is why I >> think I shouldn't use externalId for that) >>=20 >> Earlier in the thread, someone said that multiple identifiers might >> leak between different clients. Well, you might want them to share the >> multiple identifiers, but limiting identifier to one doesn't solve the >> leakage problem - so I don't think it's a reason to limit it to one. >>=20 >> Still, multiple identifiers are always a problem - how do you tell >> them apart? Actually, I looked for a set of links that identified >> related records to the user - e,g, href=3D + rel=3D. I would prefer this >> over the existing approach >>=20 >> Grahame >>=20 >>=20 >> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >> wrote: >>> I would like to ask anyone that have real use cases for multi-valued or >>> typed/complex externalID to bring them to the WG. I think it would >>>greatly >>> help better define this and make a decision on whether we need to >>>extend the >>> current definition or just clarify it. >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> --=20 >> ----- >> http://www.healthintersections.com.au / >> grahame@healthintersections.com.au / +61 411 867 065 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 22 15:48:35 2014 Return-Path: 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 8174E1A6F39 for ; Mon, 22 Sep 2014 15:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 Qt2peSeLIL_2 for ; Mon, 22 Sep 2014 15:48:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4EF1A6F33 for ; Mon, 22 Sep 2014 15:48:32 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8MMmQXc013048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Sep 2014 22:48:26 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8MMmPUs006873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2014 22:48:26 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8MMmPJ1002337; Mon, 22 Sep 2014 22:48:25 GMT Received: from [192.168.1.8] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Sep 2014 15:48:24 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <075EE1B3-715D-4953-8132-C038CCDECE1D@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 22 Sep 2014 15:48:16 -0700 To: "Morteza Ansari (moransar)" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4iJPMnr5GAj_1wY-keEDXw9Qq3o Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:48:33 -0000 If it is single valued, which client may set the value? How is it bound? Phil > On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)" wrote: >=20 > As far as I can tell nobody brought up any use cases for adding support > for multi-valued or complex externalID. I take that as consensus to > clarify the spec and stating this is a single valued attribute and move > forward. If anyone objects to this, please speak up now. >=20 >=20 > Cheers, > Morteza >=20 >> On 9/11/14, 7:53 AM, "Chuck Mortimore" wrote= : >>=20 >> externalid is there to provide a surrogate primary key for the scim >> entity so it can be more easily addressed by scim consumers or federation= >> services.=20 >>=20 >> For example, if you are trying to provide single sign-on to a cloud >> service, it is often more convenient for the IDP to use its local >> identifier for the user, rather than to update its schema and store the >> identifier used by the cloud service. So - it(or the provisions service= >> it is paired with) would use scim to set its primary id for the user as >> externalid and send that as the subject of a SAML assertion. >>=20 >> - cmort >>=20 >>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>> wrote: >>>=20 >>> it's not clear what externalId is for. In a distributed system, it's >>> not unlikely that there will be multiple relevant other identifiers - >>> is there some notion of which is primary? For instance, I need to map >>> between the User resource in the SCIM interface, and a Patient record >>> in a different interface, so that the security engine knows that this >>> user is the same as this patient. Should that be externalId, or should >>> it be somewhere else (an extension?). I didn't think that the >>> definition of external id was quite clear enough to be sure. But if I >>> said to use externalId for that, what happens to other uses of >>> externalId - same user on a different user record? (which is why I >>> think I shouldn't use externalId for that) >>>=20 >>> Earlier in the thread, someone said that multiple identifiers might >>> leak between different clients. Well, you might want them to share the >>> multiple identifiers, but limiting identifier to one doesn't solve the >>> leakage problem - so I don't think it's a reason to limit it to one. >>>=20 >>> Still, multiple identifiers are always a problem - how do you tell >>> them apart? Actually, I looked for a set of links that identified >>> related records to the user - e,g, href=3D + rel=3D. I would prefer this= >>> over the existing approach >>>=20 >>> Grahame >>>=20 >>>=20 >>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>> wrote: >>>> I would like to ask anyone that have real use cases for multi-valued or= >>>> typed/complex externalID to bring them to the WG. I think it would >>>> greatly >>>> help better define this and make a decision on whether we need to >>>> extend the >>>> current definition or just clarify it. >>>>=20 >>>>=20 >>>> Cheers, >>>> Morteza >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >>>=20 >>> --=20 >>> ----- >>> http://www.healthintersections.com.au / >>> grahame@healthintersections.com.au / +61 411 867 065 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 22 15:56:26 2014 Return-Path: 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 32A171A1B31 for ; Mon, 22 Sep 2014 15:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kguevqV1lUGQ for ; Mon, 22 Sep 2014 15:56:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493251A1B10 for ; Mon, 22 Sep 2014 15:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4150; q=dns/txt; s=iport; t=1411426584; x=1412636184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=58yiCROOjDFFUDmvxgo/9X9npReWMC5lSNdlF8V7Kpw=; b=D3HZNcXCW5i275+MtYaPl37Tgxy1akxz9ayHDk9o7WA9R3v6u6dGepsj REg85ME1f1qMC2sIVJgaPc6RJTBqpmDlY9eedb4A+MfaGA47YiWfiJWT3 8W4hW4s08xxxANSSs147Zg4Xm2e42HutB0V+B0R8c5WO+eQjhPO/6oCV7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFABioIFStJV2c/2dsb2JhbABggw5TVwTKSAqHTQGBERYBeoQEAQEEAQEBNzQLEAIBCBgeECEGCyUCBA4FiCoDEQ29fw2HLAEXjVeBWCQzB4RLBZFXiS+CEI8NhkWDYWyBB0GBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,575,1406592000"; d="scan'208";a="357110702" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 Sep 2014 22:56:23 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8MMuMLE030185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 22:56:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 17:56:22 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAeUkA//+M6AA= Date: Mon, 22 Sep 2014 22:56:22 +0000 Message-ID: References: <075EE1B3-715D-4953-8132-C038CCDECE1D@oracle.com> In-Reply-To: <075EE1B3-715D-4953-8132-C038CCDECE1D@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.78.186] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1bihd6qTl1qgou9_-VYyBPVzqTE Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:56:25 -0000 Any client that is authorized to modify the value. Not sure what you mean by bound. No attribute is bound to a specific client, this is no different (given lack of new use cases). Cheers, Morteza On 9/22/14, 3:48 PM, "Phil Hunt" wrote: >If it is single valued, which client may set the value? > >How is it bound? > >Phil > >> On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)" >> wrote: >>=20 >> As far as I can tell nobody brought up any use cases for adding support >> for multi-valued or complex externalID. I take that as consensus to >> clarify the spec and stating this is a single valued attribute and move >> forward. If anyone objects to this, please speak up now. >>=20 >>=20 >> Cheers, >> Morteza >>=20 >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" >>>wrote: >>>=20 >>> externalid is there to provide a surrogate primary key for the scim >>> entity so it can be more easily addressed by scim consumers or >>>federation >>> services.=20 >>>=20 >>> For example, if you are trying to provide single sign-on to a cloud >>> service, it is often more convenient for the IDP to use its local >>> identifier for the user, rather than to update its schema and store the >>> identifier used by the cloud service. So - it(or the provisions >>>service >>> it is paired with) would use scim to set its primary id for the user as >>> externalid and send that as the subject of a SAML assertion. >>>=20 >>> - cmort >>>=20 >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>>> wrote: >>>>=20 >>>> it's not clear what externalId is for. In a distributed system, it's >>>> not unlikely that there will be multiple relevant other identifiers - >>>> is there some notion of which is primary? For instance, I need to map >>>> between the User resource in the SCIM interface, and a Patient record >>>> in a different interface, so that the security engine knows that this >>>> user is the same as this patient. Should that be externalId, or should >>>> it be somewhere else (an extension?). I didn't think that the >>>> definition of external id was quite clear enough to be sure. But if I >>>> said to use externalId for that, what happens to other uses of >>>> externalId - same user on a different user record? (which is why I >>>> think I shouldn't use externalId for that) >>>>=20 >>>> Earlier in the thread, someone said that multiple identifiers might >>>> leak between different clients. Well, you might want them to share the >>>> multiple identifiers, but limiting identifier to one doesn't solve the >>>> leakage problem - so I don't think it's a reason to limit it to one. >>>>=20 >>>> Still, multiple identifiers are always a problem - how do you tell >>>> them apart? Actually, I looked for a set of links that identified >>>> related records to the user - e,g, href=3D + rel=3D. I would prefer th= is >>>> over the existing approach >>>>=20 >>>> Grahame >>>>=20 >>>>=20 >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>>> wrote: >>>>> I would like to ask anyone that have real use cases for multi-valued >>>>>or >>>>> typed/complex externalID to bring them to the WG. I think it would >>>>> greatly >>>>> help better define this and make a decision on whether we need to >>>>> extend the >>>>> current definition or just clarify it. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Morteza >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> ----- >>>> http://www.healthintersections.com.au / >>>> grahame@healthintersections.com.au / +61 411 867 065 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 22 16:36:18 2014 Return-Path: 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 0CF591A6F66 for ; Mon, 22 Sep 2014 16:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 TNmvrdubQNQM for ; Mon, 22 Sep 2014 16:36:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9091A6F53 for ; Mon, 22 Sep 2014 16:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3852; q=dns/txt; s=iport; t=1411428976; x=1412638576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RCDyWhW6A7Od/0yQa57lAMwzdRNnfMxiCH0undnoJmE=; b=bbjnfhVHXuO9g/opX/UE0SRDldXafWnFa++JCjZLNH6fykSWPYo7uk4/ cdzQvAjXj+J/Dv9GZc/TBEEZ5fA+zdlRWakXeDuxMWGyFsV9IsgaCeYOM yKYBP0dgSGG4w6Z8vZREcQ4JtewAkXP5KzwTWXlWgR5/dMCMbdVQFZiiu Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAD+xIFStJV2U/2dsb2JhbABggw5TVwTKSgqHTQGBExYBeoQEAQEEAQEBNzQLEAIBCBgeECEGCyUCBA4FiCoDEQ2+EQ2HLAEXjVeBWCQzB4RLBZFXiS+CEI8NhkWDYWyBB0GBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,575,1406592000"; d="scan'208";a="357289888" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 22 Sep 2014 23:36:15 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8MNaEf1011750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 23:36:14 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 18:36:14 -0500 From: "Morteza Ansari (moransar)" To: Grahame Grieve Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4A= Date: Mon, 22 Sep 2014 23:36:14 +0000 Message-ID: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> In-Reply-To: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.78.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D724EB0C97B074A84858A58EC3F13E4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/C-Afu78RHmPreWrdA4i5z-NJnRc Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:36:17 -0000 Can you please expand? On 9/22/14, 4:33 PM, "Grahame Grieve" wrote: >No, not for a complex external id, but I would like to have a set of >links for the user. > >Grahame > >> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)" >> wrote: >>=20 >> As far as I can tell nobody brought up any use cases for adding support >> for multi-valued or complex externalID. I take that as consensus to >> clarify the spec and stating this is a single valued attribute and move >> forward. If anyone objects to this, please speak up now. >>=20 >>=20 >> Cheers, >> Morteza >>=20 >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" >>>wrote: >>>=20 >>> externalid is there to provide a surrogate primary key for the scim >>> entity so it can be more easily addressed by scim consumers or >>>federation >>> services.=20 >>>=20 >>> For example, if you are trying to provide single sign-on to a cloud >>> service, it is often more convenient for the IDP to use its local >>> identifier for the user, rather than to update its schema and store the >>> identifier used by the cloud service. So - it(or the provisions >>>service >>> it is paired with) would use scim to set its primary id for the user as >>> externalid and send that as the subject of a SAML assertion. >>>=20 >>> - cmort >>>=20 >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>>> wrote: >>>>=20 >>>> it's not clear what externalId is for. In a distributed system, it's >>>> not unlikely that there will be multiple relevant other identifiers - >>>> is there some notion of which is primary? For instance, I need to map >>>> between the User resource in the SCIM interface, and a Patient record >>>> in a different interface, so that the security engine knows that this >>>> user is the same as this patient. Should that be externalId, or should >>>> it be somewhere else (an extension?). I didn't think that the >>>> definition of external id was quite clear enough to be sure. But if I >>>> said to use externalId for that, what happens to other uses of >>>> externalId - same user on a different user record? (which is why I >>>> think I shouldn't use externalId for that) >>>>=20 >>>> Earlier in the thread, someone said that multiple identifiers might >>>> leak between different clients. Well, you might want them to share the >>>> multiple identifiers, but limiting identifier to one doesn't solve the >>>> leakage problem - so I don't think it's a reason to limit it to one. >>>>=20 >>>> Still, multiple identifiers are always a problem - how do you tell >>>> them apart? Actually, I looked for a set of links that identified >>>> related records to the user - e,g, href=3D + rel=3D. I would prefer th= is >>>> over the existing approach >>>>=20 >>>> Grahame >>>>=20 >>>>=20 >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>>> wrote: >>>>> I would like to ask anyone that have real use cases for multi-valued >>>>>or >>>>> typed/complex externalID to bring them to the WG. I think it would >>>>> greatly >>>>> help better define this and make a decision on whether we need to >>>>> extend the >>>>> current definition or just clarify it. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Morteza >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> ----- >>>> http://www.healthintersections.com.au / >>>> grahame@healthintersections.com.au / +61 411 867 065 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>=20 From nobody Mon Sep 22 16:58:32 2014 Return-Path: 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 6F8301A1ACD for ; Mon, 22 Sep 2014 16:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 1aQXaZvMQndc for ; Mon, 22 Sep 2014 16:58:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EB71A02C0 for ; Mon, 22 Sep 2014 16:58:25 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8MNwJGu025925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Sep 2014 23:58:20 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8MNwIOA007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2014 23:58:19 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8MNwHF3007329; Mon, 22 Sep 2014 23:58:18 GMT Received: from [192.168.1.133] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Sep 2014 16:58:17 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5546603-E8ED-4038-A260-2ACEC020B3CF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 22 Sep 2014 16:58:13 -0700 Message-Id: References: <075EE1B3-715D-4953-8132-C038CCDECE1D@oracle.com> To: Morteza Ansari X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/9S0SRRIu6xet2OZYANmCb1FIngo Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:58:28 -0000 --Apple-Mail=_D5546603-E8ED-4038-A260-2ACEC020B3CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think I=92m being a bit pedantic too, but I=92m just anticipating = questions down the road here.=20 =46rom the spec... externalId A String that is an identifier for the resource as defined by the client. The "externalId" may simplify identification of the resource between client and service provider by allowing the client to use a filter to locate the resource with its own identifier, obviating the need to store a local mapping between the local identifier of the resource and the identifier used by the service provider. Each resource MAY include a non-empty "externalId" value. The value of the "externalId" attribute is always issued by the client and MUST NOT be specified by the service provider. The service provider MUST always interpret the externalId as scoped to the client's tenant. While the server does not enforce uniqueness, it is assumed that the value's uniqueness is controlled by the client setting the value. See Section 9 for additional considerations regarding privacy. The text that gives me concern is: The value of the "externalId" attribute is always issued by the client and MUST NOT be specified by the service provider. The service provider MUST always interpret the externalId as scoped to the client's tenant. The problem I=92m having is that externalId is single-valued and bound = to the tenant. This simple requirement has a wide amount of = interpretation and methods for implementation. I=92m worried about a lot = of incompatibilities emerging here. What happens if multiple security domains (remember SCIM is = cross-domain) are referencing the same user resource? Are they each = allowed to have a single-value? Thus the server is required to = virtualize the fact that there is only a single value but will have to = maintain multiple externalId instances based on domain/tenancy whatever? This definition has implied virtualization and security characteristics = that no other attribute type has. Are we really wanting to do something = special here? Are we saying that there can be access control and that = for any particular attribute, the server may accept or decline values = (in which case should it ignore or throw an error). Other options: 1. Multi-valued plus typing - any client can do what ever they want = technically. In practice we set type value to someting that indicates a = domain or format. 2. Single-valued immutable - first client to set the value wins. This = is not helpful to second, or third to the table clients who also want to = assign an externalId 3. Create a new data type/access control definition that allows = specific values to be assigned to clients. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 22, 2014, at 3:56 PM, Morteza Ansari (moransar) = wrote: > Any client that is authorized to modify the value. Not sure what you = mean > by bound. No attribute is bound to a specific client, this is no > different (given lack of new use cases). >=20 >=20 > Cheers, > Morteza >=20 > On 9/22/14, 3:48 PM, "Phil Hunt" wrote: >=20 >> If it is single valued, which client may set the value? >>=20 >> How is it bound? >>=20 >> Phil >>=20 >>> On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)" >>> wrote: >>>=20 >>> As far as I can tell nobody brought up any use cases for adding = support >>> for multi-valued or complex externalID. I take that as consensus to >>> clarify the spec and stating this is a single valued attribute and = move >>> forward. If anyone objects to this, please speak up now. >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" >>>> wrote: >>>>=20 >>>> externalid is there to provide a surrogate primary key for the scim >>>> entity so it can be more easily addressed by scim consumers or >>>> federation >>>> services.=20 >>>>=20 >>>> For example, if you are trying to provide single sign-on to a cloud >>>> service, it is often more convenient for the IDP to use its local >>>> identifier for the user, rather than to update its schema and store = the >>>> identifier used by the cloud service. So - it(or the provisions >>>> service >>>> it is paired with) would use scim to set its primary id for the = user as >>>> externalid and send that as the subject of a SAML assertion. >>>>=20 >>>> - cmort >>>>=20 >>>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>>>> wrote: >>>>>=20 >>>>> it's not clear what externalId is for. In a distributed system, = it's >>>>> not unlikely that there will be multiple relevant other = identifiers - >>>>> is there some notion of which is primary? For instance, I need to = map >>>>> between the User resource in the SCIM interface, and a Patient = record >>>>> in a different interface, so that the security engine knows that = this >>>>> user is the same as this patient. Should that be externalId, or = should >>>>> it be somewhere else (an extension?). I didn't think that the >>>>> definition of external id was quite clear enough to be sure. But = if I >>>>> said to use externalId for that, what happens to other uses of >>>>> externalId - same user on a different user record? (which is why I >>>>> think I shouldn't use externalId for that) >>>>>=20 >>>>> Earlier in the thread, someone said that multiple identifiers = might >>>>> leak between different clients. Well, you might want them to share = the >>>>> multiple identifiers, but limiting identifier to one doesn't solve = the >>>>> leakage problem - so I don't think it's a reason to limit it to = one. >>>>>=20 >>>>> Still, multiple identifiers are always a problem - how do you tell >>>>> them apart? Actually, I looked for a set of links that identified >>>>> related records to the user - e,g, href=3D + rel=3D. I would = prefer this >>>>> over the existing approach >>>>>=20 >>>>> Grahame >>>>>=20 >>>>>=20 >>>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>>>> wrote: >>>>>> I would like to ask anyone that have real use cases for = multi-valued >>>>>> or >>>>>> typed/complex externalID to bring them to the WG. I think it = would >>>>>> greatly >>>>>> help better define this and make a decision on whether we need to >>>>>> extend the >>>>>> current definition or just clarify it. >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>> Morteza >>>>>>=20 >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> ----- >>>>> http://www.healthintersections.com.au / >>>>> grahame@healthintersections.com.au / +61 411 867 065 >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_D5546603-E8ED-4038-A260-2ACEC020B3CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I think I=92m being a bit = pedantic too, but I=92m just anticipating questions down the road = here. 

=46rom the = spec...

externalId
    =   A String that is an identifier for the resource as defined by = the
      client.  The "externalId" may = simplify identification of the
      resource = between client and service provider by allowing the
  =     client to use a filter to locate the resource with its = own
      identifier, obviating the need to = store a local mapping between
      the local = identifier of the resource and the identifier used by
  =     the service provider.  Each resource MAY include a = non-empty
      "externalId" value. =  The value of the "externalId" attribute = is
      always issued by the client and = MUST NOT be specified by the
      = service provider.  The service provider MUST always interpret = the
      externalId as scoped to the = client's tenant.  While the server
    =   does not enforce uniqueness, it is assumed that the = value's
      uniqueness is controlled by the = client setting the value.  See
      = Section 9 for additional considerations regarding = privacy.

The = text that gives me concern is:
     The value = of the "externalId" attribute is
      always issued = by the client and MUST NOT be specified by the
      = service provider.  The service provider MUST always interpret = the
      externalId as scoped to the client's = tenant.

The = problem I=92m having is that externalId is single-valued and bound to = the tenant. This simple requirement has a wide amount of interpretation = and methods for implementation. I=92m worried about a lot of = incompatibilities emerging here.

What happens = if multiple security domains (remember SCIM is cross-domain) are = referencing the same user resource? Are they each allowed to have a = single-value?  Thus the server is required to virtualize the fact = that there is only a single value but will have to maintain multiple = externalId instances based on domain/tenancy = whatever?

This definition has implied = virtualization and security characteristics that no other attribute type = has.  Are we really wanting to do something special here? Are we = saying that there can be access control and that for any particular = attribute, the server may accept or decline values (in which case should = it ignore or throw an error).

Other = options:
1.  Multi-valued plus typing - any client can do = what ever they want technically. In practice we set type value to = someting that indicates a domain or format.
2. =  Single-valued immutable - first client to set the value wins. =  This is not helpful to second, or third to the table clients who = also want to assign an externalId
3.  Create a new data = type/access control definition that allows specific values to be = assigned to = clients.

Phil

@independentid
www.independentid.com
phil.hu= nt@oracle.com



On Sep 22, 2014, at 3:56 PM, Morteza = Ansari (moransar) <moransar@cisco.com> = wrote:

Any client that is authorized to = modify the value.  Not sure what you mean
by bound.  No = attribute is bound to a specific client, this is no
different (given = lack of new use cases).


Cheers,
Morteza

On 9/22/14, = 3:48 PM, "Phil Hunt" <phil.hunt@oracle.com> = wrote:

If it is single valued, which = client may set the value?

How is it = bound?

Phil

On Sep 22, 2014, at = 15:34, "Morteza Ansari (moransar)"
<moransar@cisco.com> = wrote:

As far as I can tell nobody brought up any use cases for = adding support
for multi-valued or complex externalID.  I take = that as consensus to
clarify the spec and stating this is a single = valued attribute and move
forward.  If anyone objects to this, = please speak up now.


Cheers,
Morteza

On 9/11/14, 7:53 AM, "Chuck Mortimore" <charliemortimore@gmail.com&= gt;
wrote:

externalid is there to provide a surrogate primary = key for the scim
entity so it can be more easily addressed by scim = consumers or
federation
services. 

For example, if you = are trying to provide single sign-on to a cloud
service, it is often = more convenient for the IDP to use its local
identifier for the user, = rather than to update its schema and store the
identifier used by the = cloud service.   So - it(or the provisions
service
it is = paired with) would use scim to set its primary id for the user = as
externalid and send that as the subject of a SAML = assertion.

- cmort

On Sep 10, = 2014, at 10:58 PM, Grahame Grieve
<grahame@healthintersect= ions.com.au> wrote:

it's not clear what externalId is for. = In a distributed system, it's
not unlikely that there will be = multiple relevant other identifiers -
is there some notion of which = is primary? For instance, I need to map
between the User resource in = the SCIM interface, and a Patient record
in a different interface, so = that the security engine knows that this
user is the same as this = patient. Should that be externalId, or should
it be somewhere else = (an extension?). I didn't think that the
definition of external id = was quite clear enough to be sure. But if I
said to use externalId = for that, what happens to other uses of
externalId - same user on a = different user record? (which is why I
think I shouldn't use = externalId for that)

Earlier in the thread, someone said that = multiple identifiers might
leak between different clients. Well, you = might want them to share the
multiple identifiers, but limiting = identifier to one doesn't solve the
leakage problem - so I don't = think it's a reason to limit it to one.

Still, multiple = identifiers are always a problem - how do you tell
them apart? = Actually, I looked for a set of links that identified
related records = to the user - e,g, href=3D + rel=3D. I would prefer this
over the = existing approach

Grahame


On Thu, Sep 11, 2014 at 9:45 = AM, Morteza Ansari (moransar)
<moransar@cisco.com> = wrote:
I would like to ask anyone that have = real use cases for multi-valued
or
typed/complex externalID to = bring them to the WG.  I think it would
greatly
help better = define this and make a decision on whether we need to
extend = the
current definition or just clarify = it.


Cheers,
Morteza

_________________________________= ______________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim



-- 
-----
http://www.healthintersecti= ons.com.au /
grahame@healthintersect= ions.com.au / +61 411 867 = 065

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

_____________________= __________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

_____________________= __________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_D5546603-E8ED-4038-A260-2ACEC020B3CF-- From nobody Mon Sep 22 18:08:56 2014 Return-Path: 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 161FB1A039D for ; Mon, 22 Sep 2014 18:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no 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 d9jeZffzpRxJ for ; Mon, 22 Sep 2014 18:08:52 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AB11A6F6D for ; Mon, 22 Sep 2014 18:08:51 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id z2so4081718wiv.17 for ; Mon, 22 Sep 2014 18:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Se/J1och+9QCyoyJ+4lo612/92kUK+tXnMOax40+IRM=; b=Mpi8IYpkihP0Bayu2drICKS8gwBskpZKiysIN5I7HGvXoh+uV3Yy2816QK7QOBzpuq AWiyM4gPaMn8g7h81ISO8gMr64M6e0LxfnRBEfr9a9uPF4XszMt9ewTuMNWY9YLdjAbc e8UrMQ2cleV0ARQq3eKY1uOAHW3BhjOT4YnDyvMp/09F4Rzpx39brGX+qpSlVa0g9poB cd32StV5zLkVqTdWOPdengTIsseIkTJUkDXTIXi0RuhBuYjIXpXl5e59Lz73PxD6KwfJ sXWqYjOB3IknV7tVNM6x6GGUmGbhQ6hyKNMkRt+Kwtt7C4vrLyQanmKYlqddIcELySMo OqLw== MIME-Version: 1.0 X-Received: by 10.194.79.35 with SMTP id g3mr4712wjx.110.1411434530011; Mon, 22 Sep 2014 18:08:50 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.77.199 with HTTP; Mon, 22 Sep 2014 18:08:49 -0700 (PDT) In-Reply-To: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> Date: Tue, 23 Sep 2014 11:08:49 +1000 X-Google-Sender-Auth: dWbw38xWW4mt3zFbMRzSVdH4hl4 Message-ID: From: Grahame Grieve To: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary=047d7bf0c59ac901fb0503b13538 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/h2ZcbHi3_n0XJTZUjpmRaos7jvs Cc: "scim@ietf.org" , Chuck Mortimore Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 01:08:54 -0000 --047d7bf0c59ac901fb0503b13538 Content-Type: text/plain; charset=UTF-8 ...from the right email this time... Sure, I can expand. A couple of points: Most uses of scim will use the user/group in the context of some wider set of functionality. Either they can extend the scim user - a long way - or they can link the user to their other context. For instance, in the context of health, for which I am writing what will be a widely used spec, the user will correspond to either a patient or a healthcare provider (or perhaps both, though most systems keep them far apart even when they're the same person). How is this link to be established? It could either be from the scim user to the extarnal resource, or to the other way around, or both. I'm thinking about which would be better, but if it's from the user to the external resource: - it could be by reusing the external id. But the external id as described by the spec and /or Phil's comments is not suitable for this use, and it has other uses - it could be by putting extensions into the resource. Perhaps this is the intent, though I'm not sure why extarnalId is very different - it could done be adding a link property that has rel-type and href. I'd use related, but there's a bunch of interesting ones here: http://www.iana.org/assignments/link-relations/link-relations.xhtml. That's the second - these links are used for hateos. I suppose that you could confine them to the http header (in fact, we could use it that way in my context too), but there's kind of a difference between workflow uses and uses related to meaning - that's why HTML pages can include links in the page itself, not just in the headers,,and why I think it would be a good idea to add them to the resource itself.mpossibly in the meta element A couple of further comments: - I'm still thinking about how the link should be made, and if the spec already answers think I missed it. But I think it will be a common use case. - I'm also interested in the by-play between links on the http headers, and links in the resource as well. Is this as good an idea as I made it sound? Grahame On Tuesday, September 23, 2014, Morteza Ansari (moransar) < moransar@cisco.com> wrote: > Can you please expand? > > > > On 9/22/14, 4:33 PM, "Grahame Grieve" > > wrote: > > >No, not for a complex external id, but I would like to have a set of > >links for the user. > > > >Grahame > > > >> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)" > >>> wrote: > >> > >> As far as I can tell nobody brought up any use cases for adding support > >> for multi-valued or complex externalID. I take that as consensus to > >> clarify the spec and stating this is a single valued attribute and move > >> forward. If anyone objects to this, please speak up now. > >> > >> > >> Cheers, > >> Morteza > >> > >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" > > >>>wrote: > >>> > >>> externalid is there to provide a surrogate primary key for the scim > >>> entity so it can be more easily addressed by scim consumers or > >>>federation > >>> services. > >>> > >>> For example, if you are trying to provide single sign-on to a cloud > >>> service, it is often more convenient for the IDP to use its local > >>> identifier for the user, rather than to update its schema and store the > >>> identifier used by the cloud service. So - it(or the provisions > >>>service > >>> it is paired with) would use scim to set its primary id for the user as > >>> externalid and send that as the subject of a SAML assertion. > >>> > >>> - cmort > >>> > >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve > >>>> > wrote: > >>>> > >>>> it's not clear what externalId is for. In a distributed system, it's > >>>> not unlikely that there will be multiple relevant other identifiers - > >>>> is there some notion of which is primary? For instance, I need to map > >>>> between the User resource in the SCIM interface, and a Patient record > >>>> in a different interface, so that the security engine knows that this > >>>> user is the same as this patient. Should that be externalId, or should > >>>> it be somewhere else (an extension?). I didn't think that the > >>>> definition of external id was quite clear enough to be sure. But if I > >>>> said to use externalId for that, what happens to other uses of > >>>> externalId - same user on a different user record? (which is why I > >>>> think I shouldn't use externalId for that) > >>>> > >>>> Earlier in the thread, someone said that multiple identifiers might > >>>> leak between different clients. Well, you might want them to share the > >>>> multiple identifiers, but limiting identifier to one doesn't solve the > >>>> leakage problem - so I don't think it's a reason to limit it to one. > >>>> > >>>> Still, multiple identifiers are always a problem - how do you tell > >>>> them apart? Actually, I looked for a set of links that identified > >>>> related records to the user - e,g, href= + rel=. I would prefer this > >>>> over the existing approach > >>>> > >>>> Grahame > >>>> > >>>> > >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) > >>>> > wrote: > >>>>> I would like to ask anyone that have real use cases for multi-valued > >>>>>or > >>>>> typed/complex externalID to bring them to the WG. I think it would > >>>>> greatly > >>>>> help better define this and make a decision on whether we need to > >>>>> extend the > >>>>> current definition or just clarify it. > >>>>> > >>>>> > >>>>> Cheers, > >>>>> Morteza > >>>>> > >>>>> _______________________________________________ > >>>>> scim mailing list > >>>>> scim@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/scim > >>>> > >>>> > >>>> > >>>> -- > >>>> ----- > >>>> http://www.healthintersections.com.au / > >>>> grahame@healthintersections.com.au / +61 411 867 065 > >>>> > >>>> _______________________________________________ > >>>> scim mailing list > >>>> scim@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/scim > >> > > -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --047d7bf0c59ac901fb0503b13538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ...from the right email this time...

Sure, I can expand.= A couple of points:

Most uses of scim will use th= e user/group in the context of=C2=A0some wider set of functionality. Either= they can extend the scim user - a long way - or they can link the user to = their other context. For instance, in the context of health, for which I am= writing what will be a widely used=C2=A0spec, the user will correspond to = either a patient or a healthcare provider (or perhaps both, though most sys= tems keep them far apart even when they're the same person). How is thi= s link to be established? It could either be from the scim user to the exta= rnal resource, or to the other way around, or both. I'm thinking about = which would be better, but if it's from the user to the=C2=A0external r= esource:
- it could be by reusing the external id. But the extern= al id as described by the spec and /or Phil's comments is not suitable = for this use, and it has other uses
- it could be by putting exte= nsions into the resource. Perhaps this is the intent, though I'm not su= re why extarnalId is very different=C2=A0
- it could done be addi= ng a link property that has rel-type and href. I'd use related, but the= re's a bunch of interesting ones here:=C2=A0http://www.iana.org/as= signments/link-relations/link-relations.xhtml.=C2=A0

That's the second - these links are used for hateos. I suppose t= hat you could confine them to the http header (in fact, we could use it tha= t way in my context too), but there's kind of a difference between work= flow uses and uses related to meaning - that's why HTML pages can inclu= de links in the page itself, not just in the headers,,and why I think it wo= uld be a good idea to add them to the resource itself.mpossibly in the meta= element

A couple of further comments:
-= I'm still thinking about how the link should be made, and if the spec = already answers think I missed it. But I think it will be a common use case= .
- I'm also interested in the by-play between links on the h= ttp headers, and links in the resource as well. Is this as good an idea as = I made it sound?

Grahame

=

On Tuesday, September 23, 2014, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
Can you please expand?



On 9/22/14, 4:33 PM, "Grahame Grieve" <graha= meg@gmail.com> wrote:

>No, not for a complex external id, but I would like to have a set of >links for the user.
>
>Grahame
>
>> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)"<= br> >><moransar@cisco.com> wrote:
>>
>> As far as I can tell nobody brought up any use cases for adding su= pport
>> for multi-valued or complex externalID.=C2=A0 I take that as conse= nsus to
>> clarify the spec and stating this is a single valued attribute and= move
>> forward.=C2=A0 If anyone objects to this, please speak up now.
>>
>>
>> Cheers,
>> Morteza
>>
>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <charliemortimore@gmail.com>
>>>wrote:
>>>
>>> externalid is there to provide a surrogate primary key for the= scim
>>> entity so it can be more easily addressed by scim consumers or=
>>>federation
>>> services.
>>>
>>> For example, if you are trying to provide single sign-on to a = cloud
>>> service, it is often more convenient for the IDP to use its lo= cal
>>> identifier for the user, rather than to update its schema and = store the
>>> identifier used by the cloud service.=C2=A0 =C2=A0So - it(or t= he provisions
>>>service
>>> it is paired with) would use scim to set its primary id for th= e user as
>>> externalid and send that as the subject of a SAML assertion. >>>
>>> - cmort
>>>
>>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve
>>>> <grahame@healthinters= ections.com.au> wrote:
>>>>
>>>> it's not clear what externalId is for. In a distribute= d system, it's
>>>> not unlikely that there will be multiple relevant other id= entifiers -
>>>> is there some notion of which is primary? For instance, I = need to map
>>>> between the User resource in the SCIM interface, and a Pat= ient record
>>>> in a different interface, so that the security engine know= s that this
>>>> user is the same as this patient. Should that be externalI= d, or should
>>>> it be somewhere else (an extension?). I didn't think t= hat the
>>>> definition of external id was quite clear enough to be sur= e. But if I
>>>> said to use externalId for that, what happens to other use= s of
>>>> externalId - same user on a different user record? (which = is why I
>>>> think I shouldn't use externalId for that)
>>>>
>>>> Earlier in the thread, someone said that multiple identifi= ers might
>>>> leak between different clients. Well, you might want them = to share the
>>>> multiple identifiers, but limiting identifier to one doesn= 't solve the
>>>> leakage problem - so I don't think it's a reason t= o limit it to one.
>>>>
>>>> Still, multiple identifiers are always a problem - how do = you tell
>>>> them apart? Actually, I looked for a set of links that ide= ntified
>>>> related records to the user - e,g, href=3D + rel=3D. I wou= ld prefer this
>>>> over the existing approach
>>>>
>>>> Grahame
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)=
>>>> <moransar@cisco.com> wrote: >>>>> I would like to ask anyone that have real use cases fo= r multi-valued
>>>>>or
>>>>> typed/complex externalID to bring them to the WG.=C2= =A0 I think it would
>>>>> greatly
>>>>> help better define this and make a decision on whether= we need to
>>>>> extend the
>>>>> current definition or just clarify it.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Morteza
>>>>>
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> scim@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> http://www.healthintersections.com.au /
>>>> grahame@healthintersecti= ons.com.au / +61 411 867 065
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>



--
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065
--047d7bf0c59ac901fb0503b13538-- From nobody Tue Sep 23 01:42:14 2014 Return-Path: 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 5F14A1A00E9 for ; Tue, 23 Sep 2014 01:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Nj_TQ8CgBw9x for ; Tue, 23 Sep 2014 01:42:10 -0700 (PDT) Received: from mail-ig0-f199.google.com (mail-ig0-f199.google.com [209.85.213.199]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93251A03E3 for ; Tue, 23 Sep 2014 01:42:09 -0700 (PDT) Received: by mail-ig0-f199.google.com with SMTP id r10so24394384igi.6 for ; Tue, 23 Sep 2014 01:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=nLdbzIkxDkQk0gFwE3Euw+ZW9BCxXFsBzYk9ARQHuKY=; b=GsilNp6l+SfL9kqCrpPB2NdwxSITJlA3qLQiyYUntKbtyLtfbYbxlyMM5zk18Y2Gif mm5g5siSeOvrwJFewB2h+O9RembTai/mF2OWbzPCEjS7ixMt4ZbImejJvcHiwSOfP5RV qzESZCgMf+SYJvz3VBg42h25L8fbyq151oQkGcBM8ZdMEbmsktp2nIrhzVxK+nkZuJj+ lCsoAg35xYdh5QXFYBWXf3dVY0nGBIYNPeTmGesCyk7n2LFHzUFY+Jrp/bhw/5gOzUqd Vg8+EdlP9B/uG3WdCGFu+Vw5yFE3H0ixlPhEOBd71Jn3A6ZMcL8pzuj/SruSekNerxx7 CelQ== X-Gm-Message-State: ALoCoQlwB2Hg5PVb72keRsi3T76pCJ4nM1piKZ4elSxidSZk4wcMRC2FtJgZa34u6SczYbvOvQhd X-Received: by 10.50.66.36 with SMTP id c4mr20319723igt.48.1411461728796; Tue, 23 Sep 2014 01:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.70.33 with HTTP; Tue, 23 Sep 2014 01:41:48 -0700 (PDT) In-Reply-To: References: <26670283-4756-49D7-B684-F5123ECF52BE@oracle.com> From: Thomas Krille Date: Tue, 23 Sep 2014 10:41:48 +0200 Message-ID: To: SCIM WG Content-Type: multipart/alternative; boundary=001a1134cc1ef5a6290503b78af8 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/JB9DpoKo4yTuoUMLTH7nn-0qW-4 Subject: Re: [scim] Questions about defined vs. supported schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 08:42:12 -0000 --001a1134cc1ef5a6290503b78af8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I think a SCIM server should obey Postel's law, i.e. *Be conservative in what you do, be liberal in what you accept from others *[1]. So just ignoring attributes that are not supported should be totally fine. In fact, as a SCIM server always returns the changed resource, one can always figure out if some attribute was actually saved or not. The idea to define a special value "unsupported" for the "mutability" attribute sounds good. At least this way clients can figure out, too, why their attribute was not stored by the server. On the other hand, just removing the attribute from schemas has the same effect: you sending the unsupported attribute "photos" to the server, it ignores it, and you can query the server what attributes it support, seeing that it does not list "photos". So, I think 3.a is the best option, but adding a special value "unsupported" for the "mutability" attribute might also be a good thing. [1] http://en.wikipedia.org/wiki/Robustness_principle --=20 Thomas Krille Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-128 Telefax +49 (0) 228 54881-235 t.krille@tarent.de Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale= xander Steeg 2014-09-23 0:18 GMT+02:00 Morteza Ansari (moransar) : > Speaking as an implementer: our current implementation is doing 3B. 2 > is certainly an option, but I like the idea of unsupported mutability the > best. The question is what is the semantics if a server defines =E2=80=9C= photos=E2=80=9D as > unsupported, but gets a put request with it? Does it ignore the value or > return a schema error? I see pro/cons for both. > > > Cheers, > Morteza > > From: Ian Glazer > Date: Monday, September 22, 2014 at 2:20 PM > To: Phil Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Questions about defined vs. supported schema > > > > On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt wrote: > >> I received a question from an implementer about how to indicate >> non-supported attributes that are defined in core-schema. >> >> For example, a service provider doesn=E2=80=99t want to use =E2=80=9Cph= otos=E2=80=9D as defined >> in the core schemas. >> >> Should it: >> >> 1. Do nothing. Just accept the values and then ignore them. >> >> 2. In schemas, mark the attribute as =E2=80=9CreadOnly=E2=80=9D and th= en ignore them. >> (this is acceptable in the current rules) >> >> 3. Remove the attribute from Schemas. If it then receives a value >> should it: >> a. Ignore the value >> b. Return a schema error. >> >> In general, should we be silently ignoring attributes that are included >> in a JSON payload (e.g. on POST) that are not part of the schema? Or, >> should the server throw an error? >> >> With my editor hat off, my personal reaction is that servers should be >> flexible in what they accept and feel free to pick and choose data with >> appropriate DoS considerations. I have a tendency to think that a server >> can simply ignore data it does not understand or care about. Further th= e >> server is free to alter any values it does accept as long as it returns = the >> new values in its response. >> >> That said, when we are talking about standard schema, it may be useful >> to do 2 above which tells a client admin why a server may not be appeari= ng >> to accept an attribute value. We may actually want to have a mutability= of >> =E2=80=9Cunsupported=E2=80=9D which simply means the server will ignore = it entirely and >> will never return a value. This is a bit better than =E2=80=9CreadOnly= =E2=80=9D which says >> the server may set the value but the client may not. >> >> Doing 2 seems like a workable hack but a hack nonetheless. I like the > idea of an "unsupported" mutability - makes things a bit more clear > > >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1134cc1ef5a6290503b78af8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I think a SCIM server should obe= y Postel's law, i.e. Be conservative in what you do, be liberal in w= hat you accept from others=C2=A0[1]. So just ignoring attributes that a= re not supported should be totally fine. In fact, as a SCIM server always r= eturns the changed resource, one can always figure out if some attribute wa= s actually saved or not. The idea to define a special value "unsupport= ed" for the "mutability" attribute sounds good. At least thi= s way clients can figure out, too, why their attribute was not stored by th= e server. On the other hand, just removing the attribute from schemas has t= he same effect: you sending the unsupported attribute "photos" to= the server, it ignores it, and you can query the server what attributes it= support, seeing that it does not list "photos".

So, I think 3.a is the best option, but adding=C2=A0a special valu= e "unsupported" for the "mutability" attribute might al= so be a good thing.


--=C2=A0
Thomas Kr= ille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0)= 30 138803-128
Telefax +49 (0) 228 54881-235
t.krille@tarent.de

Rochusstra= =C3=9Fe 2-4, D-53123 Bonn =E2=80=A2=C2=A0http://www.tarent.de/<= br>Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 516= 8 =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Ste= fan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

2014-09-23 0:18 GMT+02:00 Morteza Ansari (mo= ransar) <moransar@cisco.com>:
Speaking as an implementer: our current implementation is doing 3B. = =C2=A02 is certainly an option, but I like the idea of unsupported mutabili= ty the best. The question is what is the semantics if a server defines =E2= =80=9Cphotos=E2=80=9D as unsupported, but gets a put request with it?=C2=A0 Does it ignore the value or return a schema error?=C2=A0 I = see pro/cons for both.


Cheers,
Morteza

From: Ian Glazer <iglazer@salesforce.com>= ;
Date: Monday, September 22, 2014 at= 2:20 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Questions about= defined vs. supported schema



On Mon, Sep 22, 2014 at 10:42 AM, Phil Hunt <phil.hunt@ora= cle.com> wrote:
I received a question from an implement= er about how to indicate non-supported attributes that are defined in core-= schema.

For example, a service provider doesn=E2=80=99t want to use =E2=80=9Cp= hotos=E2=80=9D as defined in the core schemas.=C2=A0

Should it:

1.=C2=A0 Do nothing.=C2=A0 Just accept the values and then ignore them= .

2.=C2=A0 In schemas, mark the attribute as =E2=80=9CreadOnly=E2=80=9D = and then ignore them. (this is acceptable in the current rules)

3.=C2=A0 Remove the attribute from Schemas.=C2=A0 If it then receives = a value should it:
a. Ignore the value
b. Return a schema error.

In general, should we be silently ignoring attributes that are include= d in a JSON payload (e.g. on POST) that are not part of the schema?=C2=A0 O= r, should the server throw an error?

With my editor hat off, my personal reaction is that servers should be= flexible in what they accept and feel free to pick and choose data with ap= propriate DoS considerations. I have a tendency to think that a server can = simply ignore data it does not understand or care about.=C2=A0 Further the server is free to alter any values it doe= s accept as long as it returns the new values in its response.

That said, when we are talking about standard schema, it may be useful= to do 2 above which tells a client admin why a server may not be appearing= to accept an attribute value.=C2=A0 We may actually want to have a mutabil= ity of =E2=80=9Cunsupported=E2=80=9D which simply means the server will ignore it entirely and will never return a value.=C2=A0 Th= is is a bit better than =E2=80=9CreadOnly=E2=80=9D which says the server ma= y set the value but the client may not.

Doing 2 seems like a workable hack but a hack nonetheless. I like the = idea of an "unsupported" mutability - makes things a bit more cle= ar
=C2=A0

_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166

_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim


--001a1134cc1ef5a6290503b78af8-- From nobody Fri Sep 26 16:21:07 2014 Return-Path: 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 15D0D1A00C0 for ; Fri, 26 Sep 2014 16:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.686 X-Spam-Level: X-Spam-Status: No, score=-14.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 oi49SPRku-0r for ; Fri, 26 Sep 2014 16:21:01 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A41A8711 for ; Fri, 26 Sep 2014 16:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21292; q=dns/txt; s=iport; t=1411773661; x=1412983261; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bFtLNMUj3oDAF3CTp8IgzvtjgwiSeTM15UVOua+IzCw=; b=iG6uUPIljBPLkLxuC1BuLWg11LlihQ2GEC645ADDQcoDEE75AXiB6CMV mWg9OmgkxGYttMfe7D04m2ClMApZ7rBB01kaS3KmsPyabZfzP75nNRM3T PysrPMk5HYwfV5JHMbUrNdCXxKaVgrMK+pCJXGFJL/RAeFdDTMM9eQw41 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAP3zJVStJA2J/2dsb2JhbABfgkhGU1cEyj0BCYdOAoEHFgF7hAMBAQEEAQEBCT0lCxACAQgRAwECKAchBgsUCQgCBA4FiCoDEQ2wcoZ1DYcfAReNboFZRg0EBgEJhEIFkWOJM4IQjxSGSINjbIEHQYECAQEB X-IronPort-AV: E=Sophos; i="5.04,606,1406592000"; d="scan'208,217"; a="81711548" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 26 Sep 2014 23:20:59 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8QNKxON027344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 23:20:59 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 18:20:59 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAeUkA//+M6ACAAIajgIAFyZAA Date: Fri, 26 Sep 2014 23:20:58 +0000 Message-ID: References: <075EE1B3-715D-4953-8132-C038CCDECE1D@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.76.203] Content-Type: multipart/alternative; boundary="_000_D04B3FEFFC78Fmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1GbrHKxC-AQX4ejDpdLnA7dt8hs Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 23:21:05 -0000 --_000_D04B3FEFFC78Fmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual: Sorry Phil, but I am still confused here. Not sure what it means for multi= ple clients to have provisioning or management rights to the same object. = How is this different from first name? In your scenario one client wants t= o set externalID to =93x=94 and another client wants to set it to =93y=94, = how is that different from the first client wanting to set first name to = =93John=94 and second client trying to set it to =93Johny=94? I see the use case of a hub and spoke provisioning (or cross domain), where= a client may want to provision to multiple SCIM servers (wasn=92t this the= old targeting use case?). In that case the client certainly could manage = that additional data internally if it needs it (not using externalID) and h= ave a mapping between its different ID spaces and the target SCIM server wh= ere it will be provisioning. Cheers, Morteza From: Phil Hunt > Date: Monday, September 22, 2014 at 4:58 PM To: Morteza Ansari > Cc: "scim@ietf.org" >, Chuck Mortimore >, Grahame Grieve > Subject: Re: [scim] Use cases for enhancements to externalID I think I=92m being a bit pedantic too, but I=92m just anticipating questio= ns down the road here. >From the spec... externalId A String that is an identifier for the resource as defined by the client. The "externalId" may simplify identification of the resource between client and service provider by allowing the client to use a filter to locate the resource with its own identifier, obviating the need to store a local mapping between the local identifier of the resource and the identifier used by the service provider. Each resource MAY include a non-empty "externalId" value. The value of the "externalId" attribute is always issued by the client and MUST NOT be specified by the service provider. The service provider MUST always interpret the externalId as scoped to the client's tenant. While the server does not enforce uniqueness, it is assumed that the value's uniqueness is controlled by the client setting the value. See Section 9 for additional considerations regarding privacy. The text that gives me concern is: The value of the "externalId" attribute is always issued by the client and MUST NOT be specified by the service provider. The service provider MUST always interpret the externalId as scoped to the client's tenant. The problem I=92m having is that externalId is single-valued and bound to t= he tenant. This simple requirement has a wide amount of interpretation and = methods for implementation. I=92m worried about a lot of incompatibilities = emerging here. What happens if multiple security domains (remember SCIM is cross-domain) a= re referencing the same user resource? Are they each allowed to have a sing= le-value? Thus the server is required to virtualize the fact that there is= only a single value but will have to maintain multiple externalId instance= s based on domain/tenancy whatever? This definition has implied virtualization and security characteristics tha= t no other attribute type has. Are we really wanting to do something speci= al here? Are we saying that there can be access control and that for any pa= rticular attribute, the server may accept or decline values (in which case = should it ignore or throw an error). Other options: 1. Multi-valued plus typing - any client can do what ever they want techni= cally. In practice we set type value to someting that indicates a domain or= format. 2. Single-valued immutable - first client to set the value wins. This is = not helpful to second, or third to the table clients who also want to assig= n an externalId 3. Create a new data type/access control definition that allows specific v= alues to be assigned to clients. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 22, 2014, at 3:56 PM, Morteza Ansari (moransar) > wrote: Any client that is authorized to modify the value. Not sure what you mean by bound. No attribute is bound to a specific client, this is no different (given lack of new use cases). Cheers, Morteza On 9/22/14, 3:48 PM, "Phil Hunt" > wrote: If it is single valued, which client may set the value? How is it bound? Phil On Sep 22, 2014, at 15:34, "Morteza Ansari (moransar)" > wrote: As far as I can tell nobody brought up any use cases for adding support for multi-valued or complex externalID. I take that as consensus to clarify the spec and stating this is a single valued attribute and move forward. If anyone objects to this, please speak up now. Cheers, Morteza On 9/11/14, 7:53 AM, "Chuck Mortimore" > wrote: externalid is there to provide a surrogate primary key for the scim entity so it can be more easily addressed by scim consumers or federation services. For example, if you are trying to provide single sign-on to a cloud service, it is often more convenient for the IDP to use its local identifier for the user, rather than to update its schema and store the identifier used by the cloud service. So - it(or the provisions service it is paired with) would use scim to set its primary id for the user as externalid and send that as the subject of a SAML assertion. - cmort On Sep 10, 2014, at 10:58 PM, Grahame Grieve > wrote: it's not clear what externalId is for. In a distributed system, it's not unlikely that there will be multiple relevant other identifiers - is there some notion of which is primary? For instance, I need to map between the User resource in the SCIM interface, and a Patient record in a different interface, so that the security engine knows that this user is the same as this patient. Should that be externalId, or should it be somewhere else (an extension?). I didn't think that the definition of external id was quite clear enough to be sure. But if I said to use externalId for that, what happens to other uses of externalId - same user on a different user record? (which is why I think I shouldn't use externalId for that) Earlier in the thread, someone said that multiple identifiers might leak between different clients. Well, you might want them to share the multiple identifiers, but limiting identifier to one doesn't solve the leakage problem - so I don't think it's a reason to limit it to one. Still, multiple identifiers are always a problem - how do you tell them apart? Actually, I looked for a set of links that identified related records to the user - e,g, href=3D + rel=3D. I would prefer this over the existing approach Grahame On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) > wrote: I would like to ask anyone that have real use cases for multi-valued or typed/complex externalID to bring them to the WG. I think it would greatly help better define this and make a decision on whether we need to extend the current definition or just clarify it. Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D04B3FEFFC78Fmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8CEDF23B38910B41AF5A4E39968E020C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Speaking as an individual:

Sorry Phil, but I am still confused here.  Not sure what it means= for multiple clients to have provisioning or management rights to the same= object.  How is this different from first name?  In your scenari= o one client wants to set externalID to =93x=94 and another client wants to set it to =93y=94, how is that different from the = first client wanting to set first name to =93John=94 and second client tryi= ng to set it to =93Johny=94?

I see the use case of a hub and spoke provisioning (or cross domain), = where a client may want to provision to multiple SCIM servers (wasn=92t thi= s the old targeting use case?).  In that case the client certainly cou= ld manage that additional data internally if it needs it (not using externalID) and have a mapping between its diffe= rent ID spaces and the target SCIM server where it will be provisioning.


Cheers,
Morteza

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, September 22, 2014 at= 4:58 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: "scim@ietf.org" <scim@i= etf.org>, Chuck Mortimore <charliemortimore@gmail.com>, Grahame Grieve <grahame@healthintersections.com.a= u>
Subject: Re: [scim] Use cases for e= nhancements to externalID

I think I=92m being a bit pedantic too, but I=92m just anticipating qu= estions down the road here. 

From the spec...

externalId
      A String that is an identifier for the resource a= s defined by the
      client.  The "externalId" may simp= lify identification of the
      resource between client and service provider by a= llowing the
      client to use a filter to locate the resource wit= h its own
      identifier, obviating the need to store a local m= apping between
      the local identifier of the resource and the iden= tifier used by
      the service provider.  Each resource MAY inc= lude a non-empty
      "externalId" value.  The value = of the "externalId" attribute is
      always issued by the client and MUST NOT be sp= ecified by the
      service provider.  The service provider M= UST always interpret the
      externalId as scoped to the client's tenant.  While the server
      does not enforce uniqueness, it is assumed that t= he value's
      uniqueness is controlled by the client setting th= e value.  See
      Section 9 for additional considerations rega= rding privacy.

The text that gives me concern is:
     The value of the "externalId" attribute = is
      always issued by the client and MUST NOT be specified = by the
      service provider.  The service provider MUST alwa= ys interpret the
      externalId as scoped to the client's tenant.

The problem I=92m having is that externalId is single-valued and bound= to the tenant. This simple requirement has a wide amount of interpretation= and methods for implementation. I=92m worried about a lot of incompatibili= ties emerging here.

What happens if multiple security domains (remember SCIM is cross-doma= in) are referencing the same user resource? Are they each allowed to have a= single-value?  Thus the server is required to virtualize the fact tha= t there is only a single value but will have to maintain multiple externalId instances based on domain/tenancy wha= tever?

This definition has implied virtualization and security characteristic= s that no other attribute type has.  Are we really wanting to do somet= hing special here? Are we saying that there can be access control and that = for any particular attribute, the server may accept or decline values (in which case should it ignore or throw an e= rror).

Other options:
1.  Multi-valued plus typing - any client can do what ever they w= ant technically. In practice we set type value to someting that indicates a= domain or format.
2.  Single-valued immutable - first client to set the value wins.=  This is not helpful to second, or third to the table clients who als= o want to assign an externalId
3.  Create a new data type/access control definition that allows = specific values to be assigned to clients.


On Sep 22, 2014, at 3:56 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

Any client that is authorized to modify the value= .  Not sure what you mean
by bound.  No attribute is bound to a specific client, this is no
different (given lack of new use cases).


Cheers,
Morteza

On 9/22/14, 3:48 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:

If it is single valued, which client may set the = value?

How is it bound?

Phil

On Sep 22, 2014, at 15:34, "Morteza Ansari (= moransar)"
<moransar@cisco.com> wrote:=

As far as I can tell nobody brought up any use cases for adding support
for multi-valued or complex externalID.  I take that as consensus to clarify the spec and stating this is a single valued attribute and move
forward.  If anyone objects to this, please speak up now.


Cheers,
Morteza

On 9/11/14, 7:53 AM, "Chuck Mortimore" = <charliemortimore@gmail.co= m>
wrote:

externalid is there to provide a surrogate primary key for the scim
entity so it can be more easily addressed by scim consumers or
federation
services. 

For example, if you are trying to provide single sign-on to a cloud
service, it is often more convenient for the IDP to use its local
identifier for the user, rather than to update its schema and store the
identifier used by the cloud service.   So - it(or the provisions
service
it is paired with) would use scim to set its primary id for the user as
externalid and send that as the subject of a SAML assertion.

- cmort

On Sep 10, 2014, at 10:58 PM, Grahame Grieve
<grahame@healthint= ersections.com.au> wrote:

it's not clear what externalId is for. In a distributed system, it's
not unlikely that there will be multiple relevant other identifiers -
is there some notion of which is primary? For instance, I need to map
between the User resource in the SCIM interface, and a Patient record
in a different interface, so that the security engine knows that this
user is the same as this patient. Should that be externalId, or should
it be somewhere else (an extension?). I didn't think that the
definition of external id was quite clear enough to be sure. But if I
said to use externalId for that, what happens to other uses of
externalId - same user on a different user record? (which is why I
think I shouldn't use externalId for that)

Earlier in the thread, someone said that multiple identifiers might
leak between different clients. Well, you might want them to share the
multiple identifiers, but limiting identifier to one doesn't solve the
leakage problem - so I don't think it's a reason to limit it to one.

Still, multiple identifiers are always a problem - how do you tell
them apart? Actually, I looked for a set of links that identified
related records to the user - e,g, href=3D + rel=3D. I would prefer thi= s
over the existing approach

Grahame


On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)
<moransar@cisco.com> wrote:=
I would like to ask anyone that have real use cas= es for multi-valued
or
typed/complex externalID to bring them to the WG.  I think it would greatly
help better define this and make a decision on whether we need to
extend the
current definition or just clarify it.


Cheers,
Morteza

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim



-- 
-----
http://www.healthintersec= tions.com.au /
grahame@healthinterse= ctions.com.au / +61 411 867 065

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

 --_000_D04B3FEFFC78Fmoransarciscocom_-- From nobody Fri Sep 26 17:03:21 2014 Return-Path: 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 842CB1A877F for ; Fri, 26 Sep 2014 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.686 X-Spam-Level: X-Spam-Status: No, score=-14.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 lUdYxgGlWjy0 for ; Fri, 26 Sep 2014 17:03:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB7B1A8783 for ; Fri, 26 Sep 2014 17:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19598; q=dns/txt; s=iport; t=1411776198; x=1412985798; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i1HjKTYnLJoNEN/fL6dIryttWttuU/KhSnladsxii44=; b=EfcQ2vq80a+m68gIpl/wSQlzl6wCea3ry+4+btIOk3S50Lr9fr7EyTeb 4cLvr5dHM67a74ETGMME9vYeG7XdoVpbHyTLf/FmVZYojhu2ANGjxaJup QRZVdpw2NjVdv/LzsbUauRHcxcDPZcl5wOH+IpZ25N+d1sfsH4CjBhdcb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJX9JVStJV2d/2dsb2JhbABfgkhGU1cEyj0BCYdOAoEHFgF7hAMBAQEEAQEBawQHEAIBCBEDAQIBJwchBgsUCQgCBA4FCYghAxENt18Nhx8BFAMGAY1ngU4LBgE/DQQHCYRCBZFjiTOCEI8UhkiDY2wBgQYIFyKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,606,1406592000"; d="scan'208,217";a="358611848" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Sep 2014 00:03:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8R03Fq3030678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 00:03:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 19:03:15 -0500 From: "Morteza Ansari (moransar)" To: Grahame Grieve Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4CAAI84gIAFwaeA Date: Sat, 27 Sep 2014 00:03:14 +0000 Message-ID: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.76.203] Content-Type: multipart/alternative; boundary="_000_D04B4B50FC809moransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/th2IayVZGwtC7CZeir9IuIGS_G4 Cc: "scim@ietf.org" , Chuck Mortimore Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 00:03:19 -0000 --_000_D04B4B50FC809moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the additional info. Wouldn=92t this be a classic case of schem= a extension though? In your example you probably need two distinct schema = extensions, one for =93patient=94 and another for =93provider=94 where each= extension defines the necessary attributes and semantics for that type of = user and if the user happens to be both a patient in one context and a prov= ider in another context, will have both extensions. I don=92t see how that= links with externalID unless you consider each of these providers a differ= ent authoritative source in which case you are going down the distributed a= ttribute provider which is probably a whole net set of use cases (interesti= ng use cases though). Cheers, Morteza From: Grahame Grieve > Date: Monday, September 22, 2014 at 6:08 PM To: Morteza Ansari > Cc: Chuck Mortimore >, "scim@ietf.org" > Subject: Re: [scim] Use cases for enhancements to externalID ...from the right email this time... Sure, I can expand. A couple of points: Most uses of scim will use the user/group in the context of some wider set = of functionality. Either they can extend the scim user - a long way - or th= ey can link the user to their other context. For instance, in the context o= f health, for which I am writing what will be a widely used spec, the user = will correspond to either a patient or a healthcare provider (or perhaps bo= th, though most systems keep them far apart even when they're the same pers= on). How is this link to be established? It could either be from the scim u= ser to the extarnal resource, or to the other way around, or both. I'm thin= king about which would be better, but if it's from the user to the external= resource: - it could be by reusing the external id. But the external id as described = by the spec and /or Phil's comments is not suitable for this use, and it ha= s other uses - it could be by putting extensions into the resource. Perhaps this is the = intent, though I'm not sure why extarnalId is very different - it could done be adding a link property that has rel-type and href. I'd u= se related, but there's a bunch of interesting ones here: http://www.iana.o= rg/assignments/link-relations/link-relations.xhtml. That's the second - these links are used for hateos. I suppose that you cou= ld confine them to the http header (in fact, we could use it that way in my= context too), but there's kind of a difference between workflow uses and u= ses related to meaning - that's why HTML pages can include links in the pag= e itself, not just in the headers,,and why I think it would be a good idea = to add them to the resource itself.mpossibly in the meta element A couple of further comments: - I'm still thinking about how the link should be made, and if the spec alr= eady answers think I missed it. But I think it will be a common use case. - I'm also interested in the by-play between links on the http headers, and= links in the resource as well. Is this as good an idea as I made it sound? Grahame On Tuesday, September 23, 2014, Morteza Ansari (moransar) > wrote: Can you please expand? On 9/22/14, 4:33 PM, "Grahame Grieve" > wr= ote: >No, not for a complex external id, but I would like to have a set of >links for the user. > >Grahame > >> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)" >>> wrote: >> >> As far as I can tell nobody brought up any use cases for adding support >> for multi-valued or complex externalID. I take that as consensus to >> clarify the spec and stating this is a single valued attribute and move >> forward. If anyone objects to this, please speak up now. >> >> >> Cheers, >> Morteza >> >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" > >>>wrote: >>> >>> externalid is there to provide a surrogate primary key for the scim >>> entity so it can be more easily addressed by scim consumers or >>>federation >>> services. >>> >>> For example, if you are trying to provide single sign-on to a cloud >>> service, it is often more convenient for the IDP to use its local >>> identifier for the user, rather than to update its schema and store the >>> identifier used by the cloud service. So - it(or the provisions >>>service >>> it is paired with) would use scim to set its primary id for the user as >>> externalid and send that as the subject of a SAML assertion. >>> >>> - cmort >>> >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>>> > wrote: >>>> >>>> it's not clear what externalId is for. In a distributed system, it's >>>> not unlikely that there will be multiple relevant other identifiers - >>>> is there some notion of which is primary? For instance, I need to map >>>> between the User resource in the SCIM interface, and a Patient record >>>> in a different interface, so that the security engine knows that this >>>> user is the same as this patient. Should that be externalId, or should >>>> it be somewhere else (an extension?). I didn't think that the >>>> definition of external id was quite clear enough to be sure. But if I >>>> said to use externalId for that, what happens to other uses of >>>> externalId - same user on a different user record? (which is why I >>>> think I shouldn't use externalId for that) >>>> >>>> Earlier in the thread, someone said that multiple identifiers might >>>> leak between different clients. Well, you might want them to share the >>>> multiple identifiers, but limiting identifier to one doesn't solve the >>>> leakage problem - so I don't think it's a reason to limit it to one. >>>> >>>> Still, multiple identifiers are always a problem - how do you tell >>>> them apart? Actually, I looked for a set of links that identified >>>> related records to the user - e,g, href=3D + rel=3D. I would prefer th= is >>>> over the existing approach >>>> >>>> Grahame >>>> >>>> >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>>> > wrote: >>>>> I would like to ask anyone that have real use cases for multi-valued >>>>>or >>>>> typed/complex externalID to bring them to the WG. I think it would >>>>> greatly >>>>> help better define this and make a decision on whether we need to >>>>> extend the >>>>> current definition or just clarify it. >>>>> >>>>> >>>>> Cheers, >>>>> Morteza >>>>> >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>>> >>>> >>>> -- >>>> ----- >>>> http://www.healthintersections.com.au / >>>> grahame@healthintersections.com.au / +61 411 867 065 >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >> -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au<= mailto:grahame@healthintersections.com.au> / +61 411 867 065 --_000_D04B4B50FC809moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5549F322C79C08428B0772B770C53276@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks for the additional info.  Wouldn=92t this be a classic cas= e of schema extension though?  In your example you probably need two d= istinct schema extensions, one for =93patient=94 and another for =93provide= r=94 where each extension defines the necessary attributes and semantics for that type of user and if the user happens to be both a p= atient in one context and a provider in another context, will have both ext= ensions.  I don=92t see how that links with externalID unless you cons= ider each of these providers a different authoritative source in which case you are going down the distributed attr= ibute provider which is probably a whole net set of use cases (interesting = use cases though).


Cheers,
Morteza

From: Grahame Grieve <grahame@healthintersections.com= .au>
Date: Monday, September 22, 2014 at= 6:08 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: Chuck Mortimore <charliemortimore@gmail.com>, &quo= t;scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Use cases for e= nhancements to externalID

...from the right email this time...

Sure, I can expand. A couple of points:

Most uses of scim will use the user/group in the context of some = wider set of functionality. Either they can extend the scim user - a long w= ay - or they can link the user to their other context. For instance, in the= context of health, for which I am writing what will be a widely used spec, the user will correspond to either a= patient or a healthcare provider (or perhaps both, though most systems kee= p them far apart even when they're the same person). How is this link to be= established? It could either be from the scim user to the extarnal resource, or to the other way around, or bot= h. I'm thinking about which would be better, but if it's from the user to t= he external resource:
- it could be by reusing the external id. But the external id as descr= ibed by the spec and /or Phil's comments is not suitable for this use, and = it has other uses
- it could be by putting extensions into the resource. Perhaps this is= the intent, though I'm not sure why extarnalId is very different 
- it could done be adding a link property that has rel-type and href. = I'd use related, but there's a bunch of interesting ones here: ht= tp://www.iana.org/assignments/link-relations/link-relations.xhtml. = ;

That's the second - these links are used for hateos. I suppose that yo= u could confine them to the http header (in fact, we could use it that way = in my context too), but there's kind of a difference between workflow uses = and uses related to meaning - that's why HTML pages can include links in the page itself, not just in the heade= rs,,and why I think it would be a good idea to add them to the resource its= elf.mpossibly in the meta element

A couple of further comments:
- I'm still thinking about how the link should be made, and if the spe= c already answers think I missed it. But I think it will be a common use ca= se.
- I'm also interested in the by-play between links on the http headers= , and links in the resource as well. Is this as good an idea as I made it s= ound?

Grahame



On Tuesday, September 23, 2014, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
Can you please expand?



On 9/22/14, 4:33 PM, "Grahame Grieve" <grahameg@gmail.com> wrote:

>No, not for a complex external id, but I would like to have a set of >links for the user.
>
>Grahame
>
>> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)"<= br> >><moransar@cisco.com> wrote:
>>
>> As far as I can tell nobody brought up any use cases for adding su= pport
>> for multi-valued or complex externalID.  I take that as conse= nsus to
>> clarify the spec and stating this is a single valued attribute and= move
>> forward.  If anyone objects to this, please speak up now.
>>
>>
>> Cheers,
>> Morteza
>>
>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <charliemortimore@gmail.com>
>>>wrote:
>>>
>>> externalid is there to provide a surrogate primary key for the= scim
>>> entity so it can be more easily addressed by scim consumers or=
>>>federation
>>> services.
>>>
>>> For example, if you are trying to provide single sign-on to a = cloud
>>> service, it is often more convenient for the IDP to use its lo= cal
>>> identifier for the user, rather than to update its schema and = store the
>>> identifier used by the cloud service.   So - it(or t= he provisions
>>>service
>>> it is paired with) would use scim to set its primary id for th= e user as
>>> externalid and send that as the subject of a SAML assertion. >>>
>>> - cmort
>>>
>>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve
>>>> <grahame@healthintersections.com.au> wrote:
>>>>
>>>> it's not clear what externalId is for. In a distributed sy= stem, it's
>>>> not unlikely that there will be multiple relevant other id= entifiers -
>>>> is there some notion of which is primary? For instance, I = need to map
>>>> between the User resource in the SCIM interface, and a Pat= ient record
>>>> in a different interface, so that the security engine know= s that this
>>>> user is the same as this patient. Should that be externalI= d, or should
>>>> it be somewhere else (an extension?). I didn't think that = the
>>>> definition of external id was quite clear enough to be sur= e. But if I
>>>> said to use externalId for that, what happens to other use= s of
>>>> externalId - same user on a different user record? (which = is why I
>>>> think I shouldn't use externalId for that)
>>>>
>>>> Earlier in the thread, someone said that multiple identifi= ers might
>>>> leak between different clients. Well, you might want them = to share the
>>>> multiple identifiers, but limiting identifier to one doesn= 't solve the
>>>> leakage problem - so I don't think it's a reason to limit = it to one.
>>>>
>>>> Still, multiple identifiers are always a problem - how do = you tell
>>>> them apart? Actually, I looked for a set of links that ide= ntified
>>>> related records to the user - e,g, href=3D + rel=3D. I= would prefer this
>>>> over the existing approach
>>>>
>>>> Grahame
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)=
>>>> <moransar@cisco.com> wrote:
>>>>> I would like to ask anyone that have real use cases fo= r multi-valued
>>>>>or
>>>>> typed/complex externalID to bring them to the WG. = ; I think it would
>>>>> greatly
>>>>> help better define this and make a decision on whether= we need to
>>>>> extend the
>>>>> current definition or just clarify it.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Morteza
>>>>>
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> scim@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> http://www.healthintersections.com.au /
>>>> grahame@healthintersections.com.au / +61 411 867 065
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>



--
-----
http://= www.healthintersections.com.au / gra= hame@healthintersections.com.au / +61 411 867 065
--_000_D04B4B50FC809moransarciscocom_-- From nobody Fri Sep 26 18:07:04 2014 Return-Path: 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 C4A981A00A7 for ; Fri, 26 Sep 2014 18:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.385 X-Spam-Level: X-Spam-Status: No, score=-4.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 F2L7hc1dIhz4 for ; Fri, 26 Sep 2014 18:06:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4C61A00A9 for ; Fri, 26 Sep 2014 18:06:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8R16t8Y021182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Sep 2014 01:06:56 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8R16rcw013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2014 01:06:54 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8R16rjX010187; Sat, 27 Sep 2014 01:06:53 GMT Received: from [10.98.11.49] (/24.244.23.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 Sep 2014 18:06:52 -0700 References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7995A850-FB9D-44FC-9A71-491B9CCE9878 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Fri, 26 Sep 2014 18:06:49 -0700 To: "Morteza Ansari (moransar)" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/BObqaEigCOFLtwJaX8zia3hcNAg Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 01:07:03 -0000 --Apple-Mail-7995A850-FB9D-44FC-9A71-491B9CCE9878 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think an externid for enterprise to cloud and for saml subject matching (a= s Chuck mentioned) can create conflicts.=20 I also wonder what happens over time when cloud to cloud scenarios occur. Wh= o then controls the value? Who is the owning client is not really defined we= ll in a peer to peer case.=20 I am neutral on this but I do find the current language underspecified if it= is to be single valued.=20 Phil > On Sep 26, 2014, at 17:03, "Morteza Ansari (moransar)" wrote: >=20 > Thanks for the additional info. Wouldn=E2=80=99t this be a classic case o= f schema extension though? In your example you probably need two distinct s= chema extensions, one for =E2=80=9Cpatient=E2=80=9D and another for =E2=80=9C= provider=E2=80=9D where each extension defines the necessary attributes and s= emantics for that type of user and if the user happens to be both a patient i= n one context and a provider in another context, will have both extensions. = I don=E2=80=99t see how that links with externalID unless you consider each= of these providers a different authoritative source in which case you are g= oing down the distributed attribute provider which is probably a whole net s= et of use cases (interesting use cases though). >=20 >=20 > Cheers, > Morteza >=20 > From: Grahame Grieve > Date: Monday, September 22, 2014 at 6:08 PM > To: Morteza Ansari > Cc: Chuck Mortimore , "scim@ietf.org" > Subject: Re: [scim] Use cases for enhancements to externalID >=20 > ...from the right email this time... >=20 > Sure, I can expand. A couple of points: >=20 > Most uses of scim will use the user/group in the context of some wider set= of functionality. Either they can extend the scim user - a long way - or th= ey can link the user to their other context. For instance, in the context of= health, for which I am writing what will be a widely used spec, the user wi= ll correspond to either a patient or a healthcare provider (or perhaps both,= though most systems keep them far apart even when they're the same person).= How is this link to be established? It could either be from the scim user t= o the extarnal resource, or to the other way around, or both. I'm thinking a= bout which would be better, but if it's from the user to the external resour= ce: > - it could be by reusing the external id. But the external id as described= by the spec and /or Phil's comments is not suitable for this use, and it ha= s other uses > - it could be by putting extensions into the resource. Perhaps this is the= intent, though I'm not sure why extarnalId is very different=20 > - it could done be adding a link property that has rel-type and href. I'd u= se related, but there's a bunch of interesting ones here: http://www.iana.or= g/assignments/link-relations/link-relations.xhtml.=20 >=20 > That's the second - these links are used for hateos. I suppose that you co= uld confine them to the http header (in fact, we could use it that way in my= context too), but there's kind of a difference between workflow uses and us= es related to meaning - that's why HTML pages can include links in the page i= tself, not just in the headers,,and why I think it would be a good idea to a= dd them to the resource itself.mpossibly in the meta element >=20 > A couple of further comments: > - I'm still thinking about how the link should be made, and if the spec al= ready answers think I missed it. But I think it will be a common use case. > - I'm also interested in the by-play between links on the http headers, an= d links in the resource as well. Is this as good an idea as I made it sound?= >=20 > Grahame >=20 >=20 >=20 >> On Tuesday, September 23, 2014, Morteza Ansari (moransar) wrote: >> Can you please expand? >>=20 >>=20 >>=20 >> On 9/22/14, 4:33 PM, "Grahame Grieve" wrote: >>=20 >> >No, not for a complex external id, but I would like to have a set of >> >links for the user. >> > >> >Grahame >> > >> >> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)" >> >> wrote: >> >> >> >> As far as I can tell nobody brought up any use cases for adding suppor= t >> >> for multi-valued or complex externalID. I take that as consensus to >> >> clarify the spec and stating this is a single valued attribute and mov= e >> >> forward. If anyone objects to this, please speak up now. >> >> >> >> >> >> Cheers, >> >> Morteza >> >> >> >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" >> >>>wrote: >> >>> >> >>> externalid is there to provide a surrogate primary key for the scim >> >>> entity so it can be more easily addressed by scim consumers or >> >>>federation >> >>> services. >> >>> >> >>> For example, if you are trying to provide single sign-on to a cloud >> >>> service, it is often more convenient for the IDP to use its local >> >>> identifier for the user, rather than to update its schema and store t= he >> >>> identifier used by the cloud service. So - it(or the provisions >> >>>service >> >>> it is paired with) would use scim to set its primary id for the user a= s >> >>> externalid and send that as the subject of a SAML assertion. >> >>> >> >>> - cmort >> >>> >> >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >> >>>> wrote: >> >>>> >> >>>> it's not clear what externalId is for. In a distributed system, it's= >> >>>> not unlikely that there will be multiple relevant other identifiers -= >> >>>> is there some notion of which is primary? For instance, I need to ma= p >> >>>> between the User resource in the SCIM interface, and a Patient recor= d >> >>>> in a different interface, so that the security engine knows that thi= s >> >>>> user is the same as this patient. Should that be externalId, or shou= ld >> >>>> it be somewhere else (an extension?). I didn't think that the >> >>>> definition of external id was quite clear enough to be sure. But if I= >> >>>> said to use externalId for that, what happens to other uses of >> >>>> externalId - same user on a different user record? (which is why I >> >>>> think I shouldn't use externalId for that) >> >>>> >> >>>> Earlier in the thread, someone said that multiple identifiers might >> >>>> leak between different clients. Well, you might want them to share t= he >> >>>> multiple identifiers, but limiting identifier to one doesn't solve t= he >> >>>> leakage problem - so I don't think it's a reason to limit it to one.= >> >>>> >> >>>> Still, multiple identifiers are always a problem - how do you tell >> >>>> them apart? Actually, I looked for a set of links that identified >> >>>> related records to the user - e,g, href=3D + rel=3D. I would prefer t= his >> >>>> over the existing approach >> >>>> >> >>>> Grahame >> >>>> >> >>>> >> >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >> >>>> wrote: >> >>>>> I would like to ask anyone that have real use cases for multi-value= d >> >>>>>or >> >>>>> typed/complex externalID to bring them to the WG. I think it would= >> >>>>> greatly >> >>>>> help better define this and make a decision on whether we need to >> >>>>> extend the >> >>>>> current definition or just clarify it. >> >>>>> >> >>>>> >> >>>>> Cheers, >> >>>>> Morteza >> >>>>> >> >>>>> _______________________________________________ >> >>>>> scim mailing list >> >>>>> scim@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/scim >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> ----- >> >>>> http://www.healthintersections.com.au / >> >>>> grahame@healthintersections.com.au / +61 411 867 065 >> >>>> >> >>>> _______________________________________________ >> >>>> scim mailing list >> >>>> scim@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/scim >> >> >=20 >=20 > --=20 > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.au= / +61 411 867 065 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-7995A850-FB9D-44FC-9A71-491B9CCE9878 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think an externid for enterprise to c= loud and for saml subject matching (as Chuck mentioned) can create conflicts= . 

I also wonder what happens over time when c= loud to cloud scenarios occur. Who then controls the value? Who is the ownin= g client is not really defined well in a peer to peer case. 
=
I am neutral on this but I do find the current language under= specified if it is to be single valued. 

Phil

On S= ep 26, 2014, at 17:03, "Morteza Ansari (moransar)" <moransar@cisco.com> wrote:

Thanks for the additional info.  Wouldn=E2=80=99t this be a classi= c case of schema extension though?  In your example you probably need t= wo distinct schema extensions, one for =E2=80=9Cpatient=E2=80=9D and another= for =E2=80=9Cprovider=E2=80=9D where each extension defines the necessary a= ttributes and semantics for that type of user and if the user happens to be both a pa= tient in one context and a provider in another context, will have both exten= sions.  I don=E2=80=99t see how that links with externalID unless you c= onsider each of these providers a different authoritative source in which case you are going down the distributed attri= bute provider which is probably a whole net set of use cases (interesting us= e cases though).


Cheers,
Morteza

From: Grahame Grieve <grahame@healthintersections.com.a= u>
Date: Monday, September 22, 2014 at 6= :08 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: Chuck Mortimore <charliemortimore@gmail.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Use cases for en= hancements to externalID

...from the right email this time...

Sure, I can expand. A couple of points:

Most uses of scim will use the user/group in the context of some w= ider set of functionality. Either they can extend the scim user - a long way= - or they can link the user to their other context. For instance, in the co= ntext of health, for which I am writing what will be a widely used spec, the user will correspond to either a p= atient or a healthcare provider (or perhaps both, though most systems keep t= hem far apart even when they're the same person). How is this link to be est= ablished? It could either be from the scim user to the extarnal resource, or to the other way around, or both= . I'm thinking about which would be better, but if it's from the user to the=  external resource:
- it could be by reusing the external id. But the external id as descri= bed by the spec and /or Phil's comments is not suitable for this use, and it= has other uses
- it could be by putting extensions into the resource. Perhaps this is t= he intent, though I'm not sure why extarnalId is very different 
- it could done be adding a link property that has rel-type and href. I= 'd use related, but there's a bunch of interesting ones here: http:/= /www.iana.org/assignments/link-relations/link-relations.xhtml. 

That's the second - these links are used for hateos. I suppose that you= could confine them to the http header (in fact, we could use it that way in= my context too), but there's kind of a difference between workflow uses and= uses related to meaning - that's why HTML pages can include links in the page itself, not just in the header= s,,and why I think it would be a good idea to add them to the resource itsel= f.mpossibly in the meta element

A couple of further comments:
- I'm still thinking about how the link should be made, and if the spec= already answers think I missed it. But I think it will be a common use case= .
- I'm also interested in the by-play between links on the http headers,= and links in the resource as well. Is this as good an idea as I made it sou= nd?

Grahame



On Tuesday, September 23, 2014, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
Can you please expand?



On 9/22/14, 4:33 PM, "Grahame Grieve" <grahameg@gmail.com> wrote:<= br>
>No, not for a complex external id, but I would like to have a set of
= >links for the user.
>
>Grahame
>
>> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)"
>><moransar@cisco.com> wrote:
>>
>> As far as I can tell nobody brought up any use cases for adding sup= port
>> for multi-valued or complex externalID.  I take that as consen= sus to
>> clarify the spec and stating this is a single valued attribute and m= ove
>> forward.  If anyone objects to this, please speak up now.
>>
>>
>> Cheers,
>> Morteza
>>
>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <charliemort= imore@gmail.com>
>>>wrote:
>>>
>>> externalid is there to provide a surrogate primary key for the s= cim
>>> entity so it can be more easily addressed by scim consumers or<= br> >>>federation
>>> services.
>>>
>>> For example, if you are trying to provide single sign-on to a c= loud
>>> service, it is often more convenient for the IDP to use its loc= al
>>> identifier for the user, rather than to update its schema and s= tore the
>>> identifier used by the cloud service.   So - it(or th= e provisions
>>>service
>>> it is paired with) would use scim to set its primary id for the= user as
>>> externalid and send that as the subject of a SAML assertion. >>>
>>> - cmort
>>>
>>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve
>>>> <grahame@healthintersections.com.au= > wrote:
>>>>
>>>> it's not clear what externalId is for. In a distributed sys= tem, it's
>>>> not unlikely that there will be multiple relevant other ide= ntifiers -
>>>> is there some notion of which is primary? For instance, I n= eed to map
>>>> between the User resource in the SCIM interface, and a Pati= ent record
>>>> in a different interface, so that the security engine knows= that this
>>>> user is the same as this patient. Should that be externalId= , or should
>>>> it be somewhere else (an extension?). I didn't think that t= he
>>>> definition of external id was quite clear enough to be sure= . But if I
>>>> said to use externalId for that, what happens to other uses= of
>>>> externalId - same user on a different user record? (which i= s why I
>>>> think I shouldn't use externalId for that)
>>>>
>>>> Earlier in the thread, someone said that multiple identifie= rs might
>>>> leak between different clients. Well, you might want them t= o share the
>>>> multiple identifiers, but limiting identifier to one doesn'= t solve the
>>>> leakage problem - so I don't think it's a reason to limit i= t to one.
>>>>
>>>> Still, multiple identifiers are always a problem - how do y= ou tell
>>>> them apart? Actually, I looked for a set of links that iden= tified
>>>> related records to the user - e,g, href=3D + rel=3D. I woul= d prefer this
>>>> over the existing approach
>>>>
>>>> Grahame
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)<= br> >>>> <moransar@cisco.com> wrote:
>>>>> I would like to ask anyone that have real use cases for= multi-valued
>>>>>or
>>>>> typed/complex externalID to bring them to the WG. = I think it would
>>>>> greatly
>>>>> help better define this and make a decision on whether w= e need to
>>>>> extend the
>>>>> current definition or just clarify it.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Morteza
>>>>>
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> scim@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> http://www.healthintersections.com.au /
>>>> grahame@healthintersections.com.au / +61 411 867 065
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>



--
-----
http://w= ww.healthintersections.com.au / grah= ame@healthintersections.com.au / +61 411 867 065
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-7995A850-FB9D-44FC-9A71-491B9CCE9878-- From nobody Sat Sep 27 03:20:30 2014 Return-Path: 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 74DA61A87BE for ; Sat, 27 Sep 2014 03:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 KyyNVkg9U8eU for ; Sat, 27 Sep 2014 03:20:26 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479DA1A87C0 for ; Sat, 27 Sep 2014 03:20:26 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so303014lam.37 for ; Sat, 27 Sep 2014 03:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2FTBWzXwZ9yPX9jL1WpmQvqlisUxTP4G1PBB/atm1u4=; b=QNGVFZJYiEe9nI2UvdOZR1wW2f9WRoUomTfnavDKsePdLnlrcCXe9NL6/Qe8aT6dG7 0kwVPbiOQmsc0nK5NIf42rHZ114dNkYpbjWEkuxJnafQ6FOeQfxJmtj0ingPWNb2Dv/4 JjLUZucRqSfUXUPSBZFFOJiTETiOa1EL6xe1cYv0d6vkRGILiYejg7YeYGSeF/58qaot aUI5CwlrxObX8sJfLe2jcAtLe2H44RbPOD/uhlyhCs67RTEvr9qyOVtaFscxdkdeDh3H bb65SJl5tXLptZc7bdFAY5UF2RteyOAcJQU1H0U1gmIhy1biMhFqPKbXLm2Y13991J4O leSQ== MIME-Version: 1.0 X-Received: by 10.152.234.76 with SMTP id uc12mr26230376lac.50.1411813224500; Sat, 27 Sep 2014 03:20:24 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.25.24.132 with HTTP; Sat, 27 Sep 2014 03:20:24 -0700 (PDT) In-Reply-To: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> Date: Sat, 27 Sep 2014 20:20:24 +1000 X-Google-Sender-Auth: rsfgZEfSTkWPsSo8ygvGHNKMgrA Message-ID: From: Grahame Grieve To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uu1GmUNfaC2Z0hsK84PqSVoHbNg Cc: "scim@ietf.org" , Chuck Mortimore Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 10:20:27 -0000 > Wouldn=E2=80=99t this be a classic case of schema > extension though? In your example you probably need two distinct schema > extensions, one for =E2=80=9Cpatient=E2=80=9D and another for =E2=80=9Cpr= ovider=E2=80=9D where each > extension defines the necessary attributes and semantics for that type of > user and if the user happens to be both a patient in one context and a > provider in another context, will have both extensions. no, because there are already resources for these with their own existing restful interface, and a bunch of defined behaviours etc. So all that is wanted in the SCIM user object is to link to the existing patient or provider resource > I don=E2=80=99t see how > that links with externalID unless you consider each of these providers a > different authoritative source in which case you are going down the > distributed attribute provider which is probably a whole net set of use > cases (interesting use cases though). no, it probably doesn't, as I read more, but is it necessary to add a schema extension to link a user to related external resources? If so, then that's what I'll have to do - but it seems to me that this will be a common extension. What, for instance, would facebook, dropbox or paypal do if they decided to implement SCIM? They would be in the same position, right - need to link from the SCIM user to the logical resource that links to the user in their business environment Grahame From nobody Sat Sep 27 09:44:16 2014 Return-Path: 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 B01E21A1BB7 for ; Sat, 27 Sep 2014 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 CdW3vPhiH1T3 for ; Sat, 27 Sep 2014 09:44:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44C81A1BAF for ; Sat, 27 Sep 2014 09:44:12 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8RGi8dw008253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Sep 2014 16:44:09 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8RGi76B025687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2014 16:44:08 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8RGi6mH020632; Sat, 27 Sep 2014 16:44:06 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Sep 2014 09:44:06 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 27 Sep 2014 09:44:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> To: Grahame Grieve X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/86ev5KqH7ijd-DsHp2t0QJyhJII Cc: "scim@ietf.org" , Chuck Mortimore , Morteza Ansari Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 16:44:14 -0000 I=92m thinking out loud here (and may have this very wrong)=85. The sense that I get from the group is that externalId is intended only = as a lookup key for clients. Assigning meaning to externalId is not = correct usage. It is ok to use externalId=3D{somekey} as a filter, but we should NOT be = using it for the purpose of holding a defined identifier value.=20 Wrong: =93We put patient number in externalId so we can retrieve patient = numbers=94. =20 Correct: Saying we put patient numbers in externalId so we can =93locate=94= patients would be correct usage.=20 Valid: give me the record whose externalId is 1234.=20 Invalid: what is the externalId of this record. Thinking of it this way, having externalId be multi-valued should not = matter. Nor should it matter which value is which. What matters is = that a match can be found for a value. A User schema can be extended to have an attribute patientNum as a = specific attribute. But it may also be useful to add the value to = externalId if the client might not know if the record has been extended = with the attribute. It can use externalId as the general attribute to = match keys against. ExternalId is not meant to be retrieved (it might even be write only or = not returnable). It=92s purpose is for matching only. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 27, 2014, at 3:20 AM, Grahame Grieve = wrote: >> Wouldn=92t this be a classic case of schema >> extension though? In your example you probably need two distinct = schema >> extensions, one for =93patient=94 and another for =93provider=94 = where each >> extension defines the necessary attributes and semantics for that = type of >> user and if the user happens to be both a patient in one context and = a >> provider in another context, will have both extensions. >=20 > no, because there are already resources for these with their own = existing > restful interface, and a bunch of defined behaviours etc. So all that = is > wanted in the SCIM user object is to link to the existing patient or > provider resource >=20 >> I don=92t see how >> that links with externalID unless you consider each of these = providers a >> different authoritative source in which case you are going down the >> distributed attribute provider which is probably a whole net set of = use >> cases (interesting use cases though). >=20 > no, it probably doesn't, as I read more, but is it necessary to add a > schema extension to link a user to related external resources? If > so, then that's what I'll have to do - but it seems to me that this > will be a common extension. What, for instance, would facebook, > dropbox or paypal do if they decided to implement SCIM? They would > be in the same position, right - need to link from the SCIM user > to the logical resource that links to the user in their business > environment >=20 > Grahame >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Sep 28 22:13:51 2014 Return-Path: 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 A17711A0290 for ; Sun, 28 Sep 2014 22:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 GTN-H214RPFg for ; Sun, 28 Sep 2014 22:13:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0661A0282 for ; Sun, 28 Sep 2014 22:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1871; q=dns/txt; s=iport; t=1411967627; x=1413177227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a/N+D1bzk/lmDdNcI+czvLilC3SIfAC/sak1ngI2NrA=; b=aE7TYECevEESIkO8aFEnM63+5fgVtqutW9Uec8EzwudTu2/LbRlBt+7N ZEVCMOmnJpkgCXKM7d4OINkI2MD1+hxVjvBZbe5aI7ikq5QE5UrsLhmK4 IrBbpMLgR2Q4hRVP0Ehjcpx0kZZpewi60fjvnqKwcx1JsDlKbS/iRJ5si Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAD7pKFStJA2H/2dsb2JhbABggw5TW8pACodOAoEEFgF7hAQBAQMBAQEBawsQAgEIRicLJQIEDgWINggNr1ePPwETBI9rMweESwWFFIV/hlKDWIdrlV2DY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,617,1406592000"; d="scan'208";a="82159736" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 29 Sep 2014 05:13:46 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8T5Di6X006422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 05:13:45 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 00:13:44 -0500 From: "Morteza Ansari (moransar)" To: Grahame Grieve Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4CAAI84gIAFwaeAgAEhyQCAAlmgAA== Date: Mon, 29 Sep 2014 05:13:43 +0000 Message-ID: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.68.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4FC373937EED0C45BB64B1C72B84C135@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/_OT2JlpkGbUB_AyIBdenORgwOwo Cc: "scim@ietf.org" , Chuck Mortimore Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:13:48 -0000 Speaking as an individual: Got it. But even in this scenario, it is an schema extension but the new schema is simply a pointer (URL/URI?) to patient and provider resources. On 9/27/14, 3:20 AM, "Grahame Grieve" wrote: >> Wouldn=B9t this be a classic case of schema >> extension though? In your example you probably need two distinct schema >> extensions, one for =B3patient=B2 and another for =B3provider=B2 where e= ach >> extension defines the necessary attributes and semantics for that type >>of >> user and if the user happens to be both a patient in one context and a >> provider in another context, will have both extensions. > >no, because there are already resources for these with their own existing >restful interface, and a bunch of defined behaviours etc. So all that is >wanted in the SCIM user object is to link to the existing patient or >provider resource > >> I don=B9t see how >> that links with externalID unless you consider each of these providers a >> different authoritative source in which case you are going down the >> distributed attribute provider which is probably a whole net set of use >> cases (interesting use cases though). > >no, it probably doesn't, as I read more, but is it necessary to add a >schema extension to link a user to related external resources? If >so, then that's what I'll have to do - but it seems to me that this >will be a common extension. What, for instance, would facebook, >dropbox or paypal do if they decided to implement SCIM? They would >be in the same position, right - need to link from the SCIM user >to the logical resource that links to the user in their business >environment > >Grahame > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Sun Sep 28 22:20:05 2014 Return-Path: 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 7E1841A6FB6 for ; Sun, 28 Sep 2014 22:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.686 X-Spam-Level: X-Spam-Status: No, score=-14.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dobEhljv7G4h for ; Sun, 28 Sep 2014 22:19:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625E91A0275 for ; Sun, 28 Sep 2014 22:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25312; q=dns/txt; s=iport; t=1411967994; x=1413177594; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rlQb9pCiYb2oOCnM9SQuLRegs2ujHZPdB7zANfXkFzg=; b=ByH/QYWvc8MHi3ocwx65DUR+W0vHA6ABCQvdZsdhZKTQLDtT9AEK0N5M CceFaNKvkEjOB1ZV7KfxaKFF+jQxy46v/XTNsbhmTAnbG9SCfhzK4yRv3 h6FKnr/8CTOklW8qTkxG6Z/lYsdyToSdoZIW//ulxoF77HVPu+mobsb2t k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAN/qKFStJV2b/2dsb2JhbABggkhGU1vKQAEJh04CgQQWAXuEAwEBAQQBAQFrBAcQAgEIEQMBAgEnByEGCxQJCAIEDgUJiCEDEQ23aw2HIAEUAwYBjWeBTgsGAT8NBAcJhEIFkWWJM4IQjxWGSINjbAGBBggXIoECAQEB X-IronPort-AV: E=Sophos;i="5.04,618,1406592000"; d="scan'208,217";a="359001983" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 29 Sep 2014 05:19:53 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8T5JqBA031083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 05:19:52 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 00:19:52 -0500 From: "Morteza Ansari (moransar)" To: Phil Hunt Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4CAAI84gIAFwaeAgACHHoCAAvYCAA== Date: Mon, 29 Sep 2014 05:19:52 +0000 Message-ID: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.68.120] Content-Type: multipart/alternative; boundary="_000_D04E38F9FC8DFmoransarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ENAmHq1kXX159m6C678vDSdiIk0 Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:19:58 -0000 --_000_D04E38F9FC8DFmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual: Here is an example of how externalID could be used for chaining ID=92s cros= s multiple providers. Note that this does NOT cover the case where you go = from many to one though. The first client provisions users to service provider A from AD using GUID = as externalID. Service provider A provisions to service provider B and use= s its =93id=94 as =93externalID=94, and so on. The only thing unique about= externalID is the fact the client provisioning uses as a reference back to= its own objects in its store. Obviously as I said this excludes many to o= ne scenarios which really was the basic idea for targeting and I am sure so= oner or later this will come up, but I personally believe that can be handl= ed using extensions semantics we have defined for the schema and protocol. I fully agree with you that the current language is underspecified and shou= ld be tweaked to be more clear. Cheers, Morteza From: Phil Hunt > Date: Friday, September 26, 2014 at 6:06 PM To: Morteza Ansari > Cc: Grahame Grieve >, "scim@ietf.org" >, Chuck Mortimore > Subject: Re: [scim] Use cases for enhancements to externalID I think an externid for enterprise to cloud and for saml subject matching (= as Chuck mentioned) can create conflicts. I also wonder what happens over time when cloud to cloud scenarios occur. W= ho then controls the value? Who is the owning client is not really defined = well in a peer to peer case. I am neutral on this but I do find the current language underspecified if i= t is to be single valued. Phil On Sep 26, 2014, at 17:03, "Morteza Ansari (moransar)" > wrote: Thanks for the additional info. Wouldn=92t this be a classic case of schem= a extension though? In your example you probably need two distinct schema = extensions, one for =93patient=94 and another for =93provider=94 where each= extension defines the necessary attributes and semantics for that type of = user and if the user happens to be both a patient in one context and a prov= ider in another context, will have both extensions. I don=92t see how that= links with externalID unless you consider each of these providers a differ= ent authoritative source in which case you are going down the distributed a= ttribute provider which is probably a whole net set of use cases (interesti= ng use cases though). Cheers, Morteza From: Grahame Grieve > Date: Monday, September 22, 2014 at 6:08 PM To: Morteza Ansari > Cc: Chuck Mortimore >, "scim@ietf.org" > Subject: Re: [scim] Use cases for enhancements to externalID ...from the right email this time... Sure, I can expand. A couple of points: Most uses of scim will use the user/group in the context of some wider set = of functionality. Either they can extend the scim user - a long way - or th= ey can link the user to their other context. For instance, in the context o= f health, for which I am writing what will be a widely used spec, the user = will correspond to either a patient or a healthcare provider (or perhaps bo= th, though most systems keep them far apart even when they're the same pers= on). How is this link to be established? It could either be from the scim u= ser to the extarnal resource, or to the other way around, or both. I'm thin= king about which would be better, but if it's from the user to the external= resource: - it could be by reusing the external id. But the external id as described = by the spec and /or Phil's comments is not suitable for this use, and it ha= s other uses - it could be by putting extensions into the resource. Perhaps this is the = intent, though I'm not sure why extarnalId is very different - it could done be adding a link property that has rel-type and href. I'd u= se related, but there's a bunch of interesting ones here: http://www.iana.o= rg/assignments/link-relations/link-relations.xhtml. That's the second - these links are used for hateos. I suppose that you cou= ld confine them to the http header (in fact, we could use it that way in my= context too), but there's kind of a difference between workflow uses and u= ses related to meaning - that's why HTML pages can include links in the pag= e itself, not just in the headers,,and why I think it would be a good idea = to add them to the resource itself.mpossibly in the meta element A couple of further comments: - I'm still thinking about how the link should be made, and if the spec alr= eady answers think I missed it. But I think it will be a common use case. - I'm also interested in the by-play between links on the http headers, and= links in the resource as well. Is this as good an idea as I made it sound? Grahame On Tuesday, September 23, 2014, Morteza Ansari (moransar) > wrote: Can you please expand? On 9/22/14, 4:33 PM, "Grahame Grieve" > wr= ote: >No, not for a complex external id, but I would like to have a set of >links for the user. > >Grahame > >> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)" >>> wrote: >> >> As far as I can tell nobody brought up any use cases for adding support >> for multi-valued or complex externalID. I take that as consensus to >> clarify the spec and stating this is a single valued attribute and move >> forward. If anyone objects to this, please speak up now. >> >> >> Cheers, >> Morteza >> >>> On 9/11/14, 7:53 AM, "Chuck Mortimore" > >>>wrote: >>> >>> externalid is there to provide a surrogate primary key for the scim >>> entity so it can be more easily addressed by scim consumers or >>>federation >>> services. >>> >>> For example, if you are trying to provide single sign-on to a cloud >>> service, it is often more convenient for the IDP to use its local >>> identifier for the user, rather than to update its schema and store the >>> identifier used by the cloud service. So - it(or the provisions >>>service >>> it is paired with) would use scim to set its primary id for the user as >>> externalid and send that as the subject of a SAML assertion. >>> >>> - cmort >>> >>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve >>>> > wrote: >>>> >>>> it's not clear what externalId is for. In a distributed system, it's >>>> not unlikely that there will be multiple relevant other identifiers - >>>> is there some notion of which is primary? For instance, I need to map >>>> between the User resource in the SCIM interface, and a Patient record >>>> in a different interface, so that the security engine knows that this >>>> user is the same as this patient. Should that be externalId, or should >>>> it be somewhere else (an extension?). I didn't think that the >>>> definition of external id was quite clear enough to be sure. But if I >>>> said to use externalId for that, what happens to other uses of >>>> externalId - same user on a different user record? (which is why I >>>> think I shouldn't use externalId for that) >>>> >>>> Earlier in the thread, someone said that multiple identifiers might >>>> leak between different clients. Well, you might want them to share the >>>> multiple identifiers, but limiting identifier to one doesn't solve the >>>> leakage problem - so I don't think it's a reason to limit it to one. >>>> >>>> Still, multiple identifiers are always a problem - how do you tell >>>> them apart? Actually, I looked for a set of links that identified >>>> related records to the user - e,g, href=3D + rel=3D. I would prefer th= is >>>> over the existing approach >>>> >>>> Grahame >>>> >>>> >>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar) >>>> > wrote: >>>>> I would like to ask anyone that have real use cases for multi-valued >>>>>or >>>>> typed/complex externalID to bring them to the WG. I think it would >>>>> greatly >>>>> help better define this and make a decision on whether we need to >>>>> extend the >>>>> current definition or just clarify it. >>>>> >>>>> >>>>> Cheers, >>>>> Morteza >>>>> >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>>> >>>> >>>> -- >>>> ----- >>>> http://www.healthintersections.com.au / >>>> grahame@healthintersections.com.au / +61 411 867 065 >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >> -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au<= mailto:grahame@healthintersections.com.au> / +61 411 867 065 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D04E38F9FC8DFmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D6508C8FEB29D4A8CEABD158D003BF2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Speaking as an individual:

Here is an example of how externalID could be used for chaining ID=92s= cross multiple providers.  Note that this does NOT cover the case whe= re you go from many to one though.

The first client provisions users to service provider A from AD using = GUID as externalID.  Service provider A provisions to service provider= B and uses its =93id=94 as =93externalID=94, and so on.  The only thi= ng unique about externalID is the fact the client provisioning uses as a reference back to its own objects in its store. &nb= sp;Obviously as I said this excludes many to one scenarios which really was= the basic idea for targeting and I am sure sooner or later this will come = up, but I personally believe that can be handled using extensions semantics we have defined for the schema and p= rotocol.

I fully agree with you that the current language is underspecified and= should be tweaked to be more clear.


Cheers,
Morteza

From: Phil Hunt <phil.hunt@oracle.com>
Date: Friday, September 26, 2014 at= 6:06 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: Grahame Grieve <grahame@healthintersections.com.a= u>, "scim@ietf.org" &= lt;scim@ietf.org>, Chuck Mortimore <charliemortimo= re@gmail.com>
Subject: Re: [scim] Use cases for e= nhancements to externalID

I think an externid for enterprise to cloud and for saml subject match= ing (as Chuck mentioned) can create conflicts. 

I also wonder what happens over time when cloud to cloud scenarios occ= ur. Who then controls the value? Who is the owning client is not really def= ined well in a peer to peer case. 

I am neutral on this but I do find the current language underspecified= if it is to be single valued. 

Phil

On Sep 26, 2014, at 17:03, "Morteza Ansari (moransar)" <moransar@cisco.com> wrote:

Thanks for the additional info.  Wouldn=92t this be a classic cas= e of schema extension though?  In your example you probably need two d= istinct schema extensions, one for =93patient=94 and another for =93provide= r=94 where each extension defines the necessary attributes and semantics for that type of user and if the user happens to be both a p= atient in one context and a provider in another context, will have both ext= ensions.  I don=92t see how that links with externalID unless you cons= ider each of these providers a different authoritative source in which case you are going down the distributed attr= ibute provider which is probably a whole net set of use cases (interesting = use cases though).


Cheers,
Morteza

From: Grahame Grieve <grahame@healthintersections.com= .au>
Date: Monday, September 22, 2014 at= 6:08 PM
To: Morteza Ansari <moransar@cisco.com>
Cc: Chuck Mortimore <charliemortimore@gmail.com>, &quo= t;scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Use cases for e= nhancements to externalID

...from the right email this time...

Sure, I can expand. A couple of points:

Most uses of scim will use the user/group in the context of some = wider set of functionality. Either they can extend the scim user - a long w= ay - or they can link the user to their other context. For instance, in the= context of health, for which I am writing what will be a widely used spec, the user will correspond to either a= patient or a healthcare provider (or perhaps both, though most systems kee= p them far apart even when they're the same person). How is this link to be= established? It could either be from the scim user to the extarnal resource, or to the other way around, or bot= h. I'm thinking about which would be better, but if it's from the user to t= he external resource:
- it could be by reusing the external id. But the external id as descr= ibed by the spec and /or Phil's comments is not suitable for this use, and = it has other uses
- it could be by putting extensions into the resource. Perhaps this is= the intent, though I'm not sure why extarnalId is very different 
- it could done be adding a link property that has rel-type and href. = I'd use related, but there's a bunch of interesting ones here: ht= tp://www.iana.org/assignments/link-relations/link-relations.xhtml. = ;

That's the second - these links are used for hateos. I suppose that yo= u could confine them to the http header (in fact, we could use it that way = in my context too), but there's kind of a difference between workflow uses = and uses related to meaning - that's why HTML pages can include links in the page itself, not just in the heade= rs,,and why I think it would be a good idea to add them to the resource its= elf.mpossibly in the meta element

A couple of further comments:
- I'm still thinking about how the link should be made, and if the spe= c already answers think I missed it. But I think it will be a common use ca= se.
- I'm also interested in the by-play between links on the http headers= , and links in the resource as well. Is this as good an idea as I made it s= ound?

Grahame



On Tuesday, September 23, 2014, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
Can you please expand?



On 9/22/14, 4:33 PM, "Grahame Grieve" <grahameg@gmail.com> wrote:

>No, not for a complex external id, but I would like to have a set of >links for the user.
>
>Grahame
>
>> On 23 Sep 2014, at 8:34 am, "Morteza Ansari (moransar)"<= br> >><moransar@cisco.com> wrote:
>>
>> As far as I can tell nobody brought up any use cases for adding su= pport
>> for multi-valued or complex externalID.  I take that as conse= nsus to
>> clarify the spec and stating this is a single valued attribute and= move
>> forward.  If anyone objects to this, please speak up now.
>>
>>
>> Cheers,
>> Morteza
>>
>>> On 9/11/14, 7:53 AM, "Chuck Mortimore" <charliemortimore@gmail.com>
>>>wrote:
>>>
>>> externalid is there to provide a surrogate primary key for the= scim
>>> entity so it can be more easily addressed by scim consumers or=
>>>federation
>>> services.
>>>
>>> For example, if you are trying to provide single sign-on to a = cloud
>>> service, it is often more convenient for the IDP to use its lo= cal
>>> identifier for the user, rather than to update its schema and = store the
>>> identifier used by the cloud service.   So - it(or t= he provisions
>>>service
>>> it is paired with) would use scim to set its primary id for th= e user as
>>> externalid and send that as the subject of a SAML assertion. >>>
>>> - cmort
>>>
>>>> On Sep 10, 2014, at 10:58 PM, Grahame Grieve
>>>> <grahame@healthintersections.com.au> wrote:
>>>>
>>>> it's not clear what externalId is for. In a distributed sy= stem, it's
>>>> not unlikely that there will be multiple relevant other id= entifiers -
>>>> is there some notion of which is primary? For instance, I = need to map
>>>> between the User resource in the SCIM interface, and a Pat= ient record
>>>> in a different interface, so that the security engine know= s that this
>>>> user is the same as this patient. Should that be externalI= d, or should
>>>> it be somewhere else (an extension?). I didn't think that = the
>>>> definition of external id was quite clear enough to be sur= e. But if I
>>>> said to use externalId for that, what happens to other use= s of
>>>> externalId - same user on a different user record? (which = is why I
>>>> think I shouldn't use externalId for that)
>>>>
>>>> Earlier in the thread, someone said that multiple identifi= ers might
>>>> leak between different clients. Well, you might want them = to share the
>>>> multiple identifiers, but limiting identifier to one doesn= 't solve the
>>>> leakage problem - so I don't think it's a reason to limit = it to one.
>>>>
>>>> Still, multiple identifiers are always a problem - how do = you tell
>>>> them apart? Actually, I looked for a set of links that ide= ntified
>>>> related records to the user - e,g, href=3D + rel=3D. I= would prefer this
>>>> over the existing approach
>>>>
>>>> Grahame
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 9:45 AM, Morteza Ansari (moransar)=
>>>> <moransar@cisco.com> wrote:
>>>>> I would like to ask anyone that have real use cases fo= r multi-valued
>>>>>or
>>>>> typed/complex externalID to bring them to the WG. = ; I think it would
>>>>> greatly
>>>>> help better define this and make a decision on whether= we need to
>>>>> extend the
>>>>> current definition or just clarify it.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Morteza
>>>>>
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> scim@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> http://www.healthintersections.com.au /
>>>> grahame@healthintersections.com.au / +61 411 867 065
>>>>
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>



--
-----
http://= www.healthintersections.com.au / gra= hame@healthintersections.com.au / +61 411 867 065
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ie= tf.org/mailman/listinfo/scim
 --_000_D04E38F9FC8DFmoransarciscocom_-- From nobody Mon Sep 29 00:08:13 2014 Return-Path: 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 124F51A6FDB for ; Mon, 29 Sep 2014 00:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 UKddqIqHRONq for ; Mon, 29 Sep 2014 00:08:09 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FBC1A6FC2 for ; Mon, 29 Sep 2014 00:08:08 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so260293wid.13 for ; Mon, 29 Sep 2014 00:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=J05CueSoAdjwJPDwOTsbiwT40aIVRDFmTLfl94d0j7E=; b=GlFv+W8DGacGdIRFjsw8EFnpoIlnpNSGwrw9mxjlXGuyGLciwUf7mKQVILCECXtrKA isQU5c3WqbQ0qlmmPsPyEgLithWNPqvWIskkX8FYgoEGHEnH5M4oLX45SFafrBtHRJoV DTjzLkmW0jwKJ/zpELAOUGp0hV7aMdfC3gOj9cmvZtQTn5CSSJbkwElbM7HaRA04e/86 Cf6PPH8g31m9RqZaCm2v70tciWX3/eXM0DkCNoisa4UNXCvQI+ZS4MfD9nJ0zE3oORvR UL2vBWnzx7MswZe/7T8Sxd99nPovxLz19doEy7Ts3BKLXYqqHSn9PvT9x3N0kPYOcuxH 7JIg== MIME-Version: 1.0 X-Received: by 10.180.77.100 with SMTP id r4mr45160985wiw.1.1411974487567; Mon, 29 Sep 2014 00:08:07 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.77.199 with HTTP; Mon, 29 Sep 2014 00:08:07 -0700 (PDT) In-Reply-To: References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> Date: Mon, 29 Sep 2014 17:08:07 +1000 X-Google-Sender-Auth: 29pMmxbUnj3AQOQ_QLtQLQeXCiY Message-ID: From: Grahame Grieve To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/scim/K9YTvhXb1rAifZOyjjBPqw9UyyQ Cc: "scim@ietf.org" , Chuck Mortimore Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 07:08:11 -0000 well, it's an extension, I'll define one. Just seemed to me that it would be used often enough to be added to the base schema Grahame On Mon, Sep 29, 2014 at 3:13 PM, Morteza Ansari (moransar) wrote: > Speaking as an individual: Got it. But even in this scenario, it is an > schema extension but the new schema is simply a pointer (URL/URI?) to > patient and provider resources. > > > On 9/27/14, 3:20 AM, "Grahame Grieve" > wrote: > >>> Wouldn=C2=B9t this be a classic case of schema >>> extension though? In your example you probably need two distinct schem= a >>> extensions, one for =C2=B3patient=C2=B2 and another for =C2=B3provider= =C2=B2 where each >>> extension defines the necessary attributes and semantics for that type >>>of >>> user and if the user happens to be both a patient in one context and a >>> provider in another context, will have both extensions. >> >>no, because there are already resources for these with their own existing >>restful interface, and a bunch of defined behaviours etc. So all that is >>wanted in the SCIM user object is to link to the existing patient or >>provider resource >> >>> I don=C2=B9t see how >>> that links with externalID unless you consider each of these providers = a >>> different authoritative source in which case you are going down the >>> distributed attribute provider which is probably a whole net set of use >>> cases (interesting use cases though). >> >>no, it probably doesn't, as I read more, but is it necessary to add a >>schema extension to link a user to related external resources? If >>so, then that's what I'll have to do - but it seems to me that this >>will be a common extension. What, for instance, would facebook, >>dropbox or paypal do if they decided to implement SCIM? They would >>be in the same position, right - need to link from the SCIM user >>to the logical resource that links to the user in their business >>environment >> >>Grahame >> >>_______________________________________________ >>scim mailing list >>scim@ietf.org >>https://www.ietf.org/mailman/listinfo/scim > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 From nobody Mon Sep 29 02:00:35 2014 Return-Path: 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 55B711A8721 for ; Mon, 29 Sep 2014 02:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 dB9YzFTAbuzx for ; Mon, 29 Sep 2014 02:00:30 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF7E1A8720 for ; Mon, 29 Sep 2014 02:00:29 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 29 Sep 2014 11:00:23 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Mon, 29 Sep 2014 11:00:23 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4CAABnggIAGNwAAgACsbwCAAGsyAIACoxwA Date: Mon, 29 Sep 2014 09:00:22 +0000 Message-ID: <44EEE4A6-65B4-419D-B49C-711EA754132E@nexusgroup.com> References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.75.110.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2263ADE66382B54BA56270B3E1A99CCE@nexusgroup.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/AQTD7RyLX2DQxqNwSbbBHEPCJBI Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve , Morteza Ansari Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 09:00:33 -0000 My reasonings around externalID. in compact form :) - I think that Thomas was right on the money when he said. "SCIM server sho= uld obey Postel's law.=94. Core value is that is should be as simple as pos= sible to implement and to call SCIM service providers. I would like to just= send a SCIM core user that I have (of have found somewhere in my infrastru= cture :)) and parse the response without getting a bunch of errors if it=92= s a valid core user. - I also think that externalId is important to return. Makes it easier to d= evelop and verify the setup. - Don=92t make externalID multi-valued. It opens up a lot of questions arou= nd multi-tenancy from implementors that I think should be out of scope of t= he spec. We should not build into SCIM possibility for more users to clash = around one specific tenants users. If a service provider have that scenario= then it should be handled there. Not in spec. Once again, keep it simple t= o read, understand and to implement. If a client would like to use the exte= rnalID as subject in a SAML assertion, then it=92s up to the service provid= er to match it against that client. I don=92t really see (I=92m still to be= convinced :)) what=92s wrong with the current text around externalId in th= e core schema. Seems clear to me that a service provider should return a SC= IM user that=92s crafted against the current calling client when it comes t= o exernalID. Sorry for semi-hi-hacking the thread.=20 Cheers Erik On 27 Sep 2014, at 18:44, Phil Hunt wrote: > I=92m thinking out loud here (and may have this very wrong)=85. >=20 > The sense that I get from the group is that externalId is intended only a= s a lookup key for clients. Assigning meaning to externalId is not correct = usage. >=20 > It is ok to use externalId=3D{somekey} as a filter, but we should NOT be = using it for the purpose of holding a defined identifier value.=20 >=20 > Wrong: =93We put patient number in externalId so we can retrieve patient = numbers=94. =20 > Correct: Saying we put patient numbers in externalId so we can =93locate= =94 patients would be correct usage.=20 >=20 > Valid: give me the record whose externalId is 1234.=20 > Invalid: what is the externalId of this record. >=20 > Thinking of it this way, having externalId be multi-valued should not mat= ter. Nor should it matter which value is which. What matters is that a ma= tch can be found for a value. >=20 > A User schema can be extended to have an attribute patientNum as a specif= ic attribute. But it may also be useful to add the value to externalId if t= he client might not know if the record has been extended with the attribute= . It can use externalId as the general attribute to match keys against. >=20 > ExternalId is not meant to be retrieved (it might even be write only or n= ot returnable). It=92s purpose is for matching only. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 27, 2014, at 3:20 AM, Grahame Grieve wrote: >=20 >>> Wouldn=92t this be a classic case of schema >>> extension though? In your example you probably need two distinct schem= a >>> extensions, one for =93patient=94 and another for =93provider=94 where = each >>> extension defines the necessary attributes and semantics for that type = of >>> user and if the user happens to be both a patient in one context and a >>> provider in another context, will have both extensions. >>=20 >> no, because there are already resources for these with their own existin= g >> restful interface, and a bunch of defined behaviours etc. So all that is >> wanted in the SCIM user object is to link to the existing patient or >> provider resource >>=20 >>> I don=92t see how >>> that links with externalID unless you consider each of these providers = a >>> different authoritative source in which case you are going down the >>> distributed attribute provider which is probably a whole net set of use >>> cases (interesting use cases though). >>=20 >> no, it probably doesn't, as I read more, but is it necessary to add a >> schema extension to link a user to related external resources? If >> so, then that's what I'll have to do - but it seems to me that this >> will be a common extension. What, for instance, would facebook, >> dropbox or paypal do if they decided to implement SCIM? They would >> be in the same position, right - need to link from the SCIM user >> to the logical resource that links to the user in their business >> environment >>=20 >> Grahame >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Sep 29 08:43:02 2014 Return-Path: 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 6EEBC1A8823 for ; Mon, 29 Sep 2014 08:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 fhFtWdmRjmEd for ; Mon, 29 Sep 2014 08:42:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CD41A8822 for ; Mon, 29 Sep 2014 08:42:56 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8TFgptI007771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Sep 2014 15:42:53 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8TFgoCl016832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2014 15:42:51 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8TFgnBZ029654; Mon, 29 Sep 2014 15:42:49 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Sep 2014 08:42:48 -0700 References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> <44EEE4A6-65B4-419D-B49C-711EA754132E@nexusgroup.com> Mime-Version: 1.0 (1.0) In-Reply-To: <44EEE4A6-65B4-419D-B49C-711EA754132E@nexusgroup.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Mon, 29 Sep 2014 08:42:47 -0700 To: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1eBMJzbR9IKNrdQyC42kLBx3fPc Cc: "scim@ietf.org" , Chuck Mortimore , Grahame Grieve , Morteza Ansari Subject: Re: [scim] Use cases for enhancements to externalID X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:43:00 -0000 Ok. Thanks for all your input. I am feeling the group is leaning towards lea= ve as is.=20 I am happy to look at the text and make sure servers can do a different valu= e per subject/domain. I think it does a good job, but will confirm. One issu= e is what happens in the second client domain. Does it behave as if the valu= e was never set? Eg does a sfdc client(for saml subj match) see a different value than an ent= erprise client? Remember scim protocol client <> enterprise client. They both use scim and b= oth are technically protocol clients. However the implied owner here is the e= nterprise which some may be thinking is THE ONLY client. :-) Phil > On Sep 29, 2014, at 2:00, Erik Wahlstr=C3=B6m wrote: >=20 > My reasonings around externalID. in compact form :) >=20 > - I think that Thomas was right on the money when he said. "SCIM server sh= ould obey Postel's law.=E2=80=9D. Core value is that is should be as simple a= s possible to implement and to call SCIM service providers. I would like to j= ust send a SCIM core user that I have (of have found somewhere in my infrast= ructure :)) and parse the response without getting a bunch of errors if it=E2= =80=99s a valid core user. > - I also think that externalId is important to return. Makes it easier to d= evelop and verify the setup. > - Don=E2=80=99t make externalID multi-valued. It opens up a lot of questio= ns around multi-tenancy from implementors that I think should be out of scop= e of the spec. We should not build into SCIM possibility for more users to c= lash around one specific tenants users. If a service provider have that scen= ario then it should be handled there. Not in spec. Once again, keep it simpl= e to read, understand and to implement. If a client would like to use the ex= ternalID as subject in a SAML assertion, then it=E2=80=99s up to the service= provider to match it against that client. I don=E2=80=99t really see (I=E2=80= =99m still to be convinced :)) what=E2=80=99s wrong with the current text ar= ound externalId in the core schema. Seems clear to me that a service provide= r should return a SCIM user that=E2=80=99s crafted against the current calli= ng client when it comes to exernalID. >=20 > Sorry for semi-hi-hacking the thread.=20 > Cheers > Erik >=20 >=20 >> On 27 Sep 2014, at 18:44, Phil Hunt wrote: >>=20 >> I=E2=80=99m thinking out loud here (and may have this very wrong)=E2=80=A6= . >>=20 >> The sense that I get from the group is that externalId is intended only a= s a lookup key for clients. Assigning meaning to externalId is not correct u= sage. >>=20 >> It is ok to use externalId=3D{somekey} as a filter, but we should NOT be u= sing it for the purpose of holding a defined identifier value.=20 >>=20 >> Wrong: =E2=80=9CWe put patient number in externalId so we can retrieve pa= tient numbers=E2=80=9D. =20 >> Correct: Saying we put patient numbers in externalId so we can =E2=80=9Cl= ocate=E2=80=9D patients would be correct usage.=20 >>=20 >> Valid: give me the record whose externalId is 1234.=20 >> Invalid: what is the externalId of this record. >>=20 >> Thinking of it this way, having externalId be multi-valued should not mat= ter. Nor should it matter which value is which. What matters is that a mat= ch can be found for a value. >>=20 >> A User schema can be extended to have an attribute patientNum as a specif= ic attribute. But it may also be useful to add the value to externalId if th= e client might not know if the record has been extended with the attribute. I= t can use externalId as the general attribute to match keys against. >>=20 >> ExternalId is not meant to be retrieved (it might even be write only or n= ot returnable). It=E2=80=99s purpose is for matching only. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 27, 2014, at 3:20 AM, Grahame Grieve wrote: >>=20 >>>> Wouldn=E2=80=99t this be a classic case of schema >>>> extension though? In your example you probably need two distinct schem= a >>>> extensions, one for =E2=80=9Cpatient=E2=80=9D and another for =E2=80=9C= provider=E2=80=9D where each >>>> extension defines the necessary attributes and semantics for that type o= f >>>> user and if the user happens to be both a patient in one context and a >>>> provider in another context, will have both extensions. >>>=20 >>> no, because there are already resources for these with their own existin= g >>> restful interface, and a bunch of defined behaviours etc. So all that is= >>> wanted in the SCIM user object is to link to the existing patient or >>> provider resource >>>=20 >>>> I don=E2=80=99t see how >>>> that links with externalID unless you consider each of these providers a= >>>> different authoritative source in which case you are going down the >>>> distributed attribute provider which is probably a whole net set of use= >>>> cases (interesting use cases though). >>>=20 >>> no, it probably doesn't, as I read more, but is it necessary to add a >>> schema extension to link a user to related external resources? If >>> so, then that's what I'll have to do - but it seems to me that this >>> will be a common extension. What, for instance, would facebook, >>> dropbox or paypal do if they decided to implement SCIM? They would >>> be in the same position, right - need to link from the SCIM user >>> to the logical resource that links to the user in their business >>> environment >>>=20 >>> Grahame >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 From nobody Mon Sep 29 10:32:52 2014 Return-Path: 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 443281A8F37 for ; Mon, 29 Sep 2014 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 pTgZyR7Th0MQ for ; Mon, 29 Sep 2014 10:32:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244271A8F39 for ; Mon, 29 Sep 2014 10:32:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8THWjLL025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Sep 2014 17:32:46 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8THWiFQ008399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Sep 2014 17:32:45 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8THWhMN003733 for ; Mon, 29 Sep 2014 17:32:44 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Sep 2014 10:32:42 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_670BE9F8-5C50-4B52-AC53-D3D956386659" Message-Id: Date: Mon, 29 Sep 2014 10:32:41 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ICC5JKqwjw-3wuNH5jhAvsVOj6I Subject: [scim] Localizable group names X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 17:32:49 -0000 --Apple-Mail=_670BE9F8-5C50-4B52-AC53-D3D956386659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Please comment and if possible answer the embedded question below=85 I=92ve received a question on how to handle localization of groups = names. The current =93displayName=94 is single valued and thus can only support = one localized value. E.g. you can create a group name in Dutch, but = then it can=92t be displayed in english (nor can multiple locale names = be maintained through scim) unless you create multiple groups (which = causes other problems).=20 While displayName for Group and User is consistent and is acceptable, = groups have the additional problem of needing to be understood in = multiple languages at the same time =97 particularly groups that drive = access controls. We considered doing this with ALH and =93displayName=94 but we are = concerned about it causing other issues as many systems may be using = displayName as a fixed key (whether this is good is another discussion). We are now considering using a schema extension (e.g. enterprise Group), = but it seems like this would be more usefully done in an inter-operable = way as part of Group core schema. Question: Would the group support a new multi-valued attribute called = =93globalNames=94 that can be used to maintain and retrieve multiple = localized names for the same group? Under Multi-valued attributes for Group: globalNames An optional multi-valued attribute containing group names for = specific locales. For each localized value, the corresponding =93type=94 = sub-attribute is a language tag as defined in [RFC5646]. =20 This is a change, but it is an optional addition and seems minor. Service providers that do not plan to support would have to simply = ignore the value (they should be ignoring attributes they don=92t = understand anyway). Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_670BE9F8-5C50-4B52-AC53-D3D956386659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Please comment and if possible answer the = embedded question below=85

<individual = hat>
I=92ve received a question on how to handle localization of = groups names.

The current =93displayName=94 is single = valued and thus can only support one localized value.  E.g. you can = create a group name in Dutch, but then it can=92t be displayed in = english (nor can multiple locale names be maintained through scim) = unless you create multiple groups (which causes other = problems). 

While displayName for Group = and User is consistent and is acceptable, groups have the additional = problem of needing to be understood in multiple languages at the same = time =97 particularly groups that drive access = controls.

We considered doing this with ALH and = =93displayName=94 but we are concerned about it causing other issues as = many systems may be using displayName as a fixed key (whether this is = good is another discussion).

We are now = considering using a schema extension (e.g. enterprise Group), but it = seems like this would be more usefully done in an inter-operable way as = part of Group core schema.

Question: = Would the group support a new multi-valued attribute called = =93globalNames=94 that can be used to maintain and retrieve multiple = localized names for the same = group?

Under Multi-valued attributes = for Group:

globalNames
  =  An optional multi-valued attribute containing group names for = specific locales. For each localized value, the corresponding =93type=94 = sub-attribute is a language tag as defined in = [RFC5646].
 
</individual = hat>

<editor>
This is a = change, but it is an optional addition and seems = minor.

Service providers that do not plan to = support would have to simply ignore the value (they should be ignoring = attributes they don=92t understand = anyway).
</editor>

Phil
= --Apple-Mail=_670BE9F8-5C50-4B52-AC53-D3D956386659-- From nobody Mon Sep 29 12:51:21 2014 Return-Path: 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 1BE9C1ABD3B for ; Mon, 29 Sep 2014 12:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 S9kM1dFY6SLP for ; Mon, 29 Sep 2014 12:51:17 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96761A9308 for ; Mon, 29 Sep 2014 12:51:16 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so14120346wgh.24 for ; Mon, 29 Sep 2014 12:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t5Co0II0fQwiODaRlmAJKuaJeoi8u8JnV+nT+OVVE9c=; b=GIX7pvdMlhn1ocxktA5LNNpOfmdTBYC+3MOiliiocdhP1s0ZwJB77x2K48AR72SQqe jLWG6w9wIAaBv1/LOCt/AfSYyFyG7l9T/sVxSz3sRxRH1XQyrSLhZLAC/RKNlZrjptTb ZbNqPaJJbuGTPIRIxy8Pz7Wf38xiOTOAd1BE2Wkgegg19jlAQZNaY1bYaXmLvfHqBrZy iM8XDCv10juYMtnUxYpTPuZ92heE1/1pG/QuCXSwgJUGo0ifVyb67l7wQROZ0+uDrRFo 2NDc9X0zZwF89Ia/MovFUqRvsaFX1SdeUTBB1mtofM9NkxHDHFQjWS80+JYyvgvFteyt DPHA== MIME-Version: 1.0 X-Received: by 10.194.185.14 with SMTP id ey14mr14076116wjc.91.1412020275521; Mon, 29 Sep 2014 12:51:15 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.77.199 with HTTP; Mon, 29 Sep 2014 12:51:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 05:51:15 +1000 X-Google-Sender-Auth: ZHFOw-Qb0YbJGUgXjfTzvhlxau0 Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7bd6b040f0301005043996c6 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/jGDTmxR3wqZksCV58HwudjXAGyQ Cc: SCIM WG Subject: Re: [scim] Localizable group names X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:51:19 -0000 --047d7bd6b040f0301005043996c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you're really going to consider localization issues with names, a single displayName for a user is a problem - the question is not which language it is in, but which script - many systems support recording names in both Latin and local script, since some users can't read This would appear to be relevant for group name too Grahame On Tuesday, September 30, 2014, Phil Hunt wrote: > Please comment and if possible answer the embedded question below=E2=80= =A6 > > > I=E2=80=99ve received a question on how to handle localization of groups = names. > > The current =E2=80=9CdisplayName=E2=80=9D is single valued and thus can o= nly support one > localized value. E.g. you can create a group name in Dutch, but then it > can=E2=80=99t be displayed in english (nor can multiple locale names be m= aintained > through scim) unless you create multiple groups (which causes other > problems). > > While displayName for Group and User is consistent and is acceptable, > groups have the additional problem of needing to be understood in multipl= e > languages at the same time =E2=80=94 particularly groups that drive acces= s controls. > > We considered doing this with ALH and =E2=80=9CdisplayName=E2=80=9D but w= e are concerned > about it causing other issues as many systems may be using displayName as= a > fixed key (whether this is good is another discussion). > > We are now considering using a schema extension (e.g. enterprise Group), > but it seems like this would be more usefully done in an inter-operable w= ay > as part of Group core schema. > > *Question: Would the group support a new multi-valued attribute called > =E2=80=9CglobalNames=E2=80=9D that can be used to maintain and retrieve m= ultiple localized > names for the same group?* > > Under Multi-valued attributes for Group: > > globalNames > An optional multi-valued attribute containing group names for specific > locales. For each localized value, the corresponding =E2=80=9Ctype=E2=80= =9D sub-attribute > is a language tag as defined in [RFC5646]. > > > > > This is a change, but it is an optional addition and seems minor. > > Service providers that do not plan to support would have to simply ignore > the value (they should be ignoring attributes they don=E2=80=99t understa= nd anyway). > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --047d7bd6b040f0301005043996c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you're really going to consider localization issues with names, a si= ngle displayName for a user is a problem - the question is not which langua= ge it is in, but which script - many systems support recording names in bot= h Latin and local script, since some=C2=A0users can't read=C2=A0
This would appear to be relevant for group name too
=
Grahame=C2=A0

On Tuesday, September 30, 2= 014, Phil Hunt <phil.hunt@oracle= .com> wrote:
Please comment and if possible answer the embedded ques= tion below=E2=80=A6

<individual hat>
I= =E2=80=99ve received a question on how to handle localization of groups nam= es.

The current =E2=80=9CdisplayName=E2=80=9D is single = valued and thus can only support one localized value.=C2=A0 E.g. you can cr= eate a group name in Dutch, but then it can=E2=80=99t be displayed in engli= sh (nor can multiple locale names be maintained through scim) unless you cr= eate multiple groups (which causes other problems).=C2=A0

While displayName for Group and User is consistent and is acceptabl= e, groups have the additional problem of needing to be understood in multip= le languages at the same time =E2=80=94 particularly groups that drive acce= ss controls.

We considered doing this with ALH and= =E2=80=9CdisplayName=E2=80=9D but we are concerned about it causing other = issues as many systems may be using displayName as a fixed key (whether thi= s is good is another discussion).

We are now consi= dering using a schema extension (e.g. enterprise Group), but it seems like = this would be more usefully done in an inter-operable way as part of Group = core schema.

Question: Would the group suppo= rt a new multi-valued attribute called =E2=80=9CglobalNames=E2=80=9D that c= an be used to maintain and retrieve multiple localized names for the same g= roup?

Under Multi-valued attributes for Gr= oup:

globalNames=
=C2=A0 =C2=A0An optional multi-valued= attribute containing group names for specific locales. For each localized = value, the corresponding =E2=80=9Ctype=E2=80=9D sub-attribute is a language= tag as defined in [RFC5646].
=C2=A0
</indivi= dual hat>

<editor>
This is a ch= ange, but it is an optional addition and seems minor.

<= div>Service providers that do not plan to support would have to simply igno= re the value (they should be ignoring attributes they don=E2=80=99t underst= and anyway).
</editor>

Phil

@independentid
www.independentid.= com
phil.hunt@oracle.com<= /div>





--
-----
http://www.health= intersections.com.au / grahame@healthintersections.com.au / +61 411 86= 7 065
--047d7bd6b040f0301005043996c6-- From nobody Mon Sep 29 12:54:37 2014 Return-Path: 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 6A26A1ABB1A for ; Mon, 29 Sep 2014 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 VEVsHhDCwDUC for ; Mon, 29 Sep 2014 12:54:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CFF1A930A for ; Mon, 29 Sep 2014 12:54:32 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 19:54:07 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.203]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.203]) with mapi id 15.00.1039.011; Mon, 29 Sep 2014 19:54:07 +0000 From: Kelly Grizzle To: Grahame Grieve , Phil Hunt Thread-Topic: [scim] Localizable group names Thread-Index: AQHP3Atp1xD0Lvg2s0+Ks5hUQbz7cZwYhV2AgAAAhvA= Date: Mon, 29 Sep 2014 19:54:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 011A236D0082FC011A24BA x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [97.79.140.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB389; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(199003)(377454003)(19300405004)(19609705001)(83322001)(19580395003)(90102001)(15975445006)(15202345003)(99396003)(101416001)(19580405001)(10300001)(120916001)(97736003)(108616004)(66066001)(64706001)(85306004)(16236675004)(20776003)(74316001)(83072002)(81542003)(46102003)(80022003)(85852003)(86362001)(77982003)(79102003)(92566001)(81342003)(19625215002)(16601075003)(31966008)(21056001)(54356999)(107046002)(2656002)(87936001)(76176999)(50986999)(76482002)(77096002)(74502003)(74662003)(4396001)(95666004)(76576001)(105586002)(33646002)(106356001)(19617315012)(99286002)(106116001)(24736002)(9078065003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_fa111afb8bb3458f82c827189e6f1bf5BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Archived-At: http://mailarchive.ietf.org/arch/msg/scim/MIJPM4KkQOgc0dDXCKxx2wLsWcY Cc: SCIM WG Subject: Re: [scim] Localizable group names X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:54:35 -0000 --_000_fa111afb8bb3458f82c827189e6f1bf5BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIHBhc3Qgd2UgaGF2ZSByZWNvbW1lbmRlZCBwZW9wbGUgdGhhdCBhcmUgY29uY2VybmVk IHdpdGggaTE4buKAmWQgdmFsdWVzIHRvIHVzZSBleHRlbnNpb25zLiAgVGhpcyBwcm9ibGVtIGxp a2VseSBnb2VzIGJleW9uZCB0aGUgbmFtZXMgb2YgZ3JvdXBzIGFuZCB1c2Vycywgc28gbXkgcHJl ZmVyZW5jZSBpcyB0byBsZXQgaW1wbGVtZW50ZXJzIGRvIHRoaXMgaW4gYW4gZXh0ZW5zaW9uLg0K DQpGcm9tOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg R3JhaGFtZSBHcmlldmUNClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDI6NTEgUE0N ClRvOiBQaGlsIEh1bnQNCkNjOiBTQ0lNIFdHDQpTdWJqZWN0OiBSZTogW3NjaW1dIExvY2FsaXph YmxlIGdyb3VwIG5hbWVzDQoNCklmIHlvdSdyZSByZWFsbHkgZ29pbmcgdG8gY29uc2lkZXIgbG9j YWxpemF0aW9uIGlzc3VlcyB3aXRoIG5hbWVzLCBhIHNpbmdsZSBkaXNwbGF5TmFtZSBmb3IgYSB1 c2VyIGlzIGEgcHJvYmxlbSAtIHRoZSBxdWVzdGlvbiBpcyBub3Qgd2hpY2ggbGFuZ3VhZ2UgaXQg aXMgaW4sIGJ1dCB3aGljaCBzY3JpcHQgLSBtYW55IHN5c3RlbXMgc3VwcG9ydCByZWNvcmRpbmcg bmFtZXMgaW4gYm90aCBMYXRpbiBhbmQgbG9jYWwgc2NyaXB0LCBzaW5jZSBzb21lIHVzZXJzIGNh bid0IHJlYWQNCg0KVGhpcyB3b3VsZCBhcHBlYXIgdG8gYmUgcmVsZXZhbnQgZm9yIGdyb3VwIG5h bWUgdG9vDQoNCkdyYWhhbWUNCg0KT24gVHVlc2RheSwgU2VwdGVtYmVyIDMwLCAyMDE0LCBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+ IHdyb3RlOg0KUGxlYXNlIGNvbW1lbnQgYW5kIGlmIHBvc3NpYmxlIGFuc3dlciB0aGUgZW1iZWRk ZWQgcXVlc3Rpb24gYmVsb3figKYNCg0KPGluZGl2aWR1YWwgaGF0Pg0KSeKAmXZlIHJlY2VpdmVk IGEgcXVlc3Rpb24gb24gaG93IHRvIGhhbmRsZSBsb2NhbGl6YXRpb24gb2YgZ3JvdXBzIG5hbWVz Lg0KDQpUaGUgY3VycmVudCDigJxkaXNwbGF5TmFtZeKAnSBpcyBzaW5nbGUgdmFsdWVkIGFuZCB0 aHVzIGNhbiBvbmx5IHN1cHBvcnQgb25lIGxvY2FsaXplZCB2YWx1ZS4gIEUuZy4geW91IGNhbiBj cmVhdGUgYSBncm91cCBuYW1lIGluIER1dGNoLCBidXQgdGhlbiBpdCBjYW7igJl0IGJlIGRpc3Bs YXllZCBpbiBlbmdsaXNoIChub3IgY2FuIG11bHRpcGxlIGxvY2FsZSBuYW1lcyBiZSBtYWludGFp bmVkIHRocm91Z2ggc2NpbSkgdW5sZXNzIHlvdSBjcmVhdGUgbXVsdGlwbGUgZ3JvdXBzICh3aGlj aCBjYXVzZXMgb3RoZXIgcHJvYmxlbXMpLg0KDQpXaGlsZSBkaXNwbGF5TmFtZSBmb3IgR3JvdXAg YW5kIFVzZXIgaXMgY29uc2lzdGVudCBhbmQgaXMgYWNjZXB0YWJsZSwgZ3JvdXBzIGhhdmUgdGhl IGFkZGl0aW9uYWwgcHJvYmxlbSBvZiBuZWVkaW5nIHRvIGJlIHVuZGVyc3Rvb2QgaW4gbXVsdGlw bGUgbGFuZ3VhZ2VzIGF0IHRoZSBzYW1lIHRpbWUg4oCUIHBhcnRpY3VsYXJseSBncm91cHMgdGhh dCBkcml2ZSBhY2Nlc3MgY29udHJvbHMuDQoNCldlIGNvbnNpZGVyZWQgZG9pbmcgdGhpcyB3aXRo IEFMSCBhbmQg4oCcZGlzcGxheU5hbWXigJ0gYnV0IHdlIGFyZSBjb25jZXJuZWQgYWJvdXQgaXQg Y2F1c2luZyBvdGhlciBpc3N1ZXMgYXMgbWFueSBzeXN0ZW1zIG1heSBiZSB1c2luZyBkaXNwbGF5 TmFtZSBhcyBhIGZpeGVkIGtleSAod2hldGhlciB0aGlzIGlzIGdvb2QgaXMgYW5vdGhlciBkaXNj dXNzaW9uKS4NCg0KV2UgYXJlIG5vdyBjb25zaWRlcmluZyB1c2luZyBhIHNjaGVtYSBleHRlbnNp b24gKGUuZy4gZW50ZXJwcmlzZSBHcm91cCksIGJ1dCBpdCBzZWVtcyBsaWtlIHRoaXMgd291bGQg YmUgbW9yZSB1c2VmdWxseSBkb25lIGluIGFuIGludGVyLW9wZXJhYmxlIHdheSBhcyBwYXJ0IG9m IEdyb3VwIGNvcmUgc2NoZW1hLg0KDQpRdWVzdGlvbjogV291bGQgdGhlIGdyb3VwIHN1cHBvcnQg YSBuZXcgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZSBjYWxsZWQg4oCcZ2xvYmFsTmFtZXPigJ0gdGhh dCBjYW4gYmUgdXNlZCB0byBtYWludGFpbiBhbmQgcmV0cmlldmUgbXVsdGlwbGUgbG9jYWxpemVk IG5hbWVzIGZvciB0aGUgc2FtZSBncm91cD8NCg0KVW5kZXIgTXVsdGktdmFsdWVkIGF0dHJpYnV0 ZXMgZm9yIEdyb3VwOg0KDQpnbG9iYWxOYW1lcw0KICAgQW4gb3B0aW9uYWwgbXVsdGktdmFsdWVk IGF0dHJpYnV0ZSBjb250YWluaW5nIGdyb3VwIG5hbWVzIGZvciBzcGVjaWZpYyBsb2NhbGVzLiBG b3IgZWFjaCBsb2NhbGl6ZWQgdmFsdWUsIHRoZSBjb3JyZXNwb25kaW5nIOKAnHR5cGXigJ0gc3Vi LWF0dHJpYnV0ZSBpcyBhIGxhbmd1YWdlIHRhZyBhcyBkZWZpbmVkIGluIFtSRkM1NjQ2XS4NCg0K PC9pbmRpdmlkdWFsIGhhdD4NCg0KPGVkaXRvcj4NClRoaXMgaXMgYSBjaGFuZ2UsIGJ1dCBpdCBp cyBhbiBvcHRpb25hbCBhZGRpdGlvbiBhbmQgc2VlbXMgbWlub3IuDQoNClNlcnZpY2UgcHJvdmlk ZXJzIHRoYXQgZG8gbm90IHBsYW4gdG8gc3VwcG9ydCB3b3VsZCBoYXZlIHRvIHNpbXBseSBpZ25v cmUgdGhlIHZhbHVlICh0aGV5IHNob3VsZCBiZSBpZ25vcmluZyBhdHRyaWJ1dGVzIHRoZXkgZG9u 4oCZdCB1bmRlcnN0YW5kIGFueXdheSkuDQo8L2VkaXRvcj4NCg0KUGhpbA0KDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+ DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3BoaWwu aHVudEBvcmFjbGUuY29tJyk7Pg0KDQoNCg0KDQoNCi0tDQotLS0tLQ0KaHR0cDovL3d3dy5oZWFs dGhpbnRlcnNlY3Rpb25zLmNvbS5hdSAvIGdyYWhhbWVAaGVhbHRoaW50ZXJzZWN0aW9ucy5jb20u YXU8bWFpbHRvOmdyYWhhbWVAaGVhbHRoaW50ZXJzZWN0aW9ucy5jb20uYXU+IC8gKzYxIDQxMSA4 NjcgMDY1DQo= --_000_fa111afb8bb3458f82c827189e6f1bf5BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBwYXN0IHdlIGhhdmUgcmVjb21tZW5kZWQgcGVvcGxl IHRoYXQgYXJlIGNvbmNlcm5lZCB3aXRoIGkxOG7igJlkIHZhbHVlcyB0byB1c2UgZXh0ZW5zaW9u cy4mbmJzcDsgVGhpcyBwcm9ibGVtIGxpa2VseSBnb2VzIGJleW9uZCB0aGUgbmFtZXMgb2YgZ3Jv dXBzIGFuZCB1c2VycywNCiBzbyBteSBwcmVmZXJlbmNlIGlzIHRvIGxldCBpbXBsZW1lbnRlcnMg ZG8gdGhpcyBpbiBhbiBleHRlbnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5HcmFoYW1lIEdyaWV2ZTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRl bWJlciAyOSwgMjAxNCAyOjUxIFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQ8YnI+DQo8Yj5D Yzo8L2I+IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBMb2NhbGl6YWJs ZSBncm91cCBuYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91J3JlIHJl YWxseSBnb2luZyB0byBjb25zaWRlciBsb2NhbGl6YXRpb24gaXNzdWVzIHdpdGggbmFtZXMsIGEg c2luZ2xlIGRpc3BsYXlOYW1lIGZvciBhIHVzZXIgaXMgYSBwcm9ibGVtIC0gdGhlIHF1ZXN0aW9u IGlzIG5vdCB3aGljaCBsYW5ndWFnZSBpdCBpcyBpbiwgYnV0IHdoaWNoIHNjcmlwdCAtIG1hbnkg c3lzdGVtcyBzdXBwb3J0IHJlY29yZGluZyBuYW1lcyBpbiBib3RoIExhdGluIGFuZCBsb2NhbA0K IHNjcmlwdCwgc2luY2Ugc29tZSZuYnNwO3VzZXJzIGNhbid0IHJlYWQmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd291bGQgYXBwZWFyIHRv IGJlIHJlbGV2YW50IGZvciBncm91cCBuYW1lIHRvbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmFoYW1lJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gVHVl c2RheSwgU2VwdGVtYmVyIDMwLCAyMDE0LCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IGNvbW1lbnQgYW5kIGlmIHBvc3NpYmxlIGFuc3dlciB0aGUgZW1iZWRkZWQgcXVlc3Rpb24gYmVs b3figKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmx0O2luZGl2aWR1YWwgaGF0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5J4oCZdmUgcmVjZWl2ZWQgYSBxdWVzdGlvbiBvbiBob3cgdG8gaGFuZGxl IGxvY2FsaXphdGlvbiBvZiBncm91cHMgbmFtZXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCDigJxkaXNwbGF5TmFtZeKAnSBpcyBzaW5n bGUgdmFsdWVkIGFuZCB0aHVzIGNhbiBvbmx5IHN1cHBvcnQgb25lIGxvY2FsaXplZCB2YWx1ZS4m bmJzcDsgRS5nLiB5b3UgY2FuIGNyZWF0ZSBhIGdyb3VwIG5hbWUgaW4gRHV0Y2gsIGJ1dCB0aGVu IGl0IGNhbuKAmXQgYmUgZGlzcGxheWVkIGluIGVuZ2xpc2ggKG5vciBjYW4gbXVsdGlwbGUgbG9j YWxlIG5hbWVzIGJlIG1haW50YWluZWQgdGhyb3VnaCBzY2ltKSB1bmxlc3MNCiB5b3UgY3JlYXRl IG11bHRpcGxlIGdyb3VwcyAod2hpY2ggY2F1c2VzIG90aGVyIHByb2JsZW1zKS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUg ZGlzcGxheU5hbWUgZm9yIEdyb3VwIGFuZCBVc2VyIGlzIGNvbnNpc3RlbnQgYW5kIGlzIGFjY2Vw dGFibGUsIGdyb3VwcyBoYXZlIHRoZSBhZGRpdGlvbmFsIHByb2JsZW0gb2YgbmVlZGluZyB0byBi ZSB1bmRlcnN0b29kIGluIG11bHRpcGxlIGxhbmd1YWdlcyBhdCB0aGUgc2FtZSB0aW1lIOKAlCBw YXJ0aWN1bGFybHkgZ3JvdXBzIHRoYXQgZHJpdmUgYWNjZXNzIGNvbnRyb2xzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjb25zaWRlcmVk IGRvaW5nIHRoaXMgd2l0aCBBTEggYW5kIOKAnGRpc3BsYXlOYW1l4oCdIGJ1dCB3ZSBhcmUgY29u Y2VybmVkIGFib3V0IGl0IGNhdXNpbmcgb3RoZXIgaXNzdWVzIGFzIG1hbnkgc3lzdGVtcyBtYXkg YmUgdXNpbmcgZGlzcGxheU5hbWUgYXMgYSBmaXhlZCBrZXkgKHdoZXRoZXIgdGhpcyBpcyBnb29k IGlzIGFub3RoZXIgZGlzY3Vzc2lvbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBub3cgY29uc2lkZXJpbmcgdXNpbmcgYSBzY2hl bWEgZXh0ZW5zaW9uIChlLmcuIGVudGVycHJpc2UgR3JvdXApLCBidXQgaXQgc2VlbXMgbGlrZSB0 aGlzIHdvdWxkIGJlIG1vcmUgdXNlZnVsbHkgZG9uZSBpbiBhbiBpbnRlci1vcGVyYWJsZSB3YXkg YXMgcGFydCBvZiBHcm91cCBjb3JlIHNjaGVtYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+UXVlc3Rpb246IFdvdWxkIHRoZSBncm91 cCBzdXBwb3J0IGEgbmV3IG11bHRpLXZhbHVlZCBhdHRyaWJ1dGUgY2FsbGVkIOKAnGdsb2JhbE5h bWVz4oCdIHRoYXQgY2FuIGJlIHVzZWQgdG8gbWFpbnRhaW4gYW5kIHJldHJpZXZlIG11bHRpcGxl IGxvY2FsaXplZCBuYW1lcyBmb3IgdGhlIHNhbWUgZ3JvdXA/PC91PjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5kZXIgTXVsdGktdmFs dWVkIGF0dHJpYnV0ZXMgZm9yIEdyb3VwOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPmdsb2JhbE5hbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7QW4gb3B0aW9uYWwgbXVsdGktdmFs dWVkIGF0dHJpYnV0ZSBjb250YWluaW5nIGdyb3VwIG5hbWVzIGZvciBzcGVjaWZpYyBsb2NhbGVz LiBGb3IgZWFjaCBsb2NhbGl6ZWQgdmFsdWUsIHRoZSBjb3JyZXNwb25kaW5nIOKAnHR5cGXigJ0g c3ViLWF0dHJpYnV0ZSBpcyBhIGxhbmd1YWdlIHRhZyBhcyBkZWZpbmVkIGluIFtSRkM1NjQ2XS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZsdDsvaW5kaXZpZHVhbCBoYXQmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtlZGl0b3ImZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgY2hhbmdlLCBidXQg aXQgaXMgYW4gb3B0aW9uYWwgYWRkaXRpb24gYW5kIHNlZW1zIG1pbm9yLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXJ2aWNlIHByb3ZpZGVy cyB0aGF0IGRvIG5vdCBwbGFuIHRvIHN1cHBvcnQgd291bGQgaGF2ZSB0byBzaW1wbHkgaWdub3Jl IHRoZSB2YWx1ZSAodGhleSBzaG91bGQgYmUgaWdub3JpbmcgYXR0cmlidXRlcyB0aGV5IGRvbuKA mXQgdW5kZXJzdGFuZCBhbnl3YXkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9lZGl0b3ImZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp ZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwn LCdwaGlsLmh1bnRAb3JhY2xlLmNvbScpOyIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Ci0tIDxicj4NCi0tLS0tPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5oZWFsdGhpbnRlcnNlY3Rp b25zLmNvbS5hdSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaGVhbHRoaW50ZXJzZWN0aW9u cy5jb20uYXU8L2E+IC8NCjxhIGhyZWY9Im1haWx0bzpncmFoYW1lQGhlYWx0aGludGVyc2VjdGlv bnMuY29tLmF1IiB0YXJnZXQ9Il9ibGFuayI+Z3JhaGFtZUBoZWFsdGhpbnRlcnNlY3Rpb25zLmNv bS5hdTwvYT4gLyAmIzQzOzYxIDQxMSA4NjcgMDY1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_fa111afb8bb3458f82c827189e6f1bf5BN1PR04MB392namprd04pro_--