From nobody Wed Oct 1 05: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 70CE41A0345 for ; Wed, 1 Oct 2014 05:08:31 -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 2NuN7YAx9IGW for ; Wed, 1 Oct 2014 05:08:28 -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 D87791A034B for ; Wed, 1 Oct 2014 05:08:27 -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; Wed, 1 Oct 2014 14:08:25 +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; Wed, 1 Oct 2014 14:08:24 +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; Wed, 1 Oct 2014 14:08:24 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] Use cases for enhancements to externalID Thread-Index: AQHPzVFaHoydbrH+gUO2YQWumB1Unpv7xAsAgACVYACAEVUTgIAAhc6A//+Lh4CAABnggIAGNwAAgACsbwCAAGsyAIACoxwAgABwb4CAAui5gA== Date: Wed, 1 Oct 2014 12:08:24 +0000 Message-ID: <9733ED43-A97A-46B3-AC86-55217D8DBEC5@nexusgroup.com> References: <21B090C1-55C2-494E-9549-029B36A16CBA@gmail.com> <44EEE4A6-65B4-419D-B49C-711EA754132E@nexusgroup.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: [194.154.201.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <471F5DBC08F7B1438C36DBC64B2E2B0D@nexusgroup.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/eYRUmvQwsksEpGkx9tOVZsqK538 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: Wed, 01 Oct 2014 12:08:31 -0000 On 29 Sep 2014, at 17:42, Phil Hunt wrote: > Ok. Thanks for all your input. I am feeling the group is leaning towards = leave as is.=20 >=20 > I am happy to look at the text and make sure servers can do a different v= alue per subject/domain. I think it does a good job, but will confirm. One = issue is what happens in the second client domain. Does it behave as if the= value was never set? Yes. But I=92m thinking it=92s up to the Service Provider to define it. Not= the spec. Will miss todays call. Will be mid air :( / Erik From darshanasbg@gmail.com Wed Oct 1 07:36: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 332141ACDF6 for ; Wed, 1 Oct 2014 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_LOTTO_NAME=1, 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 m-B7n060qTlA for ; Wed, 1 Oct 2014 07:36:40 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D351ACDD1 for ; Wed, 1 Oct 2014 07:36:39 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so448059lbi.36 for ; Wed, 01 Oct 2014 07:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ihhPAWz5EKEhOL0DrPk2MBEJJiaSlnWaLO+ib/XMaHw=; b=pPFQVUouKDtPz2Faej6tsiyZoq6ymNIkFWbtTY12pjPBrJChfItPR+bJSZFmxnGdk/ AHAJFiU6bX0haINEqmLJ3Hpdq4AYh5Sq8hiYk+u8QhXjBMO77uck2eOf5iyw3IJb8kJA Hu/RptyKV39C0+bATAmGrDD2PRN+HQRpwTRzED7i+AZIXiAHiupl/HKFOjrHPpgq1TV6 UeJHtgYbryRGuNIfRZFLrpRtXf0nZ1q7kWZAEhWKw0QG/cgSChppyMjMQEqmgZRLmjU8 5uecHbhGuKbCVCsl0yLkPsfrFRfOE2fzj+MTRhyrRBEeveDyxC4AYqkSEbSFwky0DR8r jRnQ== X-Received: by 10.112.129.228 with SMTP id nz4mr52929079lbb.9.1412174197711; Wed, 01 Oct 2014 07:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.63.172 with HTTP; Wed, 1 Oct 2014 07:36:17 -0700 (PDT) From: Darshana Gunawardana Date: Wed, 1 Oct 2014 20:06:17 +0530 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a83ae6a683d05045d6dff Archived-At: http://mailarchive.ietf.org/arch/msg/scim/uPctdZeipBFSHEsZ9uzSIB95HFw Subject: [scim] What are the response attributes when calling SCIM filter 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, 01 Oct 2014 14:38:49 -0000 --047d7b3a83ae6a683d05045d6dff Content-Type: text/plain; charset=UTF-8 Hi all, I'm working on a improvement on SCIM user filtering capabilities in WSO2 Charon implementation which is based on SCIM 1.1. While implementing, I couldn't find in the spec, what are the bare minimum attributes should be in SCIM response. I have search this in section 3.2.2.1 in [1]. In section 3.2, it specify generally when retrieving resources, "Service Providers MAY choose to respond with a sub-set of Resource attributes, though MUST minimally return the Resource id and meta attributes" Does the same rule apply in filtering also? [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources Thanks, Darshana -- With Regards, Darshana Gunawardana, Alumni : Dept. of Computer Science & Engineering, University of Moratuwa, Sri Lanka --047d7b3a83ae6a683d05045d6dff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm working on a improvemen= t on SCIM user filtering capabilities in WSO2 Charon implementation which i= s based on=C2=A0SCIM 1.1.

While implementing, I co= uldn't find in the spec, what are the bare minimum attributes should be= in SCIM response. I have search this in section=C2=A03.2.2.1 in [1].
=

In section 3.2, it specify generally when retrieving re= sources,
"Service Providers MAY choose to respond with a sub= -set of Resource attributes, though MUST minimally return the Resource id a= nd meta attributes"

Does the same rule apply = in filtering also?

=
Thanks,
Darshana

-= -
With Regards,

Darshana Guna= wardana,
Alumni : Dept. of Computer Science & Engineering,
Univer= sity of Moratuwa,
Sri Lanka
--047d7b3a83ae6a683d05045d6dff-- From nobody Wed Oct 1 09:10:50 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 D00681ACE8D for ; Wed, 1 Oct 2014 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 twrlWP4CyPWJ for ; Wed, 1 Oct 2014 09:10: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 32F251ACE6C for ; Wed, 1 Oct 2014 09:10: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 s91GAh73018654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Oct 2014 16:10:44 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 s91GAhRD003943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 16:10:43 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s91GAg61024968; Wed, 1 Oct 2014 16:10:42 GMT Received: from [192.168.1.7] (/24.86.14.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Oct 2014 09:10:42 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-AA6998E5-CB78-4B0B-A27E-24758035D468 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Wed, 1 Oct 2014 09:10:31 -0700 To: Darshana Gunawardana X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/jStlHTJDcvu13fp0lvvwJwDHlQI Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 01 Oct 2014 16:10:48 -0000 --Apple-Mail-AA6998E5-CB78-4B0B-A27E-24758035D468 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This is resolved in scim 2. Look under schemas for the attribute meta item "= returned".=20 Phil > On Oct 1, 2014, at 7:36, Darshana Gunawardana wrot= e: >=20 > Hi all, >=20 > I'm working on a improvement on SCIM user filtering capabilities in WSO2 C= haron implementation which is based on SCIM 1.1. >=20 > While implementing, I couldn't find in the spec, what are the bare minimum= attributes should be in SCIM response. I have search this in section 3.2.2.= 1 in [1]. >=20 > In section 3.2, it specify generally when retrieving resources, > "Service Providers MAY choose to respond with a sub-set of Resource attrib= utes, though MUST minimally return the Resource id and meta attributes" >=20 > Does the same rule apply in filtering also? >=20 > [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resourc= es >=20 > Thanks, > Darshana >=20 > --=20 > With Regards, >=20 > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-AA6998E5-CB78-4B0B-A27E-24758035D468 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This is resolved in scim 2. Look under= schemas for the attribute meta item "returned". 

Phil

On Oct 1, 2014, at 7:36, Darshana Gunawardana <darshanasbg@gmail.com> wrote:

Hi all,

I'm wor= king on a improvement on SCIM user filtering capabilities in WSO2 Charon imp= lementation which is based on SCIM 1.1.

While i= mplementing, I couldn't find in the spec, what are the bare minimum attribut= es should be in SCIM response. I have search this in section 3.2.2.1 in= [1].

In section 3.2, it specify generally when ret= rieving resources,
"Service Providers MAY choose to respond with a= sub-set of Resource attributes, though MUST minimally return the Resource i= d and meta attributes"

Does the same rule apply in f= iltering also?


Thanks,
Darshana

--
With Regards,

Darshana Gunawardana,<= br>Alumni : Dept. of Computer Science & Engineering,
University of Mo= ratuwa,
Sri Lanka
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-AA6998E5-CB78-4B0B-A27E-24758035D468-- From nobody Wed Oct 1 11:47: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 272F01A6FC6 for ; Wed, 1 Oct 2014 11:47:12 -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 GrXqmLvF2W5Y for ; Wed, 1 Oct 2014 11:47:10 -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 9DA531A6FAC for ; Wed, 1 Oct 2014 11:47:10 -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 s91Il94U010256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Oct 2014 18:47:10 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 s91Il8VW022823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Oct 2014 18:47:08 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 s91Il8kw022784 for ; Wed, 1 Oct 2014 18:47:08 GMT Received: from [192.168.1.133] (/24.86.14.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Oct 2014 11:47:07 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_ECE8CAC8-E44C-4613-B650-AF0F20682EA6" Date: Wed, 1 Oct 2014 11:47:05 -0700 References: 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: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/lCz4fQ63bJuFCch_1rlPcMbM3SQ Subject: [scim] Proposed resolution for 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, 01 Oct 2014 18:47:12 -0000 --Apple-Mail=_ECE8CAC8-E44C-4613-B650-AF0F20682EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 WG Members, Morteza and I had a good talk on the phone on today=92s informal WG call = (we did not have quorum), I think we may have a good proposal on = externalId for your consideration. It does not address everyone=92s = needs but it addresses the concerns about externalId within the scope of = our charter which is provisioning. Below is some modified text for the externalId attribute. It keeps the definition the same, but makes clear who gets to assign the = value (besides an arbitrary SCIM client). Please see the text below, the changes are in UPPERCASE. Proposed text for externalId: > externalId > A String that is an identifier for the resource as defined by = the PROVISIONING client. The > "externalId" may simplify identification of the=20 > resource between PROVISIONING client and service provider by = allowing=20 > clientS to use a filter to locate the resource with AN = IDENTIFIER FROM THE PROVISIONING DOMAIN > , obviating the need to store a local mapping between > the PROVISIONING DOMAIN'S identifier of the resource and the = identifier used by > the service provider. Each resource MAY include a SINGLE = non-empty > "externalId" value. The value of the "externalId" attribute is > always issued by the PROVISONING 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. If any one has any objections or amendments, please let the group know = by the end of the week.=20 I propose to post this change to the draft early next week. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_ECE8CAC8-E44C-4613-B650-AF0F20682EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
WG Members,

Morteza and I = had a good talk on the phone on today=92s informal WG call (we did not = have quorum), I think we may have a good proposal on externalId for your = consideration. It does not address everyone=92s needs but it addresses = the concerns about externalId within the scope of our charter which is = provisioning.

Below is some modified text for the = externalId attribute.

It keeps the = definition the same, but makes clear who gets to assign the value = (besides an arbitrary SCIM client).

Please see = the text below, the changes are in = UPPERCASE.

Proposed text for = externalId:
externalId
      A String that is an identifier = for the resource as defined by the PROVISIONING client.  = The
      "externalId" may simplify identification of = the 
      resource between PROVISIONING client and = service provider by allowing 
      clientS to = use a filter to locate the resource with AN IDENTIFIER FROM THE = PROVISIONING DOMAIN
      , obviating the need to store = a local mapping between
      the PROVISIONING DOMAIN'S = identifier of the resource and the identifier used by
  =     the service provider.  Each resource MAY include a = SINGLE non-empty
      "externalId" value.  The = value of the "externalId" attribute is
      always issued = by the PROVISONING 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.

If any one = has any objections or amendments, please let the group know by the end = of the week. 

I propose to post this = change to the draft early next week.
= --Apple-Mail=_ECE8CAC8-E44C-4613-B650-AF0F20682EA6-- From nobody Wed Oct 1 20:59: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 448381A0059 for ; Wed, 1 Oct 2014 20:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, HK_LOTTO_NAME=1, 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 rWIPnGO2cbrV for ; Wed, 1 Oct 2014 20:58:58 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0554A1A0055 for ; Wed, 1 Oct 2014 20:58:57 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so1590271lab.19 for ; Wed, 01 Oct 2014 20:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zBA+5fjYIBYly4SOkS9DcSa61qFBunrRmo1GyyL/FdE=; b=xHVQ94igMZwDpODiPyw+hZ9c15BXtQXNq2AMSElG14mCg2NdBgkQIcXPn6sDPnrHeV slRKdEdEdEQgYVU3pRzf5cOsn1ARQQsg3YnASOsOdhYA8bXYixf4FBZvcDsblWdU/eb4 W0PQ9LkcDqqcO318bdKzec69RMperxKEL70hUoC3zJ73UzgL+0jnrheK2905NAC7o0Pz fpJWa9mmEI1mYWz+TjSMs82Oh6wUBjp45IPuRM6VxhTMMpZLqpZkmDm+zpfMalZ7ZqfQ 5idEOD1pGlzxAgNl+Df5xbT0TEGovPDVldE07wmqxuSBawjxrs8bmng7XxkuMhddoAeu PMSg== X-Received: by 10.152.88.43 with SMTP id bd11mr7757834lab.62.1412222336043; Wed, 01 Oct 2014 20:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.63.172 with HTTP; Wed, 1 Oct 2014 20:58:34 -0700 (PDT) In-Reply-To: References: From: Darshana Gunawardana Date: Thu, 2 Oct 2014 09:28:34 +0530 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c35452af10c7050468a217 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/FbV78OKg6MR35-ZQKgOfs1RVJ5w Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 02 Oct 2014 03:59:00 -0000 --001a11c35452af10c7050468a217 Content-Type: text/plain; charset=UTF-8 Hi Phil, Thanks for the response. Seems like SCIM 2 have well defined structure for attributes returning. When i look for User schema it have almost all of attributes have returned value as default. In the attribute required the value default defined as follows, "default : The attribute is returned by default in all SCIM operation responses where attribute values are returned" So the question is whether SCIM filter operation response is a one of those operations which should contains attribute values? I'm having this problem due to our current implementation return all attributes for users which matches search filter which seems to be compliant with the SCIM 2 spec as well. And currently our maxResults for filter operation is not limited. Hence it takes unacceptable time to build whole response for filter operations in large user base. When we do a profiling, we identified that to search in whole user base and return 1000 user id takes time in milliseconds, but to build response which contains 1000 users with all attributes takes time like 5 minutes. As for a improvement, our initial thought was only returning scim id is sufficient, when filter request does not specified the parameter "attributes". Wanted to confirm whether this way is compliant with the spec or whether it is defined, returning id only is not sufficient and specific set attributes also should always returned for each user in filtering. Thanks, Darshana. On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt wrote: > This is resolved in scim 2. Look under schemas for the attribute meta item > "returned". > > Phil > > On Oct 1, 2014, at 7:36, Darshana Gunawardana > wrote: > > Hi all, > > I'm working on a improvement on SCIM user filtering capabilities in WSO2 > Charon implementation which is based on SCIM 1.1. > > While implementing, I couldn't find in the spec, what are the bare minimum > attributes should be in SCIM response. I have search this in > section 3.2.2.1 in [1]. > > In section 3.2, it specify generally when retrieving resources, > "Service Providers MAY choose to respond with a sub-set of Resource > attributes, though MUST minimally return the Resource id and meta > attributes" > > Does the same rule apply in filtering also? > > [1] > http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources > > Thanks, > Darshana > > -- > With Regards, > > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- With Regards, Darshana Gunawardana, Alumni : Dept. of Computer Science & Engineering, University of Moratuwa, Sri Lanka --001a11c35452af10c7050468a217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

Thanks for the response.
=

Seems like SCIM 2 have well defined structure for attri= butes returning.

When i look for User schema it ha= ve almost all of attributes have returned value as default. In the attribut= e required the value default defined as follows,
=C2=A0 =C2=A0&qu= ot;default : The attribute is returned by default in all SCIM operation res= ponses where attribute values are returned"
So the question = is whether SCIM filter operation response is a one of those operations whic= h should contains attribute values?

I'm ha= ving this problem due to our current implementation return all attributes f= or users which matches search filter which seems to be compliant with the S= CIM 2 spec as well. And currently our=C2=A0maxResults for filter operation is not limited. Hence it tak= es unacceptable time to build whole response for filter operations in large= user base.

When we do a profiling, we identified that to search in whole user base a= nd return 1000 user id takes time in milliseconds, but to build response wh= ich contains 1000=C2=A0users with all = attributes takes time like 5 minutes.=C2=A0As for a improvement, our initial thought was = only returning scim id is=C2=A0suff= icient,=C2=A0when fil= ter request does not=C2=A0specified= the parameter "attributes".

Wanted to confirm whethe= r this way is=C2=A0compliant=C2=A0with the spec or whether it is defined, r= eturning id only is not=C2=A0sufficient=C2=A0and=C2=A0specific set attribut= es=C2=A0also should always returned for each user in filtering.

Thanks,
Darshana.

On Wed, Oct 1,= 2014 at 9:40 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=
This is resolved = in scim 2. Look under schemas for the attribute meta item "returned&qu= ot;.=C2=A0

Phil

On Oct 1, 2014,= at 7:36, Darshana Gunawardana <darshanasbg@gmail.com> wrote:

Hi all,

I'= m working on a improvement on SCIM user filtering capabilities in WSO2 Char= on implementation which is based on=C2=A0SCIM 1.1.

While implementing, I couldn't find in the spec, what are the bare min= imum attributes should be in SCIM response. I have search this in section= =C2=A03.2.2.1 in [1].

In section 3.2, it specify g= enerally when retrieving resources,
"Service Providers MAY c= hoose to respond with a sub-set of Resource attributes, though MUST minimal= ly return the Resource id and meta attributes"

Does the same rule apply in filtering also?


Thanks,
<= div>Darshana

--
W= ith Regards,

Darshana Gunawardana,
Alumni : Dept. of= Computer Science & Engineering,
University of Moratuwa,
Sri Lank= a
_______= ________________________________________
scim mailing list<= /span>
scim@iet= f.org
https://www.ietf.org/mailman/listinfo/scim



--
With Regards,

= Darshana Gunawardana,
Alumni : Dept. of Computer Science & Engineeri= ng,
University of Moratuwa,
Sri Lanka
--001a11c35452af10c7050468a217-- From nobody Wed Oct 1 21:12:40 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 3CE7C1A005E for ; Wed, 1 Oct 2014 21:12:38 -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_102=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 vyQmM50R_200 for ; Wed, 1 Oct 2014 21:12:35 -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 81CBF1A005B for ; Wed, 1 Oct 2014 21:12:35 -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 s924CWgD027113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Oct 2014 04:12:33 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 s924CWlu016363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 04:12:32 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 s924CU5k020600; Thu, 2 Oct 2014 04:12:31 GMT Received: from [192.168.1.110] (/24.85.230.244) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Oct 2014 21:12:29 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-522F90FF-938F-4B36-B86D-2E82E19DE7AB Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Wed, 1 Oct 2014 21:12:28 -0700 To: Darshana Gunawardana X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/c2PRdxwfgJThaomwkgGZ38ic4O4 Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 02 Oct 2014 04:12:38 -0000 --Apple-Mail-522F90FF-938F-4B36-B86D-2E82E19DE7AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If you want that behavior you could have the client request attributes=3Did.= =20 In general only privileged users should be able to return all entries and al= l attrs.=20 You can also change returned to "request" to get the behavior you want and t= hat would be legit. However you could expect some clients to react badly.=20= Better to limit max results for most users and limit what avg low-priv users= can see.=20 Phil > On Oct 1, 2014, at 20:58, Darshana Gunawardana wro= te: >=20 > Hi Phil, >=20 > Thanks for the response. >=20 > Seems like SCIM 2 have well defined structure for attributes returning. >=20 > When i look for User schema it have almost all of attributes have returned= value as default. In the attribute required the value default defined as fo= llows, > "default : The attribute is returned by default in all SCIM operation r= esponses where attribute values are returned" > So the question is whether SCIM filter operation response is a one of thos= e operations which should contains attribute values? >=20 > I'm having this problem due to our current implementation return all attri= butes for users which matches search filter which seems to be compliant with= the SCIM 2 spec as well. And currently our maxResults for filter operation i= s not limited. Hence it takes unacceptable time to build whole response for f= ilter operations in large user base. >=20 > When we do a profiling, we identified that to search in whole user base an= d return 1000 user id takes time in milliseconds, but to build response whic= h contains 1000 users with all attributes takes time like 5 minutes. As for a= improvement, our initial thought was only returning scim id is sufficient, w= hen filter request does not specified the parameter "attributes". >=20 > Wanted to confirm whether this way is compliant with the spec or whether i= t is defined, returning id only is not sufficient and specific set attribute= s also should always returned for each user in filtering. >=20 > Thanks, > Darshana. >=20 >> On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt wrote: >> This is resolved in scim 2. Look under schemas for the attribute meta ite= m "returned".=20 >>=20 >> Phil >>=20 >>> On Oct 1, 2014, at 7:36, Darshana Gunawardana wr= ote: >>>=20 >>> Hi all, >>>=20 >>> I'm working on a improvement on SCIM user filtering capabilities in WSO2= Charon implementation which is based on SCIM 1.1. >>>=20 >>> While implementing, I couldn't find in the spec, what are the bare minim= um attributes should be in SCIM response. I have search this in section 3.2.= 2.1 in [1]. >>>=20 >>> In section 3.2, it specify generally when retrieving resources, >>> "Service Providers MAY choose to respond with a sub-set of Resource attr= ibutes, though MUST minimally return the Resource id and meta attributes" >>>=20 >>> Does the same rule apply in filtering also? >>>=20 >>> [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resou= rces >>>=20 >>> Thanks, >>> Darshana >>>=20 >>> --=20 >>> With Regards, >>>=20 >>> Darshana Gunawardana, >>> Alumni : Dept. of Computer Science & Engineering, >>> University of Moratuwa, >>> Sri Lanka >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > With Regards, >=20 > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-522F90FF-938F-4B36-B86D-2E82E19DE7AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you want that behavior you could ha= ve the client request attributes=3Did. 

In gen= eral only privileged users should be able to return all entries and all attr= s. 

You can also change returned to "request" t= o get the behavior you want and that would be legit. However you could expec= t some clients to react badly. 

Better to limi= t max results for most users and limit what avg low-priv users can see. = ;

Phil

On Oct 1, 2014, at 20:58, Darshana Gunawardana &= lt;darshanasbg@gmail.com> wr= ote:

Hi Phil,
Thanks for the response.

Seems li= ke SCIM 2 have well defined structure for attributes returning.
When i look for User schema it have almost all of attributes ha= ve returned value as default. In the attribute required the value default de= fined as follows,
   "default : The attribute is returne= d by default in all SCIM operation responses where attribute values are retu= rned"
So the question is whether SCIM filter operation response is= a one of those operations which should contains attribute values?
=

I'm having this problem due to our current implementatio= n return all attributes for users which matches search filter which seems to= be compliant with the SCIM 2 spec as well. And currently our maxResults for filter operation is not= limited. Hence it takes unacceptable time to build whole response for filte= r operations in large user base.

When we do a profiling, we identified that to search in= whole user base and return 1000 user id takes time in milliseconds, but to b= uild response which contains 1000 = users with all attributes takes time like 5 minutes. As for a improvement, our initial= thought was only returning scim id is sufficient,&nb= sp;when filter request does not specified the parameter "attributes".

Wanted to confirm whether t= his way is compliant with the spec or whether it is defined, retur= ning id only is not sufficient and specific set attributes&nb= sp;also should always returned for each user in filtering.
=
Thanks= ,
Darshana.

On Wed, Oct 1, 2014 at 9= :40 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
This is resolved in scim 2. Loo= k under schemas for the attribute meta item "returned". 

Phil

On Oct 1, 2014, at 7:36, Darshana Gunawar= dana <darshana= sbg@gmail.com> wrote:

Hi all,

I'm working on a improvement on SCI= M user filtering capabilities in WSO2 Charon implementation which is based o= n SCIM 1.1.

While implementing, I couldn't fin= d in the spec, what are the bare minimum attributes should be in SCIM respon= se. I have search this in section 3.2.2.1 in [1].

<= div>In section 3.2, it specify generally when retrieving resources,
"Service Providers MAY choose to respond with a sub-set of Resource attrib= utes, though MUST minimally return the Resource id and meta attributes"

Does the same rule apply in filtering also?
<= br>

= Thanks,
Darshana

--
With Regards,

Darshana Gunawardana,
Alumni= : Dept. of Computer Science & Engineering,
University of Moratuwa,Sri Lanka
________= _______________________________________
scim mailing list
scim@ietf.o= rg
https://www.ietf.org/mailman/listinfo/scim



=
--
With Regards,

Darshan= a Gunawardana,
Alumni : Dept. of Computer Science & Engineering,
U= niversity of Moratuwa,
Sri Lanka
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-522F90FF-938F-4B36-B86D-2E82E19DE7AB-- From nobody Sat Oct 4 11:22: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 23F621A0126 for ; Sat, 4 Oct 2014 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_LOTTO_NAME=1, HTML_MESSAGE=0.001, J_CHICKENPOX_102=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 Fiv2h-1ZC6rJ for ; Sat, 4 Oct 2014 11:22:51 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C57B1A0142 for ; Sat, 4 Oct 2014 11:22:50 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so2585755lam.18 for ; Sat, 04 Oct 2014 11:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M4yC+JctuLNR3HiozoDR7OKP/EweiW5Y1zrqY+ePc6U=; b=eLBjAvGlfr1VzebPz7LLT/2cWe6iZ6mpghzu70MP/gHnKwcadm8JHiNLzeWoi0Qlqo yl1xREsGvTCEtzqtbDXcjv6JfJsckmhSyEE7xxjf8YcAXG2clvDPJMnmJv9bFWo+YNRN EuSuQPsKQqGaNsj4LsBgEwA5e0oxvBlN/12fdKNe7IAdJBv+ho3xXANdsbJAbkvl8Kq1 SOihWS7qRteRVs6vKn2vZDVjiCz9YFkCuuX6p5HRz0i4wMQyKeMHst3jOZaT0sCESgkh vHU9t///X5AKPrZNW4D1nW9l077WLVZVApCsfLlFL4WaCWxGbynyJm/YCMbW0D9EefgM WA8A== X-Received: by 10.152.44.136 with SMTP id e8mr14260408lam.36.1412446969431; Sat, 04 Oct 2014 11:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.176.105 with HTTP; Sat, 4 Oct 2014 11:22:29 -0700 (PDT) In-Reply-To: References: From: Darshana Gunawardana Date: Sat, 4 Oct 2014 23:52:29 +0530 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0160a8b2e08daa05049cef70 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/l54IUP4fGAn82fBHg-tljR0bIZc Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 04 Oct 2014 18:22:53 -0000 --089e0160a8b2e08daa05049cef70 Content-Type: text/plain; charset=UTF-8 Hi Phil, Yes, changing to return only id in the filtering, make some existing clients to do extra work. We need to do some research to find optimal solution to keep reduce ldap calls while compatible with all existing clients.. Thanks a lot for your input.. Regards, Dashana On Thu, Oct 2, 2014 at 9:42 AM, Phil Hunt wrote: > If you want that behavior you could have the client request attributes=id. > > In general only privileged users should be able to return all entries and > all attrs. > > You can also change returned to "request" to get the behavior you want and > that would be legit. However you could expect some clients to react badly. > > Better to limit max results for most users and limit what avg low-priv > users can see. > > Phil > > On Oct 1, 2014, at 20:58, Darshana Gunawardana > wrote: > > Hi Phil, > > Thanks for the response. > > Seems like SCIM 2 have well defined structure for attributes returning. > > When i look for User schema it have almost all of attributes have returned > value as default. In the attribute required the value default defined as > follows, > "default : The attribute is returned by default in all SCIM operation > responses where attribute values are returned" > So the question is whether SCIM filter operation response is a one of > those operations which should contains attribute values? > > I'm having this problem due to our current implementation return all > attributes for users which matches search filter which seems to be > compliant with the SCIM 2 spec as well. And currently our maxResults for > filter operation is not limited. Hence it takes unacceptable time to build > whole response for filter operations in large user base. > > When we do a profiling, we identified that to search in whole user base > and return 1000 user id takes time in milliseconds, but to build response > which contains 1000 users with all attributes takes time like 5 minutes. As > for a improvement, our initial thought was only returning scim id is > sufficient, when filter request does not specified the parameter > "attributes". > > Wanted to confirm whether this way is compliant with the spec or whether > it is defined, returning id only is not sufficient and specific set > attributes also should always returned for each user in filtering. > > Thanks, > Darshana. > > On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt wrote: > >> This is resolved in scim 2. Look under schemas for the attribute meta >> item "returned". >> >> Phil >> >> On Oct 1, 2014, at 7:36, Darshana Gunawardana >> wrote: >> >> Hi all, >> >> I'm working on a improvement on SCIM user filtering capabilities in WSO2 >> Charon implementation which is based on SCIM 1.1. >> >> While implementing, I couldn't find in the spec, what are the bare >> minimum attributes should be in SCIM response. I have search this in >> section 3.2.2.1 in [1]. >> >> In section 3.2, it specify generally when retrieving resources, >> "Service Providers MAY choose to respond with a sub-set of Resource >> attributes, though MUST minimally return the Resource id and meta >> attributes" >> >> Does the same rule apply in filtering also? >> >> [1] >> http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources >> >> Thanks, >> Darshana >> >> -- >> With Regards, >> >> Darshana Gunawardana, >> Alumni : Dept. of Computer Science & Engineering, >> University of Moratuwa, >> Sri Lanka >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > With Regards, > > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- With Regards, Darshana Gunawardana, Alumni : Dept. of Computer Science & Engineering, University of Moratuwa, Sri Lanka --089e0160a8b2e08daa05049cef70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

Yes, changing to return only i= d in the filtering, make some existing clients to do extra work. We need to= do some research to find optimal solution to keep reduce ldap calls while = compatible with all existing clients..

Thanks a lo= t for your input..

Regards,
Dashana

On Thu, Oc= t 2, 2014 at 9:42 AM, Phil Hunt <phil.hunt@oracle.com> wr= ote:
If you want t= hat behavior you could have the client request attributes=3Did.=C2=A0
=

In general only privileged users should be able to retu= rn all entries and all attrs.=C2=A0

You can also c= hange returned to "request" to get the behavior you want and that= would be legit. However you could expect some clients to react badly.=C2= =A0

Better to limit max results for most users and= limit what avg low-priv users can see.=C2=A0

Phil

On Oct 1, 2014, at 20:58, Darshana Gunawardana <darshanasbg@gmail.com> wrot= e:

Hi Phil,
Thanks for the response.

Seems li= ke SCIM 2 have well defined structure for attributes returning.
<= br>
When i look for User schema it have almost all of attributes = have returned value as default. In the attribute required the value default= defined as follows,
=C2=A0 =C2=A0"default : The attribute i= s returned by default in all SCIM operation responses where attribute value= s are returned"
So the question is whether SCIM filter opera= tion response is a one of those operations which should contains attribute = values?

I'm having this problem due to our= current implementation return all attributes for users which matches searc= h filter which seems to be compliant with the SCIM 2 spec as well. And curr= ently our=C2=A0maxResults fo= r filter operation is not limited. Hence it takes unacceptable time to buil= d whole response for filter operations in large user base.

When we do a profiling, we= identified that to search in whole user base and return 1000 user id takes= time in milliseconds, but to build response which contains 1000=C2=A0users with all attributes takes time like 5= minutes.=C2=A0As for a improvement, our initial thought was only returning scim id is=C2= =A0sufficient,=C2=A0when filter request does not=C2=A0specified the parameter "attribu= tes".

<= font color=3D"#000000">Wanted to confirm whether this way is=C2=A0compliant= =C2=A0with the spec or whether it is defined, returning id only is not=C2= =A0sufficient=C2=A0and=C2=A0specific set attributes=C2=A0also should always= returned for each user in filtering.

Thanks,
= Darshana.

On Wed, Oct 1, 2014 at 9:40 PM, Phil Hun= t <phil.hunt@oracle.com> wrote:
This is resolved in scim 2. Look under sche= mas for the attribute meta item "returned".=C2=A0

Phil

On Oct 1, 2014, at 7:36, Darshana Gunawardana <darshanasbg@gmail.co= m> wrote:

Hi all,

I'm working on a improvement on SCIM user= filtering capabilities in WSO2 Charon implementation which is based on=C2= =A0SCIM 1.1.

While implementing, I couldn't fi= nd in the spec, what are the bare minimum attributes should be in SCIM resp= onse. I have search this in section=C2=A03.2.2.1 in [1].

In section 3.2, it specify generally when retrieving resources,
"Service Providers MAY choose to respond with a sub-set of Resou= rce attributes, though MUST minimally return the Resource id and meta attri= butes"

Does the same rule apply in filtering = also?

=

Thanks,
Darshana

--
With Regards,

Darshana= Gunawardana,
Alumni : Dept. of Computer Science & Engineering,
U= niversity of Moratuwa,
Sri Lanka
_______= ________________________________________
scim mailing list<= /span>
scim@iet= f.org
https://www.ietf.org/mailman/listinfo/scim



--
With Regards,

= Darshana Gunawardana,
Alumni : Dept. of Computer Science & Engineeri= ng,
University of Moratuwa,
Sri Lanka
___________________= ____________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
=



--
With Regards,

= Darshana Gunawardana,
Alumni : Dept. of Computer Science & Engineeri= ng,
University of Moratuwa,
Sri Lanka
--089e0160a8b2e08daa05049cef70-- From nobody Sat Oct 4 11:49: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 A9CBF1A014D for ; Sat, 4 Oct 2014 11:49:23 -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_102=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 a0pSLB-ZE0eS for ; Sat, 4 Oct 2014 11:49:21 -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 9EDF71A0149 for ; Sat, 4 Oct 2014 11:49:21 -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 s94InHUg026090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Oct 2014 18:49:19 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 s94InHQJ023644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 18:49:17 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 s94InH7t023641; Sat, 4 Oct 2014 18:49:17 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 04 Oct 2014 11:49:16 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0DEAED2D-ED02-4EF9-B9E8-66F4D43D9D55" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 4 Oct 2014 11:49:14 -0700 Message-Id: References: To: Darshana Gunawardana 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/TFq6rgCfUrgbcIwdbFB2pjik1pk Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 04 Oct 2014 18:49:23 -0000 --Apple-Mail=_0DEAED2D-ED02-4EF9-B9E8-66F4D43D9D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dashana, I am not sure what you are suggesting/proposing.=20 If anything SCIM2 already has a lot of functionality to control which = attributes are returned per request that is similar in nature to LDAP. = LDAP protocol returns all attributes by default except for =91operational'= attributes. If anything, SCIM returns slightly fewer attributes and = allows for configured flexibility (as with LDAP). In SCIM, returning only =93id=94 is easily achieved using the attributes = qualifier. What are you suggesting we change exactly? Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 4, 2014, at 11:22 AM, Darshana Gunawardana = wrote: > Hi Phil, >=20 > Yes, changing to return only id in the filtering, make some existing = clients to do extra work. We need to do some research to find optimal = solution to keep reduce ldap calls while compatible with all existing = clients.. >=20 > Thanks a lot for your input.. >=20 > Regards, > Dashana >=20 > On Thu, Oct 2, 2014 at 9:42 AM, Phil Hunt = wrote: > If you want that behavior you could have the client request = attributes=3Did.=20 >=20 > In general only privileged users should be able to return all entries = and all attrs.=20 >=20 > You can also change returned to "request" to get the behavior you want = and that would be legit. However you could expect some clients to react = badly.=20 >=20 > Better to limit max results for most users and limit what avg low-priv = users can see.=20 >=20 > Phil >=20 > On Oct 1, 2014, at 20:58, Darshana Gunawardana = wrote: >=20 >> Hi Phil, >>=20 >> Thanks for the response. >>=20 >> Seems like SCIM 2 have well defined structure for attributes = returning. >>=20 >> When i look for User schema it have almost all of attributes have = returned value as default. In the attribute required the value default = defined as follows, >> "default : The attribute is returned by default in all SCIM = operation responses where attribute values are returned" >> So the question is whether SCIM filter operation response is a one of = those operations which should contains attribute values? >>=20 >> I'm having this problem due to our current implementation return all = attributes for users which matches search filter which seems to be = compliant with the SCIM 2 spec as well. And currently our maxResults for = filter operation is not limited. Hence it takes unacceptable time to = build whole response for filter operations in large user base. >>=20 >> When we do a profiling, we identified that to search in whole user = base and return 1000 user id takes time in milliseconds, but to build = response which contains 1000 users with all attributes takes time like 5 = minutes. As for a improvement, our initial thought was only returning = scim id is sufficient, when filter request does not specified the = parameter "attributes". >>=20 >> Wanted to confirm whether this way is compliant with the spec or = whether it is defined, returning id only is not sufficient and specific = set attributes also should always returned for each user in filtering. >>=20 >> Thanks, >> Darshana. >>=20 >> On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt = wrote: >> This is resolved in scim 2. Look under schemas for the attribute meta = item "returned".=20 >>=20 >> Phil >>=20 >> On Oct 1, 2014, at 7:36, Darshana Gunawardana = wrote: >>=20 >>> Hi all, >>>=20 >>> I'm working on a improvement on SCIM user filtering capabilities in = WSO2 Charon implementation which is based on SCIM 1.1. >>>=20 >>> While implementing, I couldn't find in the spec, what are the bare = minimum attributes should be in SCIM response. I have search this in = section 3.2.2.1 in [1]. >>>=20 >>> In section 3.2, it specify generally when retrieving resources, >>> "Service Providers MAY choose to respond with a sub-set of Resource = attributes, though MUST minimally return the Resource id and meta = attributes" >>>=20 >>> Does the same rule apply in filtering also? >>>=20 >>> [1] = http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources >>>=20 >>> Thanks, >>> Darshana >>>=20 >>> --=20 >>> With Regards, >>>=20 >>> Darshana Gunawardana, >>> Alumni : Dept. of Computer Science & Engineering, >>> University of Moratuwa, >>> Sri Lanka >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> --=20 >> With Regards, >>=20 >> Darshana Gunawardana, >> Alumni : Dept. of Computer Science & Engineering, >> University of Moratuwa, >> Sri Lanka >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > With Regards, >=20 > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka --Apple-Mail=_0DEAED2D-ED02-4EF9-B9E8-66F4D43D9D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dashana,

I am not sure what = you are suggesting/proposing. 

If anything SCIM2 = already has a lot of functionality to control which attributes are = returned per request that is similar in nature to LDAP. LDAP protocol = returns all attributes by default except for =91operational' attributes. = If anything, SCIM returns slightly fewer attributes and allows for = configured flexibility (as with LDAP).

In SCIM, = returning only =93id=94 is easily achieved using the attributes = qualifier.

What are you suggesting we change = exactly?


On Oct 4, 2014, at 11:22 AM, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi Phil,

Yes, changing = to return only id in the filtering, make some existing clients to do = extra work. We need to do some research to find optimal solution to keep = reduce ldap calls while compatible with all existing = clients..

Thanks a lot for your = input..

Regards,
Dashana

On Thu, Oct 2, = 2014 at 9:42 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
If you want that behavior you could have the client = request attributes=3Did. 

In general only = privileged users should be able to return all entries and all = attrs. 

You can also change returned to = "request" to get the behavior you want and that would be legit. However = you could expect some clients to react = badly. 

Better to limit max results for = most users and limit what avg low-priv users can see. 

Phil

On Oct 1, 2014, at 20:58, Darshana Gunawardana = <darshanasbg@gmail.com> = wrote:

Hi = Phil,

Thanks for the = response.

Seems like SCIM 2 have well defined = structure for attributes returning.

When i look = for User schema it have almost all of attributes have returned value as = default. In the attribute required the value default defined as = follows,
   "default : The attribute is returned by = default in all SCIM operation responses where attribute values are = returned"
So the question is whether SCIM filter operation = response is a one of those operations which should contains attribute = values?

I'm having this problem due to our = current implementation return all attributes for users which matches = search filter which seems to be compliant with the SCIM 2 spec as well. = And currently our maxResults for = filter operation is not limited. Hence it takes unacceptable time to = build whole response for filter operations in large user = base.

When we = do a profiling, we identified that to search in whole user base and = return 1000 user id takes time in milliseconds, but to build response = which contains 1000 users with = all attributes takes time like 5 minutes. As for a improvement, our initial thought was = only returning scim id is sufficient, when = filter request does not specified the = parameter = "attributes".

Wanted = to confirm whether this way is compliant with the spec or = whether it is defined, returning id only is = not sufficient and specific set attributes also = should always returned for each user in = filtering.

Thanks,
Darshana.

On Wed, Oct 1, 2014 = at 9:40 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This is resolved in scim 2. Look under schemas for the = attribute meta item "returned". 

Phil

On = Oct 1, 2014, at 7:36, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi = all,

I'm working on a improvement on SCIM user = filtering capabilities in WSO2 Charon implementation which is based = on SCIM 1.1.

While implementing, I = couldn't find in the spec, what are the bare minimum attributes should = be in SCIM response. I have search this in section 3.2.2.1 in = [1].

In section 3.2, it specify generally when = retrieving resources,
"Service Providers MAY choose to respond = with a sub-set of Resource attributes, though MUST minimally return the = Resource id and meta attributes"

Does the same = rule apply in filtering also?


Thanks,
Darshana

--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka
_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka
_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka

= --Apple-Mail=_0DEAED2D-ED02-4EF9-B9E8-66F4D43D9D55-- From nobody Sat Oct 4 12:23:23 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 5269F1A0175 for ; Sat, 4 Oct 2014 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_LOTTO_NAME=1, HTML_MESSAGE=0.001, J_CHICKENPOX_102=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 GThPeIoZ5nuu for ; Sat, 4 Oct 2014 12:23:20 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16581A0167 for ; Sat, 4 Oct 2014 12:23:19 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so2637117lab.13 for ; Sat, 04 Oct 2014 12:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hz9X1TtEQcgKZJ25Z62vK5Zf/M2XVNh8nu6KZklL6fQ=; b=isvW2fA/9wLQKsvtPb8Ae9aHjVFuL7SCvDhaHYGdXNQNjfyvRAhyx7VaBORE5hUKUI Xbjet3tETQKurnMb3/BLq7SfVIalNIxSByw04/39tZzptfFd4rl+X0p1rm2RkZ0n8ntl gPyAbPWJeJBRK//MM3Rf6AXEnjUyea4t+SK5OExXSXuts++/Aq1qxC1qXERjhIGC/nJR u7xct+di//bcx86jW+AvFvZ22uAnpoIBj7YETHX39zrizO9BFljp9I8ZJI1VbzrUPAPL Da55w9azAv6tLYpMCkr16nzec5dSZ/gw6Uuwxlu0xmE+ugLB51DV5tk+F6AxgTD+sIIN L8Fg== X-Received: by 10.152.9.132 with SMTP id z4mr14523643laa.8.1412450598019; Sat, 04 Oct 2014 12:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.176.105 with HTTP; Sat, 4 Oct 2014 12:22:57 -0700 (PDT) In-Reply-To: References: From: Darshana Gunawardana Date: Sun, 5 Oct 2014 00:52:57 +0530 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1132e99a28665d05049dc8b4 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/TMoNDGFMePjOH7vnyYyGhJ_8cP4 Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 04 Oct 2014 19:23:22 -0000 --001a1132e99a28665d05049dc8b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, Oh.. I thinks my previous mail was bit ambiguous.. Sorry for that.. I'm agree that SCIM2 has the flexibility to define which attributes should return. In my earlier response what i meant was, I need to look deep-in *my* implementation details and find optimal solution.. It wasn't meant to suggest to change the spec.. I got answers for my original question, "what attributes should return in a user filter response" and the answer was "as per SCIM2 it depends on the 'returned' meta attribute in user schema". So we can conclude the thread i guess.. Thanks, Darshana On Sun, Oct 5, 2014 at 12:19 AM, Phil Hunt wrote: > Dashana, > > I am not sure what you are suggesting/proposing. > > If anything SCIM2 already has a lot of functionality to control which > attributes are returned per request that is similar in nature to LDAP. LD= AP > protocol returns all attributes by default except for =E2=80=98operationa= l' > attributes. If anything, SCIM returns slightly fewer attributes and allow= s > for configured flexibility (as with LDAP). > > In SCIM, returning only =E2=80=9Cid=E2=80=9D is easily achieved using the= attributes > qualifier. > > What are you suggesting we change exactly? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 4, 2014, at 11:22 AM, Darshana Gunawardana > wrote: > > Hi Phil, > > Yes, changing to return only id in the filtering, make some existing > clients to do extra work. We need to do some research to find optimal > solution to keep reduce ldap calls while compatible with all existing > clients.. > > Thanks a lot for your input.. > > Regards, > Dashana > > On Thu, Oct 2, 2014 at 9:42 AM, Phil Hunt wrote: > >> If you want that behavior you could have the client request >> attributes=3Did. >> >> In general only privileged users should be able to return all entries an= d >> all attrs. >> >> You can also change returned to "request" to get the behavior you want >> and that would be legit. However you could expect some clients to react >> badly. >> >> Better to limit max results for most users and limit what avg low-priv >> users can see. >> >> Phil >> >> On Oct 1, 2014, at 20:58, Darshana Gunawardana >> wrote: >> >> Hi Phil, >> >> Thanks for the response. >> >> Seems like SCIM 2 have well defined structure for attributes returning. >> >> When i look for User schema it have almost all of attributes have >> returned value as default. In the attribute required the value default >> defined as follows, >> "default : The attribute is returned by default in all SCIM operation >> responses where attribute values are returned" >> So the question is whether SCIM filter operation response is a one of >> those operations which should contains attribute values? >> >> I'm having this problem due to our current implementation return all >> attributes for users which matches search filter which seems to be >> compliant with the SCIM 2 spec as well. And currently our maxResults for >> filter operation is not limited. Hence it takes unacceptable time to bui= ld >> whole response for filter operations in large user base. >> >> When we do a profiling, we identified that to search in whole user base >> and return 1000 user id takes time in milliseconds, but to build respons= e >> which contains 1000 users with all attributes takes time like 5 minutes.= As >> for a improvement, our initial thought was only returning scim id is >> sufficient, when filter request does not specified the parameter >> "attributes". >> >> Wanted to confirm whether this way is compliant with the spec or whether >> it is defined, returning id only is not sufficient and specific set >> attributes also should always returned for each user in filtering. >> >> Thanks, >> Darshana. >> >> On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt wrote: >> >>> This is resolved in scim 2. Look under schemas for the attribute meta >>> item "returned". >>> >>> Phil >>> >>> On Oct 1, 2014, at 7:36, Darshana Gunawardana >>> wrote: >>> >>> Hi all, >>> >>> I'm working on a improvement on SCIM user filtering capabilities in WSO= 2 >>> Charon implementation which is based on SCIM 1.1. >>> >>> While implementing, I couldn't find in the spec, what are the bare >>> minimum attributes should be in SCIM response. I have search this in >>> section 3.2.2.1 in [1]. >>> >>> In section 3.2, it specify generally when retrieving resources, >>> "Service Providers MAY choose to respond with a sub-set of Resource >>> attributes, though MUST minimally return the Resource id and meta >>> attributes" >>> >>> Does the same rule apply in filtering also? >>> >>> [1] >>> http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resource= s >>> >>> Thanks, >>> Darshana >>> >>> -- >>> With Regards, >>> >>> Darshana Gunawardana, >>> Alumni : Dept. of Computer Science & Engineering, >>> University of Moratuwa, >>> Sri Lanka >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >> >> >> -- >> With Regards, >> >> Darshana Gunawardana, >> Alumni : Dept. of Computer Science & Engineering, >> University of Moratuwa, >> Sri Lanka >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > With Regards, > > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > > > --=20 With Regards, Darshana Gunawardana, Alumni : Dept. of Computer Science & Engineering, University of Moratuwa, Sri Lanka --001a1132e99a28665d05049dc8b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

Oh.. I thinks my previous mail= was bit ambiguous..=C2=A0 Sorry for that.. I'm agree that SCIM2 has th= e flexibility to define which attributes should return.

In my earlier response what i meant was, I need to look deep-in my= implementation details and=C2=A0find optimal solution.. It=C2=A0wasn't=C2=A0meant to suggest to chan= ge the spec..

=
I got answers for my original q= uestion, "what attributes should return in a user filter response"= ; and the answer was "as per SCIM2 it depends on the 'returned'= ; meta attribute in user schema".

So we = can conclude the thread i guess..

Thanks,
Darshana

On Sun, Oct 5, 2014 at 1= 2:19 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Dashana,
I am not sure what you are suggesting/proposing.=C2=A0

If anything SCIM2 already has a lot of functionality to control which= attributes are returned per request that is similar in nature to LDAP. LDA= P protocol returns all attributes by default except for =E2=80=98operationa= l' attributes. If anything, SCIM returns slightly fewer attributes and = allows for configured flexibility (as with LDAP).

I= n SCIM, returning only =E2=80=9Cid=E2=80=9D is easily achieved using the at= tributes qualifier.

What are you suggesting we cha= nge exactly?



On Thu, Oct 2, 2014 at 9:42 AM, Phil= Hunt <phil.hunt@oracle.com> wrote:
=
If you want that behavior you could have the client = request attributes=3Did.=C2=A0

In general only pri= vileged users should be able to return all entries and all attrs.=C2=A0

You can also change returned to "request" t= o get the behavior you want and that would be legit. However you could expe= ct some clients to react badly.=C2=A0

Better to li= mit max results for most users and limit what avg low-priv users can see.= =C2=A0

Phil

On Oct 1, 2014, at 20:58, Darshana Gunawardana <darshanasbg@gmail.com>= ; wrote:

Hi Phil,
Thanks for the response.

Seems l= ike SCIM 2 have well defined structure for attributes returning.
=
When i look for User schema it have almost all of attributes= have returned value as default. In the attribute required the value defaul= t defined as follows,
=C2=A0 =C2=A0"default : The attribute = is returned by default in all SCIM operation responses where attribute valu= es are returned"
So the question is whether SCIM filter oper= ation response is a one of those operations which should contains attribute= values?

I'm having this problem due to ou= r current implementation return all attributes for users which matches sear= ch filter which seems to be compliant with the SCIM 2 spec as well. And cur= rently our=C2=A0maxResults for filter operati= on is not limited. Hence it takes unacceptable time to build whole response= for filter operations in large user base.

Wh= en we do a profiling, we identified that to search in whole user base and r= eturn 1000 user id takes time in milliseconds, but to build response which = contains 1000=C2=A0users with all attr= ibutes takes time like 5 minutes.=C2=A0As for a improvement, our initial thought was only returning scim i= d is=C2=A0sufficient,=C2= =A0when filter request does not=C2=A0specified the parameter &= quot;attributes".

W= anted to confirm whether this way is=C2=A0compliant=C2=A0with the spec or w= hether it is defined, returning id only is not=C2=A0sufficient=C2=A0and=C2= =A0specific set attributes=C2=A0also should always returned for each user i= n filtering.

Thanks,
Darshana.
=
On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
This is resolved in scim 2. Look under schemas for the attri= bute meta item "returned".=C2=A0

Phil

O= n Oct 1, 2014, at 7:36, Darshana Gunawardana <darshanasbg@gmail.com> wrote:
Hi all,

I'm working on a improvement on SCIM user filtering capabilities in = WSO2 Charon implementation which is based on=C2=A0SCIM 1.1.

<= /div>
While implementing, I couldn't find in the spec, what are the= bare minimum attributes should be in SCIM response. I have search this in = section=C2=A03.2.2.1 in [1].

In section 3.2, it sp= ecify generally when retrieving resources,
"Service Provider= s MAY choose to respond with a sub-set of Resource attributes, though MUST = minimally return the Resource id and meta attributes"

Does the same rule apply in filtering also?

[1]=C2=A0http://www.simplecloud.info/specs/d= raft-scim-api-01.html#query-resources

Thanks,<= /div>
Darshana

--
=
With Regards,

Darshana Gunawardana,
Alumni : De= pt. of Computer Science & Engineering,
University of Moratuwa,
Sr= i Lanka
________________________= _______________________
scim mailing list
<= a href=3D"mailto:scim@ietf.org" target=3D"_blank">scim@ietf.org<= br>https://www.ietf.org/mailman/listinfo/scim



--
With Regards,

Darshana Gunawardana,Alumni : Dept. of Computer Science & Engineering,
University of Mo= ratuwa,
Sri Lanka
______________________________= _________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--
With Regards,

Darshana Gunaward= ana,
Alumni : Dept. of Computer Science & Engineering,
University= of Moratuwa,
Sri Lanka




--
= With Regards,

Darshana Gunawardana,
Alumni : Dept. o= f Computer Science & Engineering,
University of Moratuwa,
Sri Lan= ka
--001a1132e99a28665d05049dc8b4-- From nobody Sat Oct 4 12:39:53 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 745111A0208 for ; Sat, 4 Oct 2014 12:39:51 -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_102=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 A8G9oNoIvdWu for ; Sat, 4 Oct 2014 12:39: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 9CD911A01D8 for ; Sat, 4 Oct 2014 12:39:48 -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 s94JdjpU020628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Oct 2014 19:39:46 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 s94Jdic9006032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Oct 2014 19:39:45 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s94JdiEb029663; Sat, 4 Oct 2014 19:39:44 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 04 Oct 2014 12:39:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_377934BC-5618-4028-A645-DD9857A63CBF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Sat, 4 Oct 2014 12:39:41 -0700 Message-Id: <330DB822-0C7C-489E-807D-2612B6631B2B@oracle.com> References: To: Darshana Gunawardana 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/lwHqcYukQQ-5d_8tj_djF1qvzcI Cc: "scim@ietf.org" Subject: Re: [scim] What are the response attributes when calling SCIM filter 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, 04 Oct 2014 19:39:51 -0000 --Apple-Mail=_377934BC-5618-4028-A645-DD9857A63CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Darshana, No problem. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 4, 2014, at 12:22 PM, Darshana Gunawardana = wrote: > Hi Phil, >=20 > Oh.. I thinks my previous mail was bit ambiguous.. Sorry for that.. = I'm agree that SCIM2 has the flexibility to define which attributes = should return. >=20 > In my earlier response what i meant was, I need to look deep-in my = implementation details and find optimal solution.. It wasn't meant to = suggest to change the spec.. >=20 > I got answers for my original question, "what attributes should return = in a user filter response" and the answer was "as per SCIM2 it depends = on the 'returned' meta attribute in user schema". >=20 > So we can conclude the thread i guess.. >=20 > Thanks, > Darshana >=20 > On Sun, Oct 5, 2014 at 12:19 AM, Phil Hunt = wrote: > Dashana, >=20 > I am not sure what you are suggesting/proposing.=20 >=20 > If anything SCIM2 already has a lot of functionality to control which = attributes are returned per request that is similar in nature to LDAP. = LDAP protocol returns all attributes by default except for =91operational'= attributes. If anything, SCIM returns slightly fewer attributes and = allows for configured flexibility (as with LDAP). >=20 > In SCIM, returning only =93id=94 is easily achieved using the = attributes qualifier. >=20 > What are you suggesting we change exactly? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 4, 2014, at 11:22 AM, Darshana Gunawardana = wrote: >=20 >> Hi Phil, >>=20 >> Yes, changing to return only id in the filtering, make some existing = clients to do extra work. We need to do some research to find optimal = solution to keep reduce ldap calls while compatible with all existing = clients.. >>=20 >> Thanks a lot for your input.. >>=20 >> Regards, >> Dashana >>=20 >> On Thu, Oct 2, 2014 at 9:42 AM, Phil Hunt = wrote: >> If you want that behavior you could have the client request = attributes=3Did.=20 >>=20 >> In general only privileged users should be able to return all entries = and all attrs.=20 >>=20 >> You can also change returned to "request" to get the behavior you = want and that would be legit. However you could expect some clients to = react badly.=20 >>=20 >> Better to limit max results for most users and limit what avg = low-priv users can see.=20 >>=20 >> Phil >>=20 >> On Oct 1, 2014, at 20:58, Darshana Gunawardana = wrote: >>=20 >>> Hi Phil, >>>=20 >>> Thanks for the response. >>>=20 >>> Seems like SCIM 2 have well defined structure for attributes = returning. >>>=20 >>> When i look for User schema it have almost all of attributes have = returned value as default. In the attribute required the value default = defined as follows, >>> "default : The attribute is returned by default in all SCIM = operation responses where attribute values are returned" >>> So the question is whether SCIM filter operation response is a one = of those operations which should contains attribute values? >>>=20 >>> I'm having this problem due to our current implementation return all = attributes for users which matches search filter which seems to be = compliant with the SCIM 2 spec as well. And currently our maxResults for = filter operation is not limited. Hence it takes unacceptable time to = build whole response for filter operations in large user base. >>>=20 >>> When we do a profiling, we identified that to search in whole user = base and return 1000 user id takes time in milliseconds, but to build = response which contains 1000 users with all attributes takes time like 5 = minutes. As for a improvement, our initial thought was only returning = scim id is sufficient, when filter request does not specified the = parameter "attributes". >>>=20 >>> Wanted to confirm whether this way is compliant with the spec or = whether it is defined, returning id only is not sufficient and specific = set attributes also should always returned for each user in filtering. >>>=20 >>> Thanks, >>> Darshana. >>>=20 >>> On Wed, Oct 1, 2014 at 9:40 PM, Phil Hunt = wrote: >>> This is resolved in scim 2. Look under schemas for the attribute = meta item "returned".=20 >>>=20 >>> Phil >>>=20 >>> On Oct 1, 2014, at 7:36, Darshana Gunawardana = wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I'm working on a improvement on SCIM user filtering capabilities in = WSO2 Charon implementation which is based on SCIM 1.1. >>>>=20 >>>> While implementing, I couldn't find in the spec, what are the bare = minimum attributes should be in SCIM response. I have search this in = section 3.2.2.1 in [1]. >>>>=20 >>>> In section 3.2, it specify generally when retrieving resources, >>>> "Service Providers MAY choose to respond with a sub-set of Resource = attributes, though MUST minimally return the Resource id and meta = attributes" >>>>=20 >>>> Does the same rule apply in filtering also? >>>>=20 >>>> [1] = http://www.simplecloud.info/specs/draft-scim-api-01.html#query-resources >>>>=20 >>>> Thanks, >>>> Darshana >>>>=20 >>>> --=20 >>>> With Regards, >>>>=20 >>>> Darshana Gunawardana, >>>> Alumni : Dept. of Computer Science & Engineering, >>>> University of Moratuwa, >>>> Sri Lanka >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >>>=20 >>> --=20 >>> With Regards, >>>=20 >>> Darshana Gunawardana, >>> Alumni : Dept. of Computer Science & Engineering, >>> University of Moratuwa, >>> Sri Lanka >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> --=20 >> With Regards, >>=20 >> Darshana Gunawardana, >> Alumni : Dept. of Computer Science & Engineering, >> University of Moratuwa, >> Sri Lanka >=20 >=20 >=20 >=20 > --=20 > With Regards, >=20 > Darshana Gunawardana, > Alumni : Dept. of Computer Science & Engineering, > University of Moratuwa, > Sri Lanka > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_377934BC-5618-4028-A645-DD9857A63CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Darshana,

No = problem.

Cheers,


On Oct 4, 2014, at 12:22 PM, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi Phil,

Oh.. I thinks = my previous mail was bit ambiguous..  Sorry for that.. I'm agree = that SCIM2 has the flexibility to define which attributes should = return.

In my earlier response what i meant = was, I need to look deep-in my implementation details and&nbs= p;find optimal solution.. = It wasn't meant to suggest to change the = spec..

I got = answers for my original question, "what attributes should return in a = user filter response" and the answer was "as per SCIM2 it depends on the = 'returned' meta attribute in user schema".

So we can conclude the thread i = guess..

Thanks,
Darshana

On Sun, Oct 5, 2014 at 12:19 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Dashana,

I am = not sure what you are suggesting/proposing. 

If = anything SCIM2 already has a lot of functionality to control which = attributes are returned per request that is similar in nature to LDAP. = LDAP protocol returns all attributes by default except for =91operational'= attributes. If anything, SCIM returns slightly fewer attributes and = allows for configured flexibility (as with = LDAP).

In SCIM, returning only =93id=94 is = easily achieved using the attributes = qualifier.

What are you suggesting we change = exactly?


On Oct 4, 2014, at 11:22 AM, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi = Phil,

Yes, changing to return only id in the = filtering, make some existing clients to do extra work. We need to do = some research to find optimal solution to keep reduce ldap calls while = compatible with all existing clients..

Thanks a = lot for your = input..

Regards,
Dashana

On Thu, Oct 2, = 2014 at 9:42 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
If you want that = behavior you could have the client request = attributes=3Did. 

In general only = privileged users should be able to return all entries and all = attrs. 

You can also change returned to = "request" to get the behavior you want and that would be legit. However = you could expect some clients to react = badly. 

Better to limit max results for = most users and limit what avg low-priv users can see. 

Phil

On Oct = 1, 2014, at 20:58, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi = Phil,

Thanks for the = response.

Seems like SCIM 2 have well defined = structure for attributes returning.

When i look = for User schema it have almost all of attributes have returned value as = default. In the attribute required the value default defined as = follows,
   "default : The attribute is returned by = default in all SCIM operation responses where attribute values are = returned"
So the question is whether SCIM filter operation = response is a one of those operations which should contains attribute = values?

I'm having this problem due to our = current implementation return all attributes for users which matches = search filter which seems to be compliant with the SCIM 2 spec as well. = And currently our maxResults for = filter operation is not limited. Hence it takes unacceptable time to = build whole response for filter operations in large user = base.

When we do a profiling, we identified that to = search in whole user base and return 1000 user id takes time in = milliseconds, but to build response which contains 1000 users with all attributes takes time like = 5 minutes. As for a = improvement, our initial thought was only returning scim id = is sufficient, when filter request does = not specified the parameter = "attributes".

Wanted = to confirm whether this way is compliant with the spec or = whether it is defined, returning id only is = not sufficient and specific set attributes also = should always returned for each user in = filtering.

Thanks,
Darshana.

On Wed, Oct 1, 2014 = at 9:40 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This is resolved = in scim 2. Look under schemas for the attribute meta item = "returned". 

Phil

On Oct 1, 2014, at = 7:36, Darshana Gunawardana <darshanasbg@gmail.com> = wrote:

Hi = all,

I'm working on a improvement on SCIM user = filtering capabilities in WSO2 Charon implementation which is based = on SCIM 1.1.

While implementing, I = couldn't find in the spec, what are the bare minimum attributes should = be in SCIM response. I have search this in section 3.2.2.1 in = [1].

In section 3.2, it specify generally when = retrieving resources,
"Service Providers MAY choose to respond = with a sub-set of Resource attributes, though MUST minimally return the = Resource id and meta attributes"

Does the same = rule apply in filtering also?


Thanks,
Darshana

--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka
_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka
_______________________________________________=
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim



--
With = Regards,

Darshana Gunawardana,
Alumni : Dept. of = Computer Science & Engineering,
University of Moratuwa,
Sri = Lanka
=




--
With Regards,

Darshana = Gunawardana,
Alumni : Dept. of Computer Science & = Engineering,
University of Moratuwa,
Sri Lanka
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_377934BC-5618-4028-A645-DD9857A63CBF-- From nobody Mon Oct 6 10:20: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 9C7801A8722; Mon, 6 Oct 2014 10:20:10 -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 D1ttHR4OBroe; Mon, 6 Oct 2014 10:20:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B9A1A86FD; Mon, 6 Oct 2014 10:20:08 -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.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006172008.29486.23364.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 10:20:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aIUMm7XtyyZsNlxz4j3GeP0PJgY Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-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: Mon, 06 Oct 2014 17:20:11 -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-11.txt Pages : 66 Date : 2014-10-06 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-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 Mon Oct 6 10:23: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 E7EE71A86F3 for ; Mon, 6 Oct 2014 10:23:31 -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 ZxlHmu2hk7l3 for ; Mon, 6 Oct 2014 10:23:29 -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 00E591A86E4 for ; Mon, 6 Oct 2014 10:23:28 -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 s96HNRf1006054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Oct 2014 17:23:28 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 s96HNQwW009155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Oct 2014 17:23:27 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96HNQ85005562 for ; Mon, 6 Oct 2014 17:23:26 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Oct 2014 10:23:25 -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: <20141006172008.29486.23364.idtracker@ietfa.amsl.com> Date: Mon, 6 Oct 2014 10:23:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C1FFCB5-8B42-4B60-AB56-E6C4A768E9A9@oracle.com> References: <20141006172008.29486.23364.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/jk56CmJqKjWlJ5T7U4eCZhL1VpU Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-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: Mon, 06 Oct 2014 17:23:33 -0000 This update resolves the last discussion item in the group regarding = =93externalId=94 and includes new definition text put forward to the = list last week. No other changes were made. There is no parallel update planned for the scim API draft. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 6, 2014, at 10:20 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: = Core Schema > Authors : Phil Hunt > Kelly Grizzle > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-11.txt > Pages : 66 > Date : 2014-10-06 >=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-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-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 Mon Oct 6 11:11:38 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 1E4C21A877C for ; Mon, 6 Oct 2014 11:11:36 -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 ApsgvKYtW959 for ; Mon, 6 Oct 2014 11:11:35 -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 E46771A8779 for ; Mon, 6 Oct 2014 11:11:34 -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 s96IBXOU001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Oct 2014 18:11:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s96IBWQp021892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Oct 2014 18:11:33 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96IBVQT002279 for ; Mon, 6 Oct 2014 18:11:32 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Oct 2014 11:11:31 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) Message-Id: <18B7EF3A-2A2D-4D07-803E-8CFF7AAE8E79@oracle.com> Date: Mon, 6 Oct 2014 11:11:29 -0700 To: "scim@ietf.org WG" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QZF-Xo9DOywcBjXdmgRIONegh9I Subject: [scim] Request to start WGLC 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, 06 Oct 2014 18:11:36 -0000 Chairs, As editor, I believe all outstanding items are resolved with today's draft s= ubmission.=20 I propose that we begin the WGLC process.=20 Regards, Phil= From nobody Mon Oct 6 11:27: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 5F3BE1A87C5 for ; Mon, 6 Oct 2014 11:27:20 -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 aRC1nhGg3rjr for ; Mon, 6 Oct 2014 11:27:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657981A87C0 for ; Mon, 6 Oct 2014 11:27:18 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so4869132lbj.3 for ; Mon, 06 Oct 2014 11:27:16 -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=aJbHbEtmCLFtaz/31CNdfXnxD1Rsvw8HD3vTVqijZWE=; b=T7B7qoO72FvnGKOAvglAdhBbuLLzryTsdYeXZw6pGclCGIdbYMsmfcTK4Yso5wzFey E/vMzGKiUvPduQLDZPnPMNP/z98F16oUzlTkf9Q7CSADM8aoFwfxnu9/9tgjDnqVkTKl 2Hf893OAwRTRjsUnqrDN7LpOwkL67pdaaa9QrIMe4S02x/Mv6J95RrpaPru9rMS0YzQN XJ3yl0tTh/MwYx1DrYtsCyqVqkuyGzxgZ6p+dABYZRFviBPRE+2PVAik1EAIhDC7PB7/ TpVK7GjmCbcVq8miEFaN+WP4yP7NFxFesqqunVi/0oc5jpLnO8d6cHKG9mjVGThTyw8j iXyg== X-Gm-Message-State: ALoCoQna9JGeUWyCqQJVCxaWjQ1sKg02OuAwLzrOeg+VuuactEQlRzfH+fgrARO0QB5nsvlwGFO+ X-Received: by 10.112.156.227 with SMTP id wh3mr25397704lbb.23.1412620036669; Mon, 06 Oct 2014 11:27:16 -0700 (PDT) Received: from [192.168.50.183] (scandic806.host.songnetworks.se. [212.214.188.210]) by mx.google.com with ESMTPSA id pw9sm5976372lbb.2.2014.10.06.11.27.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Oct 2014 11:27:16 -0700 (PDT) Message-ID: <5432DF01.6080009@mnt.se> Date: Mon, 06 Oct 2014 20:27:13 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: scim@ietf.org References: <18B7EF3A-2A2D-4D07-803E-8CFF7AAE8E79@oracle.com> In-Reply-To: <18B7EF3A-2A2D-4D07-803E-8CFF7AAE8E79@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Jtd7qJwsTnxtciwM0mpcguO-QHI Subject: Re: [scim] Request to start WGLC 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, 06 Oct 2014 18:27:20 -0000 On 2014-10-06 20:11, Phil Hunt wrote: > Chairs, > > As editor, I believe all outstanding items are resolved with today's draft submission. > > I propose that we begin the WGLC process. > I concur (for the chairs). We'll start the WGLC tomorrow unless there are objections from the WG. If you object to starting the WGLC, please include at least one issue that you believe the WG won't be able to handle during WGLC. Cheers Leif From nobody Thu Oct 9 07:00:29 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 85A7C1A19E8 for ; Thu, 9 Oct 2014 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 uTUGUhXfo2Aa for ; Thu, 9 Oct 2014 07:00:24 -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 3FA9F1A064C for ; Thu, 9 Oct 2014 07:00:24 -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 s99E0L1n001664 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Oct 2014 16:00:21 +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 s99E0IYk004883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2014 16:00:21 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [109.105.104.238] ([109.105.104.238]) (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; Thu, 9 Oct 2014 16:00:17 +0200 Message-ID: <543694F1.3010407@sunet.se> Date: Thu, 09 Oct 2014 16:00:17 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: 09N120lQC - 47b7756ece06 - 20141009 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NT8wg8iwowpxKr0VTs-4BznPZ34 Subject: [scim] WGCL core-schema & api (-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: Thu, 09 Oct 2014 14:00:26 -0000 This starts a 2 week Working Group Last Call on the following documents: draft-ietf-scim-core-schema-11 draft-ietf-scim-api-11 Please provide your final comments by EOB (any tz) 23 October 2014 to the list. Best R Leif & Morteza From nobody Sat Oct 11 03:51: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 165351A02DD for ; Sat, 11 Oct 2014 03:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-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 Ilyr47Prph5S for ; Sat, 11 Oct 2014 03:51:27 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F26B1A01E1 for ; Sat, 11 Oct 2014 03:51:27 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so4333535lbv.5 for ; Sat, 11 Oct 2014 03:51:25 -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:content-type:content-transfer-encoding; bh=BMNofEciTI+CCJHgDvsxI3opPH139MGwBwIPxrD7XxI=; b=QZaoyz/VPO+ILcGDdE5+sKT11lTNZeH3jtB0GXgc2+yoEPIsX9rs8TtQuQjhMc7BTJ A3sLRiofsbfTOifdQaDSLqYBu3NtMAtiYjX8O1xG2oj0FyY9lJ5Z/X1BG8xNo4lHYbpf Ffcmr4DSzpO6ABHkrwk0srOaG2/ACwcIoR4D5+QjExpUZShamShWCAwiQ7hIWEk2VPoH drVHLwDQlVm8t9VR2y4ipA0L9rgi3vDOd5Mu8QrIYGGkEUuu0bDs454soohxIDOud4HC e6p86WrpHF68aeT+Mw9Q2FZXSaiywAhd0ok9IVnJwqLz2uypsXii80HmCmTH6Vb0h0xs 7jlA== X-Gm-Message-State: ALoCoQnJDr/ffgk26kNkPVEZY5VgkNXtk0FFYPc1nqptFhOnWfeYNaZNcjVZDEYdtaFEV25iGeA/ X-Received: by 10.112.34.239 with SMTP id c15mr10556905lbj.64.1413024685271; Sat, 11 Oct 2014 03:51:25 -0700 (PDT) Received: from [172.20.10.3] (2.67.121.202.mobile.tre.se. [2.67.121.202]) by mx.google.com with ESMTPSA id tr10sm2586600lbb.1.2014.10.11.03.51.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Oct 2014 03:51:24 -0700 (PDT) Message-ID: <54390BAB.5050208@mnt.se> Date: Sat, 11 Oct 2014 12:51:23 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/oDM8swsg6f0eIMPJn3dzJJkHeL4 Subject: [scim] Planning 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: Sat, 11 Oct 2014 10:51:29 -0000 Folks, We've been scheduled on Friday afternoon (1150-1320). Given that our core documents are in WGLC and we expect them to be well under way to IESG by Hawaii we should be using our time in Hawaii to talk about next steps for the WG. To that end I encourage everyone who has been sitting on a draft about a possible SCIM extension to get those out now! Cheers Leif From nobody Tue Oct 14 10:19: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 723A61A9068 for ; Tue, 14 Oct 2014 10:19:24 -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 ZVQCszDm8t9m for ; Tue, 14 Oct 2014 10:19:18 -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 89E241A907D for ; Tue, 14 Oct 2014 10:19:17 -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 s9EHJFE1011270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Oct 2014 17:19:16 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 s9EHJFqI008972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2014 17:19:15 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9EHJEe0001140; Tue, 14 Oct 2014 17:19:14 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Oct 2014 10:19:13 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B47DA64-F4A5-495A-B501-81DDC7BDB2D5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <9098A202-EE20-46B5-A3AA-E68D22F0E93C@yahoo.com> Date: Tue, 14 Oct 2014 10:19:12 -0700 Message-Id: <3D9622E6-17E0-4A9A-9B1D-1C6DB4DC4E6D@oracle.com> References: <543CC579.8090000@oracle.com> <9098A202-EE20-46B5-A3AA-E68D22F0E93C@yahoo.com> To: SCIM WG 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/lD0k1VUK0HVD4Zie-6stE0cPga8 Cc: nikhil vaishnavi , draft-ietf-scim-core-schema@tools.ietf.org Subject: Re: [scim] draft-ietf-scim-core-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, 14 Oct 2014 17:19:24 -0000 --Apple-Mail=_6B47DA64-F4A5-495A-B501-81DDC7BDB2D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Adding the WG mailing list=85 You are correct. The examples should be updated to use =93value=94 as = per the original definition. This was discussed a while back and I = believe the group decided to be consistent with multi-valued attributes. Note, the schema also needs to be updated. It looks like it should be = multi-valued since many orgs have people with multiple reporting = relationships. Phil (resending as I originally sent as phil.hunt@yahoo.com) On Oct 13, 2014, at 11:40 PM, nikhil vaishnavi = wrote: > Hi, > I noticed that for the Enterprise User Schema Extension [Section 4.3 - = page 19], the attributes mentioned for manager are : value, $ref & = displayName. > While the value attribute definition mentions this is the id = representing the manager, the schema representation in JSON format = defined on page 54 mentions this field as 'managerId' as well as other = examples show is as managerId too. > Can this be synced up so that there is no confusion which is the = current definition of the field. >=20 > Thanks > Nikhil Vaishnavi --Apple-Mail=_6B47DA64-F4A5-495A-B501-81DDC7BDB2D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Adding the WG mailing list=85

You = are correct. The examples should be updated to use =93value=94 as per = the original definition. This was discussed a while back and I believe = the group decided to be consistent with multi-valued = attributes.

Note, the schema also needs to be = updated. It looks like it should be multi-valued since many orgs have = people with multiple reporting relationships.


(resending as I originally sent = as phil.hunt@yahoo.com)
nikhil.vaishnavi@oracle.com> wrote:

=20 =20
Hi,
I noticed that for the Enterprise User Schema Extension [Section 4.3 - page 19], the attributes mentioned for manager are : value, $ref & displayName.
While the value attribute definition mentions this is the id = representing the manager, the schema representation in JSON format defined on page 54 mentions this field as 'managerId' as well as other examples show is as managerId too.
Can this be synced up so that there is no confusion which is the current definition of the field.

Thanks
Nikhil Vaishnavi


= --Apple-Mail=_6B47DA64-F4A5-495A-B501-81DDC7BDB2D5-- From nobody Fri Oct 17 00:56: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 B8C4E1A9106 for ; Fri, 17 Oct 2014 00:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UK5QLY3Krpsu for ; Fri, 17 Oct 2014 00:56:16 -0700 (PDT) Received: from c15s9xb8.securesites.net (c15s9xb8.securesites.net [118.23.75.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AFC1A9103 for ; Fri, 17 Oct 2014 00:56:15 -0700 (PDT) Received: from [192.168.2.6] (softbank126087057008.bbtec.net [126.87.57.8]) (authenticated bits=0) by c15s9xb8.securesites.net (8.14.5/8.13.1) with ESMTP id s9H7uB2X031901 for ; Fri, 17 Oct 2014 16:56:13 +0900 MIME-Version: 1.0 Date: Fri, 17 Oct 2014 16:56:11 +0900 Message-ID: From: ueda@exgen.co.jp To: scim@ietf.org X-Mailer: JsvMail 9.0 (Shuriken 2009) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/M3g2GPNogVV6Y43sobp2CTabwMs Subject: [scim] Schema representation of members 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, 17 Oct 2014 07:56:16 -0000 Hello, I have a question. In section 8.7 of schema document, "multiValued" is "false" in "members" attribute of group. Is this "true"? - Takanori Ueda. From nobody Fri Oct 17 09:03: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 8FAE21A1B7E for ; Fri, 17 Oct 2014 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFlgF3PrxX2X for ; Fri, 17 Oct 2014 09:03:52 -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 5F3FF1A00F2 for ; Fri, 17 Oct 2014 09:03:52 -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 s9HG3gC5019379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Oct 2014 16:03:45 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 s9HG3fhA000561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 16:03:42 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 s9HG3eWv000519; Fri, 17 Oct 2014 16:03:41 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2014 09:03:40 -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: Fri, 17 Oct 2014 09:03:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42B7829D-9D31-4311-8D6B-12FB8B61B61D@oracle.com> References: To: ueda@exgen.co.jp 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/YLh-JmYYnaotxVBpaulYfZZMVLw Cc: scim@ietf.org Subject: Re: [scim] Schema representation of members 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, 17 Oct 2014 16:03:53 -0000 Thanks. This should be multi-valued.=20 I will add to the list of =93nits=94. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 17, 2014, at 12:56 AM, ueda@exgen.co.jp wrote: > Hello, >=20 > I have a question. >=20 > In section 8.7 of schema document, > "multiValued" is "false" in "members" attribute of group. > Is this "true"? >=20 > - > Takanori Ueda. >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Fri Oct 17 12:37: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 51ACB1A6F9A; Fri, 17 Oct 2014 12:37:52 -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 HP5zsW2N1KFU; Fri, 17 Oct 2014 12:37:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE511A0041; Fri, 17 Oct 2014 12:37:50 -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.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141017193750.7904.86168.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 12:37:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/gkweQRmNj7eEMb2xAzydUz7lYG8 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-12.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: Fri, 17 Oct 2014 19:37:52 -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-12.txt Pages : 69 Date : 2014-10-17 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-12 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 Fri Oct 17 12:46: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 2BA401A6FB5 for ; Fri, 17 Oct 2014 12:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iBESNnNlUjm for ; Fri, 17 Oct 2014 12:46:53 -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 91DC31A6FAD for ; Fri, 17 Oct 2014 12:46:53 -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 s9HJkpg8024404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Oct 2014 19:46:52 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9HJkpaY013467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Oct 2014 19:46:51 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9HJkppZ013458 for ; Fri, 17 Oct 2014 19:46:51 GMT Received: from [192.168.1.197] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2014 12:46:50 -0700 References: <20141017193750.7904.86168.idtracker@ietfa.amsl.com> From: Phil Hunt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) In-Reply-To: <20141017193750.7904.86168.idtracker@ietfa.amsl.com> Message-Id: <30AB4FF1-9ACC-4B6D-A68F-1804CB854662@oracle.com> Date: Fri, 17 Oct 2014 12:46:48 -0700 To: "scim@ietf.org WG" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LFzCmOHH2Y6_KJbEAvjvCphEaQs Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-12.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: Fri, 17 Oct 2014 19:46:56 -0000 This draft includes changes to address editorial nits regarding line lengths= (in draft), and corrections where json examples do not match text.=20 This includes comments received on the mailing list up to early this morning= pacific time.=20 See the change list in the appendix for more information.=20 Phil > On Oct 17, 2014, at 12:37, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the System for Cross-domain Identity Manageme= nt 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-12.txt > Pages : 69 > Date : 2014-10-17 >=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-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > 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 Mon Oct 20 11:09:42 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 359581A8A96; Mon, 20 Oct 2014 11:09:39 -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 JWt5PnipzDY0; Mon, 20 Oct 2014 11:09:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABAA1A8A6B; Mon, 20 Oct 2014 11:09:37 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020180937.4271.72998.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 11:09:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/FtHgl-u3gwNhf8T6hqhYpIWrrAY Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-12.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, 20 Oct 2014 18:09:39 -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-12.txt Pages : 78 Date : 2014-10-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. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-12 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 Oct 20 11:12: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 DE9BD1A8A92 for ; Mon, 20 Oct 2014 11:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc-Bx2JWCK7P for ; Mon, 20 Oct 2014 11:12:26 -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 412841A8A7A for ; Mon, 20 Oct 2014 11:12:25 -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 s9KICNsp014675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Oct 2014 18:12:24 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 s9KICMhX002210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Oct 2014 18:12:23 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9KICMS2011585 for ; Mon, 20 Oct 2014 18:12:22 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Oct 2014 11:12:21 -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: <20141020180937.4271.72998.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 11:12:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141020180937.4271.72998.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/jCLz9f6scU-lW3O2JNdhbPP5t-I Subject: Re: [scim] I-D Action: draft-ietf-scim-api-12.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, 20 Oct 2014 18:12:29 -0000 This update is in parallel with the version 12 update of core-schema. = The update includes only minor changes addressing NITs such as updating = RFC references to current versions and adjusting line-lengths to some = examples so as not to exceed 72 characters. The changes to core-schema and api documents were made as part of = cleaning up final =93nits=94 in the WGLC process. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 20, 2014, at 11:09 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-12.txt > Pages : 78 > Date : 2014-10-20 >=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-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-12 >=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 Mon Oct 20 19:53: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 D3CFF1A1AB0 for ; Mon, 20 Oct 2014 19:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vMioP0mgKcQL for ; Mon, 20 Oct 2014 19:53:12 -0700 (PDT) Received: from c15s9xb8.securesites.net (c15s9xb8.securesites.net [118.23.75.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1511A1AA7 for ; Mon, 20 Oct 2014 19:53:11 -0700 (PDT) Received: from [192.168.2.236] (122x220x11x94.ap122.ftth.ucom.ne.jp [122.220.11.94]) (authenticated bits=0) by c15s9xb8.securesites.net (8.14.5/8.13.1) with ESMTP id s9L2r7fH003911 for ; Tue, 21 Oct 2014 11:53:10 +0900 MIME-Version: 1.0 Date: Tue, 21 Oct 2014 11:53:07 +0900 Message-ID: From: ueda@exgen.co.jp To: scim@ietf.org X-Mailer: JsvMail 9.0 (Shuriken 2009) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/scim/llLDJV53p-R2jkUP-d4ZWHRgJbI Subject: [scim] PATCH method in 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: Tue, 21 Oct 2014 02:53:14 -0000 Hello In section 3.5.3(page 52) of api document, PATCH method is written as follows. "method": "PATCH", "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "version": "W/\"edac3253e2c0ef2\"", "data": {[ { "op": "remove", "path": "nickName" }, Questions. 1."schemas" attrribute is not need in "data"? 2."Operations" attribute is not need in "data"? as follows. "method": "PATCH", "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "version": "W/\"edac3253e2c0ef2\"", "data": { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [ { "op": "remove", "path": "nickName" }, - Takanori Ueda. From nobody Tue Oct 21 06:11:43 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 DC3781A1B5F for ; Tue, 21 Oct 2014 06:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1b7YtVGpRJp7 for ; Tue, 21 Oct 2014 06:11:38 -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 C43851A1B4F for ; Tue, 21 Oct 2014 06:11:37 -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; Tue, 21 Oct 2014 15:11:20 +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; Tue, 21 Oct 2014 15:11:20 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m=2C_neXus?= To: "ueda@exgen.co.jp" Thread-Topic: [scim] PATCH method in Bulk Thread-Index: AQHP7NourojJVHAqcUG7MPf8xE6O/pw6ZcWA Date: Tue, 21 Oct 2014 13:11:19 +0000 Message-ID: References: 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.76.115.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/c1vbgs6UJ7iXEvkKW38sUSW99F0 Cc: "scim@ietf.org" Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 13:11:40 -0000 Yes. Looks like it=92s a typo in the spec. Should be a standard PATCH call = within the data attribute. / Erik On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote: > Hello >=20 > In section 3.5.3(page 52) of api document, > PATCH method is written as follows. >=20 > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {[ > { > "op": "remove", > "path": "nickName" > }, >=20 > Questions. >=20 > 1."schemas" attrribute is not need in "data"? > 2."Operations" attribute is not need in "data"? >=20 > as follows. >=20 > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > "Operations": [ > { > "op": "remove", > "path": "nickName" > }, >=20 > - > Takanori Ueda. >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Oct 21 08:44: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 267B41A8861 for ; Tue, 21 Oct 2014 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e__xdnPYLXU for ; Tue, 21 Oct 2014 08:44:27 -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 E4FD41A8869 for ; Tue, 21 Oct 2014 08:43:49 -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 s9LFhhta031075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Oct 2014 15:43: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 s9LFhgjs014091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 15:43:43 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 s9LFhgM9014082; Tue, 21 Oct 2014 15:43:42 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 08:43:42 -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: Tue, 21 Oct 2014 08:43:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> References: To: =?windows-1252?Q?=22Erik_Wahlstr=F6m=2C_neXus=22?= 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/FhONrorCBx2i0VzqHv3ULwSi9II Cc: "scim@ietf.org" , "ueda@exgen.co.jp" Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 15:44:33 -0000 I agree, the PATCH operation is not consistent. We shall need to put some clarifying text that the outer path applies to = selection of the resource (in place of URL) and the inner path for the = operation applies to attribute/value selection. The rule of thumb should be that the JSON blob within the =93data=94 = attribute should match the body payload of any other SCIM HTTP request? = Correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus = wrote: > Yes. Looks like it=92s a typo in the spec. Should be a standard PATCH = call within the data attribute. > / Erik >=20 > On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote: >=20 >> Hello >>=20 >> In section 3.5.3(page 52) of api document, >> PATCH method is written as follows. >>=20 >> "method": "PATCH", >> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >> "version": "W/\"edac3253e2c0ef2\"", >> "data": {[ >> { >> "op": "remove", >> "path": "nickName" >> }, >>=20 >> Questions. >>=20 >> 1."schemas" attrribute is not need in "data"? >> 2."Operations" attribute is not need in "data"? >>=20 >> as follows. >>=20 >> "method": "PATCH", >> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >> "version": "W/\"edac3253e2c0ef2\"", >> "data": { >> "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], >> "Operations": [ >> { >> "op": "remove", >> "path": "nickName" >> }, >>=20 >> - >> Takanori Ueda. >>=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 Tue Oct 21 08:53:36 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 2E1271A87D0 for ; Tue, 21 Oct 2014 08:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hISi_myOTSSS for ; Tue, 21 Oct 2014 08:53:31 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2401A6EFF for ; Tue, 21 Oct 2014 08:53:13 -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 s9LFrBZS3395768 for ; Tue, 21 Oct 2014 11:53:11 -0400 Date: Tue, 21 Oct 2014 11:53:10 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu> In-Reply-To: <1546154213.2147362.1413906661592.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: address.display versus address.formatted Thread-Index: oZ1xwZXCoxroI3SCG/sdCVLJqFxCjQ== X-Virus-Scanned: by amavisd-new Archived-At: http://mailarchive.ietf.org/arch/msg/scim/LlZjpwGmooSeM99ai4mR8EV5E0c Subject: [scim] address.display versus address.formatted 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: Tue, 21 Oct 2014 15:53:35 -0000 Are the address.display attribute (inherited from SCIM Multi-Valued Attribu= te) and the address.formatted attribute (part of the address definition) am= biguous? Can anyone provide insight into how they're being used? Our curr= ent implementation sets address.formatted and ignores address.display but I= 'm curious to know how others are populating these fields. Thanks, Steve -- =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 Tue Oct 21 09:16:45 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 1AEC71A8900 for ; Tue, 21 Oct 2014 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72wfx69d56GL for ; Tue, 21 Oct 2014 09:16:43 -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 D92291A88BB for ; Tue, 21 Oct 2014 09:16:42 -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 s9LGGe5E017136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Oct 2014 16:16:41 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 s9LGGd8c007489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 16:16:39 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9LGGcFs013417; Tue, 21 Oct 2014 16:16:39 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 09:16:38 -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: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu> Date: Tue, 21 Oct 2014 09:16:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu> To: Steve Moyer 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/zTqKHe9rMznSMLkvjObSoEKPluE Cc: scim@ietf.org Subject: Re: [scim] address.display versus address.formatted 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, 21 Oct 2014 16:16:44 -0000 +1 Thanks Steve. Curious to hear what others have implemented too. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 21, 2014, at 8:53 AM, Steve Moyer wrote: > Are the address.display attribute (inherited from SCIM Multi-Valued = Attribute) and the address.formatted attribute (part of the address = definition) ambiguous? Can anyone provide insight into how they're = being used? Our current implementation sets address.formatted and = ignores address.display but I'm curious to know how others are = populating these fields. >=20 > Thanks, >=20 > Steve >=20 > -- >=20 > =93The 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.=94 - Wilhelm Stekel >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Oct 21 11:17: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 B48411A6F07 for ; Tue, 21 Oct 2014 11:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id micVtmb00WYm for ; Tue, 21 Oct 2014 11:17:47 -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 306B81A6EF2 for ; Tue, 21 Oct 2014 11:17:47 -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 s9LIHcYK027756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Oct 2014 18:17:39 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 s9LIHbFe022834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 18:17:38 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9LIHbsX028594; Tue, 21 Oct 2014 18:17:37 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 11:17:36 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_B511AF95-B098-4B4E-BF4C-8EF45ECB58F5" Message-Id: <2508B747-F882-4205-8D99-E1E40307E790@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 21 Oct 2014 11:17:35 -0700 In-Reply-To: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> References: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> 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/-ISDRYiyhNZuuYZZhaEqJ9-u6Bc Cc: "ueda@exgen.co.jp" , =?iso-8859-1?Q?=22Erik_Wahlstr=F6m=2C_neXus=22?= , "scim@ietf.org" Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 18:17:50 -0000 --Apple-Mail=_B511AF95-B098-4B4E-BF4C-8EF45ECB58F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looking this over, it looks like the example is erroneous: =85=20 { "method": "PATCH", "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "version": "W/\"edac3253e2c0ef2\"", "data": {[ { "op": "remove", "path": "nickName" }, { "op": "add", "path": "userName", "value": "Dave" } ]} =85 It should be changed to (full example included): POST /v2/Bulk Host: example.com Accept: application/scim+json Content-Type: application/scim+json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"], "failOnErrors":1, "Operations":[ { "method":"POST", "path":"/Users", "bulkId":"qwerty", "data":{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"], "userName":"Alice" } }, { "method":"PUT", "path":"/Users/b7c14771-226c-4d05-8860-134711653041", "version":"W\/\"3694e05e9dff591\"", "data":{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id":"b7c14771-226c-4d05-8860-134711653041", "userName":"Bob" } }, { "method": "PATCH", "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", "version": "W/\"edac3253e2c0ef2\"", "data": { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [ { =93schemas=94:[" "op": "remove", "path": "nickName" }, { "op": "add", "path": "userName", "value": "Dave" } ] } }, { "method":"DELETE", "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", "version":"W\/\"0ee8add0a938e1a\"" } ] } If any have implemented according to the erroneous example and object to = the change, please let the list know. Regards, Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 21, 2014, at 8:43 AM, Phil Hunt wrote: > I agree, the PATCH operation is not consistent. >=20 > We shall need to put some clarifying text that the outer path applies = to selection of the resource (in place of URL) and the inner path for = the operation applies to attribute/value selection. >=20 > The rule of thumb should be that the JSON blob within the =93data=94 = attribute should match the body payload of any other SCIM HTTP request? = Correct? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus = wrote: >=20 >> Yes. Looks like it=92s a typo in the spec. Should be a standard PATCH = call within the data attribute. >> / Erik >>=20 >> On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote: >>=20 >>> Hello >>>=20 >>> In section 3.5.3(page 52) of api document, >>> PATCH method is written as follows. >>>=20 >>> "method": "PATCH", >>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>> "version": "W/\"edac3253e2c0ef2\"", >>> "data": {[ >>> { >>> "op": "remove", >>> "path": "nickName" >>> }, >>>=20 >>> Questions. >>>=20 >>> 1."schemas" attrribute is not need in "data"? >>> 2."Operations" attribute is not need in "data"? >>>=20 >>> as follows. >>>=20 >>> "method": "PATCH", >>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>> "version": "W/\"edac3253e2c0ef2\"", >>> "data": { >>> "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], >>> "Operations": [ >>> { >>> "op": "remove", >>> "path": "nickName" >>> }, >>>=20 >>> - >>> Takanori Ueda. >>>=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 --Apple-Mail=_B511AF95-B098-4B4E-BF4C-8EF45ECB58F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Looking this over, it looks like = the example is erroneous:
       =85 =

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       =85

It should be changed to (full example = included):

   POST /v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },
       {

         "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           =
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               =
{
     =
             =93schemas=94:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
     =
    }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }

If any have implemented according to the = erroneous example and object to the change, please let the list = know.

Regards,

Phi= l

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



On Oct 21, 2014, at 8:43 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

I agree, the PATCH operation is = not consistent.

We shall need to put some clarifying text that = the outer path applies to selection of the resource (in place of URL) = and the inner path for the operation applies to attribute/value = selection.

The rule of thumb should be that the JSON blob within = the =93data=94 attribute should match the body payload of any other SCIM = HTTP = request?  Correct?

Phil

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



On Oct 21, 2014, at 6:11 AM, Erik = Wahlstr=F6m, neXus <erik.wahlstrom@nexusgroup.com> = wrote:

Yes. Looks like it=92s a typo in = the spec. Should be a standard PATCH call within the data = attribute.
/ Erik

On 21 Oct 2014, at 04:53, ueda@exgen.co.jp = wrote:

Hello

In section = 3.5.3(page 52) of api document,
PATCH method is written as = follows.

"method": "PATCH",
"path": = "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"version": = "W/\"edac3253e2c0ef2\"",
"data": {[
  {
    =   "op": "remove",
      "path": = "nickName"
  },

Questions.

1."schemas" attrribute = is not need in "data"?
2."Operations" attribute is not need in = "data"?

as follows.

"method": "PATCH",
"path": = "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"version": = "W/\"edac3253e2c0ef2\"",
"data": {
  "schemas": = ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  = "Operations": [
    {
        "op": = "remove",
        "path": "nickName"
  =   },

-
Takanori = Ueda.

_______________________________________________
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


= --Apple-Mail=_B511AF95-B098-4B4E-BF4C-8EF45ECB58F5-- From nobody Tue Oct 21 11:23: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 20B461A6EF2 for ; Tue, 21 Oct 2014 11:23:00 -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 izzmCn5mT6F6 for ; Tue, 21 Oct 2014 11:22:56 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848681A1BC7 for ; Tue, 21 Oct 2014 11:22:55 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so2642716wib.14 for ; Tue, 21 Oct 2014 11:22:54 -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=GX+I/325HFYXajnGSnLYITTmahqvJXweXC3y/CRcJ1o=; b=K4gAsxzj+FoMuDQZmrUbLladi/T0nmtz7kJOT0d/IE8g4w9Fl+GVhu9iSgol7+YK8y 2a2WGdMjpQm84BtUtZ7jV3WxNJBAG3Jaf7npalTpR4/2ksczcloVTIPue3zANiDT4P1m HcvAEBHXytZKz0nPCjnZrBn1Cd8ElKgtB1hWBW15Bu9wMZfQ5/oB3A5IqWoJFSz/IzQk j8xA9gqeouBqRpHuxhLLLxI5VuUlhl2oJMk194EchhjmNr3ajzs7wxdBshqwkMaj+8tD kso5QlLuT4GG80zdwtAZcGk9w6e086wd4fRMEn5anpuuh4KuWnVVwEVlqCajG/2Vz28/ eIzQ== X-Gm-Message-State: ALoCoQkqGoqtUbTEetcgSjA/0ZB+zCKGfEyH3unlyycnXCSCK1bZ+vf3kkafHnL9tmB2FDKJf0mW X-Received: by 10.180.205.162 with SMTP id lh2mr31103835wic.14.1413915773865; Tue, 21 Oct 2014 11:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.147.138 with HTTP; Tue, 21 Oct 2014 11:22:31 -0700 (PDT) In-Reply-To: <2508B747-F882-4205-8D99-E1E40307E790@oracle.com> References: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com> From: Ian Glazer Date: Tue, 21 Oct 2014 14:22:31 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c37d2871ccf30505f2eb83 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Da9GgPRohnnk6ZqMnqDhvED9SIk Cc: =?UTF-8?Q?Erik_Wahlstr=C3=B6m=2C_neXus?= , "ueda@exgen.co.jp" , "scim@ietf.org" Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 18:23:00 -0000 --001a11c37d2871ccf30505f2eb83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do we need the schemas element in the Operations section? On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt wrote: > Looking this over, it looks like the example is erroneous: > > =E2=80=A6 > > * { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {[ > { > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ]} > * =E2=80=A6 > > > It should be changed to (full example included): > > POST /v2/Bulk > Host: example.com > Accept: application/scim+json > Content-Type: application/scim+json > Authorization: Bearer h480djs93hd8 > Content-Length: ... > > { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"], > "failOnErrors":1, > "Operations":[ > { > "method":"POST", > "path":"/Users", > "bulkId":"qwerty", > "data":{ > "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"], > "userName":"Alice" > } > }, > > { > > "method":"PUT", > "path":"/Users/b7c14771-226c-4d05-8860-134711653041", > "version":"W\/\"3694e05e9dff591\"", > "data":{ > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], > "id":"b7c14771-226c-4d05-8860-134711653041", > "userName":"Bob" > } > },* { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {* > > * "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > "Operations": [ > {* > > * =E2=80=9Cschemas=E2=80=9D:[" > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ]* > > * } > },* > { > "method":"DELETE", > "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", > "version":"W\/\"0ee8add0a938e1a\"" > } > ] > } > > > If any have implemented according to the erroneous example and object to > the change, please let the list know. > > Regards, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 21, 2014, at 8:43 AM, Phil Hunt wrote: > > I agree, the PATCH operation is not consistent. > > We shall need to put some clarifying text that the outer path applies to > selection of the resource (in place of URL) and the inner path for the > operation applies to attribute/value selection. > > The rule of thumb should be that the JSON blob within the =E2=80=9Cdata= =E2=80=9D attribute > should match the body payload of any other SCIM HTTP request? Correct? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=C3=B6m, neXus < > erik.wahlstrom@nexusgroup.com> wrote: > > Yes. Looks like it=E2=80=99s a typo in the spec. Should be a standard PAT= CH call > within the data attribute. > / Erik > > On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote: > > Hello > > In section 3.5.3(page 52) of api document, > PATCH method is written as follows. > > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {[ > { > "op": "remove", > "path": "nickName" > }, > > Questions. > > 1."schemas" attrribute is not need in "data"? > 2."Operations" attribute is not need in "data"? > > as follows. > > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > "Operations": [ > { > "op": "remove", > "path": "nickName" > }, > > - > Takanori Ueda. > > _______________________________________________ > 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 > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a11c37d2871ccf30505f2eb83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do we need the schemas element in the Operations section?<= /div>

On Tue, Oct = 21, 2014 at 2:17 PM, Phil Hunt <phil.hunt@oracle.com> wro= te:
L= ooking this over, it looks like the example is erroneous:
       =E2=80=A6 
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb=
6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       =E2=80=A6

It should be changed to (full example inc= luded):

   POST /v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:Bulk=
Request"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.=
0:User"],
           "userName":"Alice"
         }
       },
       {

       =
  "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041=
",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.=
0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffc=
c",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           "schemas": [&qu=
ot;urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {
         =
         =E2=80=9Cschemas=E2=80=9D:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b=
",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }

If any have implemented according to the erroneou= s example and object to the change, please let the list know.
Regards,


On = Oct 21, 2014, at 8:43 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I agree, the PATCH operation is not consistent.

We = shall need to put some clarifying text that the outer path applies to selec= tion of the resource (in place of URL) and the inner path for the operation= =C2=A0applies to attribute/value selection.

The rule of thumb should= be that the JSON blob within the =E2=80=9Cdata=E2=80=9D attribute should m= atch the body payload of any other SCIM HTTP request?=C2=A0=C2=A0Correct?
Phil

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



On = Oct 21, 2014, at 6:11 AM, Erik Wahlstr=C3=B6m, neXus <erik.wahlstrom@nexusgroup.= com> wrote:

Yes. Looks like it=E2= =80=99s a typo in the spec. Should be a standard PATCH call within the data= attribute.
/ Erik

On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote:

Hello

In section 3.5.3(page 52) of api document,=
PATCH method is written as follows.

"method": "PA= TCH",
"path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb67= 63ffcc",
"version": "W/\"edac3253e2c0ef2\"= ",
"data": {[
=C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "o= p": "remove",
=C2=A0 =C2=A0 =C2=A0 "path": &quo= t;nickName"
=C2=A0 },

Questions.

1."schemas"= ; attrribute is not need in "data"?
2."Operations" a= ttribute is not need in "data"?

as follows.

"m= ethod": "PATCH",
"path": "/Users/5d8d29d3-= 342c-4b5f-8683-a3cb6763ffcc",
"version": "W/\"e= dac3253e2c0ef2\"",
"data": {
=C2=A0 "schemas= ": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
=C2= =A0 "Operations": [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 "op": "remove",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;path": "nickName"
=C2=A0 =C2=A0 },

-
Takan= ori Ueda.

_______________________________________________
scim ma= iling 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
ht= tps://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
= +1 202 255 3166
--001a11c37d2871ccf30505f2eb83-- From nobody Tue Oct 21 11:32: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 1F9F21A8747 for ; Tue, 21 Oct 2014 11:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlH-lD9Uqfnc for ; Tue, 21 Oct 2014 11:32:29 -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 673061A8750 for ; Tue, 21 Oct 2014 11:32:21 -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 s9LIWF7Y014118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Oct 2014 18:32:16 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 s9LIWDJt016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 18:32:14 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9LIWDPD013511; Tue, 21 Oct 2014 18:32:13 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 11:32:12 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_15A97565-2CC8-4C52-A0A4-FF87CFF85200" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Tue, 21 Oct 2014 11:32:10 -0700 Message-Id: <7FCA8F00-D4A9-44A3-866B-1C8AAC8C861C@oracle.com> References: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com> To: Ian Glazer 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/ps4KjsEDrssyF1etJ3fSj0ps7Gc Cc: =?iso-8859-1?Q?=22Erik_Wahlstr=F6m=2C_neXus=22?= , "ueda@exgen.co.jp" , "scim@ietf.org" Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 18:32:32 -0000 --Apple-Mail=_15A97565-2CC8-4C52-A0A4-FF87CFF85200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes. That would be consistent with the normal patch operation. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 21, 2014, at 11:22 AM, Ian Glazer wrote: > Do we need the schemas element in the Operations section? >=20 > On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt = wrote: > Looking this over, it looks like the example is erroneous: > =85=20 > { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {[ > { > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ]} > =85 >=20 > It should be changed to (full example included): >=20 > POST /v2/Bulk > Host: example.com > Accept: application/scim+json > Content-Type: application/scim+json > Authorization: Bearer h480djs93hd8 > Content-Length: ... >=20 > { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"], > "failOnErrors":1, > "Operations":[ > { > "method":"POST", > "path":"/Users", > "bulkId":"qwerty", > "data":{ > "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"], > "userName":"Alice" > } > }, > { > "method":"PUT", > "path":"/Users/b7c14771-226c-4d05-8860-134711653041", > "version":"W\/\"3694e05e9dff591\"", > "data":{ > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], > "id":"b7c14771-226c-4d05-8860-134711653041", > "userName":"Bob" > } > }, > { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": { > "schemas": = ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > "Operations": [ > { > =93schemas=94:[" > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ] > } > }, > { > "method":"DELETE", > "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", > "version":"W\/\"0ee8add0a938e1a\"" > } > ] > } >=20 > If any have implemented according to the erroneous example and object = to the change, please let the list know. >=20 > Regards, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 21, 2014, at 8:43 AM, Phil Hunt wrote: >=20 >> I agree, the PATCH operation is not consistent. >>=20 >> We shall need to put some clarifying text that the outer path applies = to selection of the resource (in place of URL) and the inner path for = the operation applies to attribute/value selection. >>=20 >> The rule of thumb should be that the JSON blob within the =93data=94 = attribute should match the body payload of any other SCIM HTTP request? = Correct? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus = wrote: >>=20 >>> Yes. Looks like it=92s a typo in the spec. Should be a standard = PATCH call within the data attribute. >>> / Erik >>>=20 >>> On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote: >>>=20 >>>> Hello >>>>=20 >>>> In section 3.5.3(page 52) of api document, >>>> PATCH method is written as follows. >>>>=20 >>>> "method": "PATCH", >>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>>> "version": "W/\"edac3253e2c0ef2\"", >>>> "data": {[ >>>> { >>>> "op": "remove", >>>> "path": "nickName" >>>> }, >>>>=20 >>>> Questions. >>>>=20 >>>> 1."schemas" attrribute is not need in "data"? >>>> 2."Operations" attribute is not need in "data"? >>>>=20 >>>> as follows. >>>>=20 >>>> "method": "PATCH", >>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>>> "version": "W/\"edac3253e2c0ef2\"", >>>> "data": { >>>> "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], >>>> "Operations": [ >>>> { >>>> "op": "remove", >>>> "path": "nickName" >>>> }, >>>>=20 >>>> - >>>> Takanori Ueda. >>>>=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 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer --Apple-Mail=_15A97565-2CC8-4C52-A0A4-FF87CFF85200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes. =  That would be consistent with the normal patch = operation.


On Oct 21, 2014, at 11:22 AM, Ian Glazer <iglazer@salesforce.com> = wrote:

Do we need the schemas element in the = Operations section?

On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Looking this over, it looks like the = example is erroneous:
       =85 =

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       =85

<= div>It should be changed to (full example = included):

   POST =
/v2/Bulk
   Host: example.com=

   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },
       {

     =
    "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           =
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               =
{
             =
     =93schemas=94:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }

If any have implemented according to the = erroneous example and object to the change, please let the list = know.

Regards,


On Oct 21, 2014, at 8:43 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I agree, the PATCH operation is not consistent.

We = shall need to put some clarifying text that the outer path applies to = selection of the resource (in place of URL) and the inner path for the = operation applies to attribute/value selection.

The rule of = thumb should be that the JSON blob within the =93data=94 attribute = should match the body payload of any other SCIM HTTP = request?  Correct?

Phil

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



On Oct 21, = 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus <erik.wahlstrom@nexusgroup.com> = wrote:

Yes. Looks like it=92s a typo in = the spec. Should be a standard PATCH call within the data = attribute.
/ Erik

On 21 Oct 2014, at 04:53, ueda@exgen.co.jp = wrote:

Hello

In section = 3.5.3(page 52) of api document,
PATCH method is written as = follows.

"method": "PATCH",
"path": = "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"version": = "W/\"edac3253e2c0ef2\"",
"data": {[
  {
    =   "op": "remove",
      "path": = "nickName"
  },

Questions.

1."schemas" attrribute = is not need in "data"?
2."Operations" attribute is not need in = "data"?

as follows.

"method": "PATCH",
"path": = "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
"version": = "W/\"edac3253e2c0ef2\"",
"data": {
  "schemas": = ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  = "Operations": [
    {
        "op": = "remove",
        "path": "nickName"
  =   },

-
Takanori = Ueda.

_______________________________________________
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




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

= --Apple-Mail=_15A97565-2CC8-4C52-A0A4-FF87CFF85200-- From nobody Tue Oct 21 12:36:36 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 B65581A1B38 for ; Tue, 21 Oct 2014 12:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 v75WzK9MEB67 for ; Tue, 21 Oct 2014 12:36:31 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91441A1AF8 for ; Tue, 21 Oct 2014 12:36:28 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so123311igb.3 for ; Tue, 21 Oct 2014 12:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e5QBChqi+APeXOW9eCTjwATs15G7vl0lVZCOfP+AkOQ=; b=Qt/hH316pLaQDT0F5uYUtHXBQaZIhWZWf87sfRpWvk1h6RB1e6JsOK5rDFgnsgn1cf xmV1Oqus76O5y2Z+MPUbANmrs/zQoRwUAN9OrwdUms7x5WPvu73GWnpwtFl3RtM+LE3s duPfTyPmzhuOV0Dt8dM3qe4/KfWEkH3T63PZZvE1ZqMFydxbXOxd0fWXtoDl709ud9Au WVYy1NuhjM0RY6S0fi6cdv9YrYAf8UWMMnzAQFyaxI520uf/E9H/y1teqL8s3De5o/Th XWStGfGPFKl5svxFrIUsdB1/2bng0VaABf55hfQBl0l35A3MIKI0f9Ep3yg6FvIzisnU CAqA== MIME-Version: 1.0 X-Received: by 10.50.143.65 with SMTP id sc1mr29807048igb.27.1413920188145; Tue, 21 Oct 2014 12:36:28 -0700 (PDT) Received: by 10.64.120.225 with HTTP; Tue, 21 Oct 2014 12:36:28 -0700 (PDT) Date: Tue, 21 Oct 2014 14:36:28 -0500 Message-ID: From: Shelley To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=001a1135fdaa8e27e70505f3f276 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/5e00VENWyPhsa560EmhCz4H5ESU Subject: [scim] SCIM Attribute Validation 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, 21 Oct 2014 19:36:34 -0000 --001a1135fdaa8e27e70505f3f276 Content-Type: text/plain; charset=UTF-8 The SCIM specification expects service providers should be able to canonicalize provided data into a common format (e.g. RFC 3966 for phoneNumbers), yet it does not explicitly describe input requirements or validation for attributes such as these.* Is it expected that values that cannot accurately be canonicalized are rejected by the SCIM service or that the SCIM service accepts this invalid data and merely persists and returns this bad data to consumers?* As a SCIM Service Provider, we are currently performing validation on attributes such as phoneNumbers and emails to ensure that they contain well-formed, valid values, and returning a 400 with a description of the error if validation fails. One of the benefits of SCIM is that data may come from multiple sources and may be consumed by multiple clients, and SCIM provides a repository of structured and well-formed data so that consumers can reliably derive meaning and use from this data. Without attribute validation and a guarantee of canonicalized values, this goal does not seem feasible and puts the burden on consumers to make sense of potentially invalid data. The downside to attribute validation is that it requires the SCIM consumers sending data to ensure valid data as well. As these consumers are closest to the source data, though, this seems like the most reasonable approach rather than putting the burden on the service provider and/or other SCIM consumers to make sense of the data. Aside from just "bad data" (e.g. sending "not a phone number" or "000-0000" for a phone number), for example, if the SCIM consumer sending source data sends phone numbers without area codes or sends only internal extensions, another SCIM consumer may not be able to make sense of this data. It seems reasonable to require the consumer sending the data to ensure that this data is well-formed and canonicalized/canonicalizable. A *good *example in the SCIM specification is the country attribute, which clearly indicates the attribute's requirements. A *bad *example is the phoneNumbers attribute, which doesn't describe the expected format to be provided by consumers, yet recommends that the service provider canonicalize the value even though the input may not be able to be canonicalized. I'd be interested in hearing others' opinions on this matter, and whether the SCIM specification should clarify further restrictions on attribute values. --001a1135fdaa8e27e70505f3f276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The SCIM specification expects service providers shou= ld be able to canonicalize provided data into a common format (e.g. RFC 396= 6 for phoneNumbers= ), yet it does not explicitly describe input requirements or validation for= attributes such as these. Is it expected that values that cannot accura= tely be canonicalized are rejected by the SCIM service or that the SCIM ser= vice accepts this invalid data and merely persists and returns this bad dat= a to consumers?

As a SCIM Service Provider, we are currently per= forming validation on attributes such as phoneNumbers and emails to ensure that they contain well-formed, valid= values, and returning a 400 with a description of the error if validation = fails. One of the benefits of SCIM is that data may come from multiple sour= ces and may be consumed by multiple clients, and SCIM provides a repository= of structured and well-formed data so that consumers can reliably derive m= eaning and use from this data. Without attribute validation and a guarantee= of canonicalized values, this goal does not seem feasible and puts the bur= den on consumers to make sense of potentially invalid data.

The down= side to attribute validation is that it requires the SCIM consumers sending= data to ensure valid data as well. As these consumers are closest to the s= ource data, though, this seems like the most reasonable approach rather tha= n putting the burden on the service provider and/or other SCIM consumers to= make sense of the data. Aside from just "bad data" (e.g. sending= "not a phone number" or "000-0000" for a phone number)= , for example, if the SCIM consumer sending source data sends phone numbers= without area codes or sends only internal extensions, another SCIM consume= r may not be able to make sense of this data. It seems reasonable to requir= e the consumer sending the data to ensure that this data is well-formed and= canonicalized/canonicalizable.

A good example in the SCIM sp= ecification is the countr= y attribute, which clearly indicates the attribute's requirement= s. A bad example is the phoneNumbers attribute, which doesn't describe the expecte= d format to be provided by consumers, yet recommends that the service provi= der canonicalize the value even though the input may not be able to be cano= nicalized.

I'd be interested in hearing others' opinio= ns on this matter, and whether the SCIM specification should clarify furthe= r restrictions on attribute values.
--001a1135fdaa8e27e70505f3f276-- From nobody Tue Oct 21 12:39: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 4AF301A1BA5 for ; Tue, 21 Oct 2014 12:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U00vThYNjiIE for ; Tue, 21 Oct 2014 12:39:24 -0700 (PDT) Received: from appa.redston.com (mail2.redston.com [212.159.105.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9322A1A1B95 for ; Tue, 21 Oct 2014 12:39:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by appa.redston.com (Postfix) with ESMTP id 87EC951FA9 for ; Tue, 21 Oct 2014 20:39:22 +0100 (BST) X-Virus-Scanned: amavisd-new at redston.com Received: from appa.redston.com ([127.0.0.1]) by localhost (appa.redston.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBE48uMdPpgk for ; Tue, 21 Oct 2014 20:39:18 +0100 (BST) Received: from [127.0.0.1] (unknown [81.171.222.102]) by appa.redston.com (Postfix) with ESMTPSA id 1AEA551FA1 for ; Tue, 21 Oct 2014 20:39:18 +0100 (BST) Message-ID: <5446B663.6030104@switchresearch.com> Date: Tue, 21 Oct 2014 20:39:15 +0100 From: Alex Redston User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080201080905090009090706" X-Antivirus: avast! (VPS 141021-0, 21/10/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/scim/L8aQr3IGncNT0__JtHMH-IQ-k4M Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 19:39:29 -0000 This is a multi-part message in MIME format. --------------080201080905090009090706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Contributors I've been away from the list for a few months so the changes seem to be fairly dramatic, a bit like seeing a child for the first time in 6 months. Please don't be offended as this is a casual observation and is not meant in any derogatory way. I understand the reason for adding schema fields, it seems that the spec is becoming more verbose and I will be interested to see how many of the larger vendors who are not part of the core SCIM contributors go on to implement the v2 spec. I know the S in SCIM no longer stands for simple and the spec is more complete, robust, deterministic and flexible now but the syntax is becoming more verbose, as it does I can't help but think it would be cleaner if XML were restored to the spec. The trouble with specifications is that adoption rate often trumps quality. For me - I'm looking forward to implementing the new specification, in its current form which we will start work on shortly. Alex On 21/10/2014 19:22, Ian Glazer wrote: > Do we need the schemas element in the Operations section? > > On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt > wrote: > > Looking this over, it looks like the example is erroneous: > > ... > > * { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {[ > { > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ]} > * ... > > It should be changed to (full example included): > > POST /v2/Bulk > Host:example.com > Accept: application/scim+json > Content-Type: application/scim+json > Authorization: Bearer h480djs93hd8 > Content-Length: ... > > { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"], > "failOnErrors":1, > "Operations":[ > { > "method":"POST", > "path":"/Users", > "bulkId":"qwerty", > "data":{ > "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"], > "userName":"Alice" > } > }, > > { > > "method":"PUT", > "path":"/Users/b7c14771-226c-4d05-8860-134711653041", > "version":"W\/\"3694e05e9dff591\"", > "data":{ > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], > "id":"b7c14771-226c-4d05-8860-134711653041", > "userName":"Bob" > } > }, > * { > "method": "PATCH", > "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", > "version": "W/\"edac3253e2c0ef2\"", > "data": {* > > * "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], > "Operations": [ > {* > > * "schemas":[" > "op": "remove", > "path": "nickName" > }, > { > "op": "add", > "path": "userName", > "value": "Dave" > } > ]* > > * } > },* > { > "method":"DELETE", > "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b", > "version":"W\/\"0ee8add0a938e1a\"" > } > ] > } > > > If any have implemented according to the erroneous example and > object to the change, please let the list know. > > Regards, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 21, 2014, at 8:43 AM, Phil Hunt > wrote: > >> I agree, the PATCH operation is not consistent. >> >> We shall need to put some clarifying text that the outer path >> applies to selection of the resource (in place of URL) and the >> inner path for the operation applies to attribute/value selection. >> >> The rule of thumb should be that the JSON blob within the "data" >> attribute should match the body payload of any other SCIM HTTP >> request? Correct? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 21, 2014, at 6:11 AM, Erik Wahlström, neXus >> > > wrote: >> >>> Yes. Looks like it's a typo in the spec. Should be a standard >>> PATCH call within the data attribute. >>> / Erik >>> >>> On 21 Oct 2014, at 04:53, ueda@exgen.co.jp >>> wrote: >>> >>>> Hello >>>> >>>> In section 3.5.3(page 52) of api document, >>>> PATCH method is written as follows. >>>> >>>> "method": "PATCH", >>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>>> "version": "W/\"edac3253e2c0ef2\"", >>>> "data": {[ >>>> { >>>> "op": "remove", >>>> "path": "nickName" >>>> }, >>>> >>>> Questions. >>>> >>>> 1."schemas" attrribute is not need in "data"? >>>> 2."Operations" attribute is not need in "data"? >>>> >>>> as follows. >>>> >>>> "method": "PATCH", >>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc", >>>> "version": "W/\"edac3253e2c0ef2\"", >>>> "data": { >>>> "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], >>>> "Operations": [ >>>> { >>>> "op": "remove", >>>> "path": "nickName" >>>> }, >>>> >>>> - >>>> Takanori Ueda. >>>> >>>> _______________________________________________ >>>> 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 > > > > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --------------080201080905090009090706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Contributors

I've been away from the list for a few months so the changes seem to be fairly dramatic, a bit like seeing a child for the first time in 6 months.

Please don't be offended as this is a casual observation and is not meant in any derogatory way.

I understand the reason for adding schema fields, it seems that the spec is becoming more verbose and I will be interested to see how many of the larger vendors who are not part of the core SCIM contributors go on to implement the v2 spec.

I know the S in SCIM no longer stands for simple and the spec is more complete, robust, deterministic and flexible now but the syntax is becoming more verbose, as it does I can't help but think it would be cleaner if XML were restored to the spec.

The trouble with specifications is that adoption rate often trumps quality.

For me - I'm looking forward to implementing the new specification, in its current form which we will start work on shortly.
Alex
On 21/10/2014 19:22, Ian Glazer wrote:
Do we need the schemas element in the Operations section?

On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Looking this over, it looks like the example is erroneous: 
       … 
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       …

                
It should be changed to (full example included):

                


                

                

                  
   POST /v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },

                  
       {


                  
         "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {

                  
                    
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {

                  
                  
                  “schemas”:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]

                  
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }


                  


                  

                  
If any have implemented according to the
                    erroneous example and object to the change, please
                    let the list know.

                  


                  

                  
Regards,

                  


                  

                

                
                

                  


                    On Oct 21, 2014, at 8:43 AM, Phil Hunt <phil.hunt@oracle.com>
                    wrote:

                    

                    
I agree, the PATCH operation
                      is not consistent.

                      

                      We shall need to put some clarifying text that the
                      outer path applies to selection of the resource
                      (in place of URL) and the inner path for the
                      operation applies to attribute/value selection.

                      

                      The rule of thumb should be that the JSON blob
                      within the “data” attribute should match the body
                      payload of any other SCIM HTTP request?  Correct?

                      

                      Phil

                      

                      @independentid

                      www.independentid.com

                      phil.hunt@oracle.com

                      

                      

                      

                      On Oct 21, 2014, at 6:11 AM, Erik Wahlström, neXus
                      <erik.wahlstrom@nexusgroup.com>
                      wrote:

                      

                      
Yes. Looks like it’s a
                        typo in the spec. Should be a standard PATCH
                        call within the data attribute.

                        / Erik

                        

                        On 21 Oct 2014, at 04:53, ueda@exgen.co.jp
                        wrote:

                        

                        
Hello

                          

                          In section 3.5.3(page 52) of api document,

                          PATCH method is written as follows.

                          

                          "method": "PATCH",

                          "path":
                          "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                          "version": "W/\"edac3253e2c0ef2\"",

                          "data": {[

                            {

                                "op": "remove",

                                "path": "nickName"

                            },

                          

                          Questions.

                          

                          1."schemas" attrribute is not need in "data"?

                          2."Operations" attribute is not need in
                          "data"?

                          

                          as follows.

                          

                          "method": "PATCH",

                          "path":
                          "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                          "version": "W/\"edac3253e2c0ef2\"",

                          "data": {

                            "schemas":
                          ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],

                            "Operations": [

                              {

                                  "op": "remove",

                                  "path": "nickName"

                              },

                          

                          -

                          Takanori Ueda.

                          

_______________________________________________

                          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

            

          

        

        

        

        


        

        -- 

        

          
Ian Glazer

          

          
Senior Director, Identity

          
+1 202 255 3166

          
        

      

    

    

  







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	








--------------080201080905090009090706--


From nobody Tue Oct 21 12:46: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 DF1E81A1C04 for ; Tue, 21 Oct 2014 12:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 9l55KbUZrHIH for ; Tue, 21 Oct 2014 12:45:57 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA491A1BE4 for ; Tue, 21 Oct 2014 12:45:57 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id rp18so1910781iec.7 for ; Tue, 21 Oct 2014 12:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YjHAibgk9zipMDl7wRJ1XgUhB7qldtH5addS5rmfGzg=; b=YbJVu8fxsZKokV6dNITJC66WBFobMreWyn1Tk638B5CzREQZ7bMLgRLayCSW0WI5Up 4eiGnfyy0R1VTwjyTefTom5DgiZPTbZ1cXcNYOgcjssQf61uCrlYDpaRDbEiDW8qG5nJ 3QXAEDmAUbIQoDh7TjPmsdleHijG8kA/GRsQXM6cqXKZcr2JjxT3ngXQt8JuSi3arxNi A8wqx/iFI4ltF6T0IgC/SDmbVgDFD3dUQlgBnaS5JhySYNZDU5fO8DdaSBaS3AY9R4e0 oI6nqtWg44cYn4rg5ZgrPRG6J10b+Z+oU955aMJ5s/+0UfzdXLYeT4+vb5MbifJaMWy8 5DkQ==
MIME-Version: 1.0
X-Received: by 10.107.37.15 with SMTP id l15mr40376920iol.40.1413920756878; Tue, 21 Oct 2014 12:45:56 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Tue, 21 Oct 2014 12:45:56 -0700 (PDT)
In-Reply-To: 
References: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu> 
Date: Tue, 21 Oct 2014 14:45:56 -0500
Message-ID: 
From: Shelley 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a11402fbc7453920505f4141f
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/GfZ0_7Ror_WhoeNukdp4rAhIKZ4
Cc: "scim@ietf.org" , Steve Moyer 
Subject: Re: [scim] address.display versus address.formatted
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, 21 Oct 2014 19:46:00 -0000

--001a11402fbc7453920505f4141f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Our implementation does the same thing, such that we ignore the address "
display" sub-attribute. Likewise, we do not support the "display" attribute
for several other multi-valued attributes since it seems to provide no
additional value beyond the "value" attribute:

   - addresses
   - emails
   - phoneNumbers
   - photos
   - roles

(We also currently ignore the ims, entitlements, and x509Certificates
attributes completely since we have no use cases for these, but would
likely ignore the "display" attribute for these attributes as well should
we add support for these attributes.)

On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt  wrote:

> +1
>
> Thanks Steve.  Curious to hear what others have implemented too.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> On Oct 21, 2014, at 8:53 AM, Steve Moyer  wrote:
>
> > Are the address.display attribute (inherited from SCIM Multi-Valued
> Attribute) and the address.formatted attribute (part of the address
> definition) ambiguous?  Can anyone provide insight into how they're being
> used?  Our current implementation sets address.formatted and ignores
> address.display but I'm curious to know how others are populating these
> fields.
> >
> > Thanks,
> >
> > Steve
> >
> > --
> >
> > =E2=80=9CThe 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.=
=E2=80=9D
> - Wilhelm Stekel
> >
> > _______________________________________________
> > 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
>

--001a11402fbc7453920505f4141f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Our implementation does the same thing, such that we ignor=
e the address "displ=
ay" sub-attribute. Likewise, we do not support the "display" attribute =
for several other multi-valued attributes since it seems to provide no addi=
tional value beyond the "value" attribute:
  • addresses
  • emails
  • phoneNumbers
  • photos
  • roles
(We also currently ignore the ims, entitlements, and x509Certificates attributes completely since =
we have no use cases for these, but would likely ignore the "display" attribute for=
 these attributes as well should we add support for these attributes.)

On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
+1



Thanks Steve.=C2=A0 Curious to hear what others have implemented too.



Phil



@independentid

www.independenti=
d.com

phil.hunt@oracle.com








On Oct 21, 2014, at 8:53 AM, Steve Moyer <smoyer@psu.edu> wrote:



> Are the address.display attribute (inherited from SCIM Multi-Valued At=
tribute) and the address.formatted attribute (part of the address definitio=
n) ambiguous?=C2=A0 Can anyone provide insight into how they're being u=
sed?=C2=A0 Our current implementation sets address.formatted and ignores ad=
dress.display but I'm curious to know how others are populating these f=
ields.

>

> Thanks,

>

> Steve

>

> --

>

> =E2=80=9CThe mark of the immature man is that he wants to die nobly fo=
r a cause, while the mark of the mature man is that he wants to live humbly=
 for one.=E2=80=9D - Wilhelm Stekel

>

> _______________________________________________

> 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





--001a11402fbc7453920505f4141f--


From nobody Tue Oct 21 12:54: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 8FD321A1AC8 for ; Tue, 21 Oct 2014 12:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.811
X-Spam-Level: 
X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwyz2L4z4N3I for ; Tue, 21 Oct 2014 12:54:03 -0700 (PDT)
Received: from appa.redston.com (mail2.redston.com [212.159.105.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9C271A1AA0 for ; Tue, 21 Oct 2014 12:54:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by appa.redston.com (Postfix) with ESMTP id 28E2251FBC; Tue, 21 Oct 2014 20:54:02 +0100 (BST)
X-Virus-Scanned: amavisd-new at redston.com
Received: from appa.redston.com ([127.0.0.1]) by localhost (appa.redston.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFf4xOi8ZTtT; Tue, 21 Oct 2014 20:53:57 +0100 (BST)
Received: from [127.0.0.1] (unknown [81.171.222.102]) by appa.redston.com (Postfix) with ESMTPSA id DE6B251F37; Tue, 21 Oct 2014 20:53:56 +0100 (BST)
Message-ID: <5446B9D2.8040005@switchresearch.com>
Date: Tue, 21 Oct 2014 20:53:54 +0100
From: Alex Redston 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Shelley , "scim@ietf.org" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080708090801020900000809"
X-Antivirus: avast! (VPS 141021-0, 21/10/2014), Outbound message
X-Antivirus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/xAoQr1Zxfs5amfsX_Bs4wbl14p8
Subject: Re: [scim] SCIM Attribute Validation
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, 21 Oct 2014 19:54:05 -0000

This is a multi-part message in MIME format.
--------------080708090801020900000809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Of course the challenge here comes down to the extent to which that 
particular data can be standardised and validated. Taking phone numbers 
as the example you have sip calls, invalid numbers, country specific 
shortcodes, this is potentially a minefield.

Well formed and valid values are two distinct concepts and with multiple 
carrier technologies the anatomy of simple +4412345678901 style numbers 
is no longer fit for purpose. For this reason I do not think that it is 
feasible for this particular data type to be rejected as bad data 
because the only way to know if a phone number is valid is to dial it.

What do you think?

Alex

Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

On 21/10/2014 20:36, Shelley wrote:
> The SCIM specification expects service providers should be able to 
> canonicalize provided data into a common format (e.g. RFC 3966 for 
> phoneNumbers), yet it does not explicitly describe input requirements 
> or validation for attributes such as these.*Is it expected that values 
> that cannot accurately be canonicalized are rejected by the SCIM 
> service or that the SCIM service accepts this invalid data and merely 
> persists and returns this bad data to consumers?*
>
> As a SCIM Service Provider, we are currently performing validation on 
> attributes such as phoneNumbers and emails to ensure that they contain 
> well-formed, valid values, and returning a 400 with a description of 
> the error if validation fails. One of the benefits of SCIM is that 
> data may come from multiple sources and may be consumed by multiple 
> clients, and SCIM provides a repository of structured and well-formed 
> data so that consumers can reliably derive meaning and use from this 
> data. Without attribute validation and a guarantee of canonicalized 
> values, this goal does not seem feasible and puts the burden on 
> consumers to make sense of potentially invalid data.
>
> The downside to attribute validation is that it requires the SCIM 
> consumers sending data to ensure valid data as well. As these 
> consumers are closest to the source data, though, this seems like the 
> most reasonable approach rather than putting the burden on the service 
> provider and/or other SCIM consumers to make sense of the data. Aside 
> from just "bad data" (e.g. sending "not a phone number" or "000-0000" 
> for a phone number), for example, if the SCIM consumer sending source 
> data sends phone numbers without area codes or sends only internal 
> extensions, another SCIM consumer may not be able to make sense of 
> this data. It seems reasonable to require the consumer sending the 
> data to ensure that this data is well-formed and 
> canonicalized/canonicalizable.
>
> A /good /example in the SCIM specification is the country attribute, 
> which clearly indicates the attribute's requirements. A /bad /example 
> is the phoneNumbers attribute, which doesn't describe the expected 
> format to be provided by consumers, yet recommends that the service 
> provider canonicalize the value even though the input may not be able 
> to be canonicalized.
>
> I'd be interested in hearing others' opinions on this matter, and 
> whether the SCIM specification should clarify further restrictions on 
> attribute values.



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

--------------080708090801020900000809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Of course the challenge here comes down
      to the extent to which that particular data can be standardised
      and validated. Taking phone numbers as the example you have sip
      calls, invalid numbers, country specific shortcodes, this is
      potentially a minefield.

      

      Well formed and valid values are two distinct concepts and with
      multiple carrier technologies the anatomy of simple +4412345678901
      style numbers is no longer fit for purpose. For this reason I do
      not think that it is feasible for this particular data type to be
      rejected as bad data because the only way to know if a phone
      number is valid is to dial it.

      

      What do you think?

      

      Alex

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 21/10/2014 20:36, Shelley wrote:

    

    

      

        
The SCIM specification expects service providers should be
          able to canonicalize provided data into a common format (e.g.
          RFC 3966 for phoneNumbers),
          yet it does not explicitly describe input requirements or
          validation for attributes such as these. Is it expected
            that values that cannot accurately be canonicalized are
            rejected by the SCIM service or that the SCIM service
            accepts this invalid data and merely persists and returns
            this bad data to consumers?

          

          As a SCIM Service Provider, we are currently performing
          validation on attributes such as phoneNumbers and
          emails to
          ensure that they contain well-formed, valid values, and
          returning a 400 with a description of the error if validation
          fails. One of the benefits of SCIM is that data may come from
          multiple sources and may be consumed by multiple clients, and
          SCIM provides a repository of structured and well-formed data
          so that consumers can reliably derive meaning and use from
          this data. Without attribute validation and a guarantee of
          canonicalized values, this goal does not seem feasible and
          puts the burden on consumers to make sense of potentially
          invalid data.

          

          The downside to attribute validation is that it requires the
          SCIM consumers sending data to ensure valid data as well. As
          these consumers are closest to the source data, though, this
          seems like the most reasonable approach rather than putting
          the burden on the service provider and/or other SCIM consumers
          to make sense of the data. Aside from just "bad data" (e.g.
          sending "not a phone number" or "000-0000" for a phone
          number), for example, if the SCIM consumer sending source data
          sends phone numbers without area codes or sends only internal
          extensions, another SCIM consumer may not be able to make
          sense of this data. It seems reasonable to require the
          consumer sending the data to ensure that this data is
          well-formed and canonicalized/canonicalizable.

          

          A good example in the SCIM specification is the country attribute,
          which clearly indicates the attribute's requirements. A bad
          example is the phoneNumbers attribute, which doesn't
          describe the expected format to be provided by consumers, yet
          recommends that the service provider canonicalize the value
          even though the input may not be able to be canonicalized.

          

        

        I'd be interested in hearing others' opinions on this matter,
        and whether the SCIM specification should clarify further
        restrictions on attribute values.

      

    

    

  







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	








--------------080708090801020900000809--


From nobody Tue Oct 21 15:50: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 6A67E1A86E7 for ; Tue, 21 Oct 2014 15:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs4HruTZDhAC for ; Tue, 21 Oct 2014 15:50:01 -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 4A76A1A8799 for ; Tue, 21 Oct 2014 15:50:01 -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 s9LMnxsn031429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Oct 2014 22:50:00 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 s9LMnwrN019754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 22:49:58 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9LMnwVB009875; Tue, 21 Oct 2014 22:49:58 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2014 15:49:57 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_F4EF066A-F0FD-417A-B9FA-5258816967C4"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: <5446B663.6030104@switchresearch.com>
Date: Tue, 21 Oct 2014 15:49:56 -0700
Message-Id: 
References:   <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com>  <5446B663.6030104@switchresearch.com>
To: Alex Redston 
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/onOJvbUMGdF0eycdfb6kQcxdF8I
Cc: scim@ietf.org
Subject: Re: [scim] PATCH method in 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: Tue, 21 Oct 2014 22:50:04 -0000

--Apple-Mail=_F4EF066A-F0FD-417A-B9FA-5258816967C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Alex,

Thanks for your comments.=20

Yes, our baby has been going through a healthy maturation indeed!

Was there anything specific to this issue that you are recommending? =20

Phil

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



On Oct 21, 2014, at 12:39 PM, Alex Redston  =
wrote:

> Contributors
>=20
> I've been away from the list for a few months so the changes seem to =
be fairly dramatic, a bit like seeing a child for the first time in 6 =
months.
>=20
> Please don't be offended as this is a casual observation and is not =
meant in any derogatory way.
>=20
> I understand the reason for adding schema fields, it seems that the =
spec is becoming more verbose and I will be interested to see how many =
of the larger vendors who are not part of the core SCIM contributors go =
on to implement the v2 spec.
>=20
> I know the S in SCIM no longer stands for simple and the spec is more =
complete, robust, deterministic and flexible now but the syntax is =
becoming more verbose, as it does I can't help but think it would be =
cleaner if XML were restored to the spec.
>=20
> The trouble with specifications is that adoption rate often trumps =
quality.
>=20
> For me - I'm looking forward to implementing the new specification, in =
its current form which we will start work on shortly.
> Alex
> On 21/10/2014 19:22, Ian Glazer wrote:
>> Do we need the schemas element in the Operations section?
>>=20
>> On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt  =
wrote:
>> Looking this over, it looks like the example is erroneous:
>>        =85=20
>>        {
>>          "method": "PATCH",
>>          "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>          "version": "W/\"edac3253e2c0ef2\"",
>>          "data": {[
>>            {
>>                "op": "remove",
>>                "path": "nickName"
>>            },
>>            {
>>                "op": "add",
>>                "path": "userName",
>>                "value": "Dave"
>>            }
>>          ]}
>>        =85
>> It should be changed to (full example included):
>>=20
>>    POST /v2/Bulk
>>    Host: example.com
>>    Accept: application/scim+json
>>    Content-Type: application/scim+json
>>    Authorization: Bearer h480djs93hd8
>>    Content-Length: ...
>>=20
>>    {
>>      "schemas": =
["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
>>      "failOnErrors":1,
>>      "Operations":[
>>        {
>>          "method":"POST",
>>          "path":"/Users",
>>          "bulkId":"qwerty",
>>          "data":{
>>            "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
>>            "userName":"Alice"
>>          }
>>        },
>>        {
>>          "method":"PUT",
>>          "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
>>          "version":"W\/\"3694e05e9dff591\"",
>>          "data":{
>>            "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
>>            "id":"b7c14771-226c-4d05-8860-134711653041",
>>            "userName":"Bob"
>>          }
>>        },
>>        {
>>          "method": "PATCH",
>>          "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>          "version": "W/\"edac3253e2c0ef2\"",
>>          "data": {
>>             "schemas": =
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>            "Operations": [
>>                {
>>                    =93schemas=94:["
>>                   "op": "remove",
>>                   "path": "nickName"
>>                },
>>                {
>>                   "op": "add",
>>                   "path": "userName",
>>                   "value": "Dave"
>>                }
>>            ]
>>          }
>>        },
>>        {
>>          "method":"DELETE",
>>          "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
>>          "version":"W\/\"0ee8add0a938e1a\""
>>        }
>>      ]
>>    }
>>=20
>> If any have implemented according to the erroneous example and object =
to the change, please let the list know.
>>=20
>> Regards,
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>> On Oct 21, 2014, at 8:43 AM, Phil Hunt  wrote:
>>=20
>>> I agree, the PATCH operation is not consistent.
>>>=20
>>> We shall need to put some clarifying text that the outer path =
applies to selection of the resource (in place of URL) and the inner =
path for the operation applies to attribute/value selection.
>>>=20
>>> The rule of thumb should be that the JSON blob within the =93data=94 =
attribute should match the body payload of any other SCIM HTTP request?  =
Correct?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>> On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus =
 wrote:
>>>=20
>>>> Yes. Looks like it=92s a typo in the spec. Should be a standard =
PATCH call within the data attribute.
>>>> / Erik
>>>>=20
>>>> On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote:
>>>>=20
>>>>> Hello
>>>>>=20
>>>>> In section 3.5.3(page 52) of api document,
>>>>> PATCH method is written as follows.
>>>>>=20
>>>>> "method": "PATCH",
>>>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>> "version": "W/\"edac3253e2c0ef2\"",
>>>>> "data": {[
>>>>>   {
>>>>>       "op": "remove",
>>>>>       "path": "nickName"
>>>>>   },
>>>>>=20
>>>>> Questions.
>>>>>=20
>>>>> 1."schemas" attrribute is not need in "data"?
>>>>> 2."Operations" attribute is not need in "data"?
>>>>>=20
>>>>> as follows.
>>>>>=20
>>>>> "method": "PATCH",
>>>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>> "version": "W/\"edac3253e2c0ef2\"",
>>>>> "data": {
>>>>>   "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>>>   "Operations": [
>>>>>     {
>>>>>         "op": "remove",
>>>>>         "path": "nickName"
>>>>>     },
>>>>>=20
>>>>> -
>>>>> Takanori Ueda.
>>>>>=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
>>=20
>>=20
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Ian Glazer
>> Senior Director, Identity
>> +1 202 255 3166
>> @iglazer
>=20
>=20
>=20
>  =09
> This email is free from viruses and malware because avast! Antivirus =
protection is active. 		=09
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_F4EF066A-F0FD-417A-B9FA-5258816967C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Alex,

Thanks for your =
comments. 

Yes, our baby has been going =
through a healthy maturation indeed!

Was there =
anything specific to this issue that you are recommending? =
 

Phil


On Oct 21, 2014, at 12:39 PM, Alex Redston <aredston@switchresearch.com> wrote:


 =20
    
 =20
  

    
Contributors

      

      I've been away from the list for a few months so the changes seem
      to be fairly dramatic, a bit like seeing a child for the first
      time in 6 months.

      

      Please don't be offended as this is a casual observation and is
      not meant in any derogatory way.

      

      I understand the reason for adding schema fields, it seems that
      the spec is becoming more verbose and I will be interested to see
      how many of the larger vendors who are not part of the core SCIM
      contributors go on to implement the v2 spec.

      

      I know the S in SCIM no longer stands for simple and the spec is
      more complete, robust, deterministic and flexible now but the
      syntax is becoming more verbose, as it does I can't help but think
      it would be cleaner if XML were restored to the spec.

      

      The trouble with specifications is that adoption rate often trumps
      quality.

      

      For me - I'm looking forward to implementing the new
      specification, in its current form which we will start work on
      shortly.

      
Alex

      On 21/10/2014 19:22, Ian Glazer wrote:

    

    

      
Do we need the schemas element in the Operations
        section?

      


        
On Tue, Oct 21, 2014 at 2:17 PM, Phil
          Hunt <phil.hunt@oracle.com>
          wrote:

          

            
Looking this over, it
              looks like the example is erroneous:
              

                
       =85 =

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       =85

                
It should be changed to (full example =
included):

                


                

                

                  
   POST =
/v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },

                  
       {


                  
         =
"method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {

                  
                    
           =
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {

                  
                  
             =
     =93schemas=94:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]

                  
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }


                  


                  

                  
If any have implemented according to the
                    erroneous example and object to the change, please
                    let the list know.

                  


                  

                  
Regards,

                  


                  

                

                
                

                  


                    On Oct 21, 2014, at 8:43 AM, Phil Hunt <phil.hunt@oracle.com>
                    wrote:

                    

                    
I agree, the PATCH =
operation
                      is not consistent.

                      

                      We shall need to put some clarifying text that the
                      outer path applies to selection of the resource
                      (in place of URL) and the inner path for the
                      operation applies to attribute/value =
selection.

                      

                      The rule of thumb should be that the JSON blob
                      within the =93data=94 attribute should match the =
body
                      payload of any other SCIM HTTP =
request?  Correct?

                      

                      Phil

                      

                      @independentid

                      www.independentid.com

                      phil.hunt@oracle.com

                      

                      

                      

                      On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, =
neXus
                      <erik.wahlstrom@nexusgroup.com>
                      wrote:

                      

                      
Yes. Looks like it=92s a
                        typo in the spec. Should be a standard PATCH
                        call within the data attribute.

                        / Erik

                        

                        On 21 Oct 2014, at 04:53, ueda@exgen.co.jp
                        wrote:

                        

                        
Hello

                          

                          In section 3.5.3(page 52) of api document,

                          PATCH method is written as follows.

                          

                          "method": "PATCH",

                          "path":
                          =
"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                          "version": "W/\"edac3253e2c0ef2\"",

                          "data": {[

                            {

                                "op": "remove",

                                "path": "nickName"

                            },

                          

                          Questions.

                          

                          1."schemas" attrribute is not need in =
"data"?

                          2."Operations" attribute is not need in
                          "data"?

                          

                          as follows.

                          

                          "method": "PATCH",

                          "path":
                          =
"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                          "version": "W/\"edac3253e2c0ef2\"",

                          "data": {

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

                            "Operations": [

                              {

                                  "op": =
"remove",

                                  "path": =
"nickName"

                              },

                          

                          -

                          Takanori Ueda.

                          

_______________________________________________

                          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

            

          

        

        

        

        


        

        -- 

        

          
Ian Glazer

          

          
Senior Director, Identity

          
+1 202 255 3166

          
        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and =
malware because avast! Antivirus =
protection is active.
			

				
	








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

=

--Apple-Mail=_F4EF066A-F0FD-417A-B9FA-5258816967C4--


From nobody Wed Oct 22 00:55: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 62D711A8AED for ; Wed, 22 Oct 2014 00:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAgjV-jVTn8I for ; Wed, 22 Oct 2014 00:55:09 -0700 (PDT)
Received: from appa.redston.com (mail2.redston.com [212.159.105.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2491A1A8AE5 for ; Wed, 22 Oct 2014 00:55:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by appa.redston.com (Postfix) with ESMTP id 0A23752022; Wed, 22 Oct 2014 08:55:08 +0100 (BST)
X-Virus-Scanned: amavisd-new at redston.com
Received: from appa.redston.com ([127.0.0.1]) by localhost (appa.redston.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGWLFBMDTxij; Wed, 22 Oct 2014 08:55:03 +0100 (BST)
Received: from [127.0.0.1] (unknown [212.159.105.77]) by appa.redston.com (Postfix) with ESMTPSA id 816F44F0D4; Wed, 22 Oct 2014 08:55:03 +0100 (BST)
Message-ID: <544762D5.2040206@switchresearch.com>
Date: Wed, 22 Oct 2014 08:55:01 +0100
From: Alex Redston 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Phil Hunt 
References:   <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com>  <5446B663.6030104@switchresearch.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060909090402010102090306"
X-Antivirus: avast! (VPS 141021-0, 21/10/2014), Outbound message
X-Antivirus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ikQWpS63WOGt2J3jLDeGI1kjTtQ
Cc: scim@ietf.org
Subject: Re: [scim] PATCH method in 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: Wed, 22 Oct 2014 07:55:13 -0000

This is a multi-part message in MIME format.
--------------060909090402010102090306
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Phil

Sorry if this is a naive question but I'm just wondering about how bulk 
patch operations will look and whether with the JSON syntax for such an 
operation would containing repeated references to the schema in each 
subsequent patch.

*"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"]*


Alex

Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

On 21/10/2014 23:49, Phil Hunt wrote:
> Alex,
>
> Thanks for your comments.
>
> Yes, our baby has been going through a healthy maturation indeed!
>
> Was there anything specific to this issue that you are recommending?
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
> On Oct 21, 2014, at 12:39 PM, Alex Redston 
> > wrote:
>
>> Contributors
>>
>> I've been away from the list for a few months so the changes seem to 
>> be fairly dramatic, a bit like seeing a child for the first time in 6 
>> months.
>>
>> Please don't be offended as this is a casual observation and is not 
>> meant in any derogatory way.
>>
>> I understand the reason for adding schema fields, it seems that the 
>> spec is becoming more verbose and I will be interested to see how 
>> many of the larger vendors who are not part of the core SCIM 
>> contributors go on to implement the v2 spec.
>>
>> I know the S in SCIM no longer stands for simple and the spec is more 
>> complete, robust, deterministic and flexible now but the syntax is 
>> becoming more verbose, as it does I can't help but think it would be 
>> cleaner if XML were restored to the spec.
>>
>> The trouble with specifications is that adoption rate often trumps 
>> quality.
>>
>> For me - I'm looking forward to implementing the new specification, 
>> in its current form which we will start work on shortly.
>> Alex
>> On 21/10/2014 19:22, Ian Glazer wrote:
>>> Do we need the schemas element in the Operations section?
>>>
>>> On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt >> > wrote:
>>>
>>>     Looking this over, it looks like the example is erroneous:
>>>
>>>             …
>>>
>>>     *        {
>>>               "method": "PATCH",
>>>               "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>               "version": "W/\"edac3253e2c0ef2\"",
>>>               "data": {[
>>>                 {
>>>                     "op": "remove",
>>>                     "path": "nickName"
>>>                 },
>>>                 {
>>>                     "op": "add",
>>>                     "path": "userName",
>>>                     "value": "Dave"
>>>                 }
>>>               ]}
>>>     *        …
>>>
>>>     It should be changed to (full example included):
>>>
>>>         POST /v2/Bulk
>>>         Host:example.com  
>>>         Accept: application/scim+json
>>>         Content-Type: application/scim+json
>>>         Authorization: Bearer h480djs93hd8
>>>         Content-Length: ...
>>>
>>>         {
>>>           "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
>>>           "failOnErrors":1,
>>>           "Operations":[
>>>             {
>>>               "method":"POST",
>>>               "path":"/Users",
>>>               "bulkId":"qwerty",
>>>               "data":{
>>>                 "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
>>>                 "userName":"Alice"
>>>               }
>>>             },
>>>
>>>             {
>>>
>>>               "method":"PUT",
>>>               "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
>>>               "version":"W\/\"3694e05e9dff591\"",
>>>               "data":{
>>>                 "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
>>>                 "id":"b7c14771-226c-4d05-8860-134711653041",
>>>                 "userName":"Bob"
>>>               }
>>>             },
>>>     *        {
>>>               "method": "PATCH",
>>>               "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>               "version": "W/\"edac3253e2c0ef2\"",
>>>               "data": {*
>>>
>>>     *            "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>                 "Operations": [
>>>                      {*
>>>
>>>     *                   “schemas”:["
>>>                        "op": "remove",
>>>                        "path": "nickName"
>>>                     },
>>>                     {
>>>                        "op": "add",
>>>                        "path": "userName",
>>>                        "value": "Dave"
>>>                     }
>>>                 ]*
>>>
>>>     *          }
>>>             },*
>>>             {
>>>               "method":"DELETE",
>>>               "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
>>>               "version":"W\/\"0ee8add0a938e1a\""
>>>             }
>>>           ]
>>>         }
>>>
>>>
>>>     If any have implemented according to the erroneous example and
>>>     object to the change, please let the list know.
>>>
>>>     Regards,
>>>
>>>     Phil
>>>
>>>     @independentid
>>>     www.independentid.com 
>>>     phil.hunt@oracle.com 
>>>
>>>
>>>
>>>     On Oct 21, 2014, at 8:43 AM, Phil Hunt >>     > wrote:
>>>
>>>>     I agree, the PATCH operation is not consistent.
>>>>
>>>>     We shall need to put some clarifying text that the outer path
>>>>     applies to selection of the resource (in place of URL) and the
>>>>     inner path for the operation applies to attribute/value selection.
>>>>
>>>>     The rule of thumb should be that the JSON blob within the
>>>>     “data” attribute should match the body payload of any other
>>>>     SCIM HTTP request?  Correct?
>>>>
>>>>     Phil
>>>>
>>>>     @independentid
>>>>     www.independentid.com 
>>>>     phil.hunt@oracle.com 
>>>>
>>>>
>>>>
>>>>     On Oct 21, 2014, at 6:11 AM, Erik Wahlström, neXus
>>>>     >>>     > wrote:
>>>>
>>>>>     Yes. Looks like it’s a typo in the spec. Should be a standard
>>>>>     PATCH call within the data attribute.
>>>>>     / Erik
>>>>>
>>>>>     On 21 Oct 2014, at 04:53, ueda@exgen.co.jp
>>>>>      wrote:
>>>>>
>>>>>>     Hello
>>>>>>
>>>>>>     In section 3.5.3(page 52) of api document,
>>>>>>     PATCH method is written as follows.
>>>>>>
>>>>>>     "method": "PATCH",
>>>>>>     "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>>>     "version": "W/\"edac3253e2c0ef2\"",
>>>>>>     "data": {[
>>>>>>       {
>>>>>>           "op": "remove",
>>>>>>           "path": "nickName"
>>>>>>       },
>>>>>>
>>>>>>     Questions.
>>>>>>
>>>>>>     1."schemas" attrribute is not need in "data"?
>>>>>>     2."Operations" attribute is not need in "data"?
>>>>>>
>>>>>>     as follows.
>>>>>>
>>>>>>     "method": "PATCH",
>>>>>>     "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>>>     "version": "W/\"edac3253e2c0ef2\"",
>>>>>>     "data": {
>>>>>>       "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>>>>       "Operations": [
>>>>>>         {
>>>>>>             "op": "remove",
>>>>>>             "path": "nickName"
>>>>>>         },
>>>>>>
>>>>>>     -
>>>>>>     Takanori Ueda.
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     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
>>>
>>>
>>>
>>>
>>> -- 
>>> Ian Glazer
>>> Senior Director, Identity
>>> +1 202 255 3166
>>> @iglazer 
>>
>>
>>
>> ------------------------------------------------------------------------
>>  	
>>
>> This email is free from viruses and malware because avast! Antivirus 
>>  protection is active.
>>
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org 
>> https://www.ietf.org/mailman/listinfo/scim
>



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

--------------060909090402010102090306
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Phil

      

      Sorry if this is a naive question but I'm just wondering about how
      bulk patch operations will look and whether with the JSON syntax
      for such an operation would containing repeated references to the
      schema in each subsequent patch. 

      

      
        
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"]

      

      Alex

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 21/10/2014 23:49, Phil Hunt wrote:

    

    

      
      Alex,
      


      

      
Thanks for your comments. 

      


      

      
Yes, our baby has been going through a healthy maturation
        indeed!

      


      

      
Was there anything specific to this issue that you are
        recommending?  

      


      

      
Phil

      

        
        

        

          
On Oct 21, 2014, at 12:39 PM, Alex Redston <aredston@switchresearch.com>
            wrote:

          

          

            
            

              
Contributors

                

                I've been away from the list for a few months so the
                changes seem to be fairly dramatic, a bit like seeing a
                child for the first time in 6 months.

                

                Please don't be offended as this is a casual observation
                and is not meant in any derogatory way.

                

                I understand the reason for adding schema fields, it
                seems that the spec is becoming more verbose and I will
                be interested to see how many of the larger vendors who
                are not part of the core SCIM contributors go on to
                implement the v2 spec.

                

                I know the S in SCIM no longer stands for simple and the
                spec is more complete, robust, deterministic and
                flexible now but the syntax is becoming more verbose, as
                it does I can't help but think it would be cleaner if
                XML were restored to the spec.

                

                The trouble with specifications is that adoption rate
                often trumps quality.

                

                For me - I'm looking forward to implementing the new
                specification, in its current form which we will start
                work on shortly.

                
Alex

                On 21/10/2014 19:22, Ian Glazer wrote:

              

              

                
Do we need the schemas element in the
                  Operations section?

                


                  
On Tue, Oct 21, 2014 at 2:17
                    PM, Phil Hunt <phil.hunt@oracle.com>
                    wrote:

                    

                      
Looking this
                        over, it looks like the example is erroneous:
                        

                          
       … 
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       …

                          
It should be changed to (full example
                            included):

                          


                          

                          

                            
   POST /v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },

                            
       {


                            
         "method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {

                            
                              
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {

                            
                            
                  “schemas”:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]

                            
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }


                            


                            

                            
If any have implemented according to
                              the erroneous example and object to the
                              change, please let the list know.

                            


                            

                            
Regards,

                            


                            

                          

                          
                          

                            


                              On Oct 21, 2014, at 8:43 AM, Phil Hunt
                              <phil.hunt@oracle.com>

                              wrote:

                              

                              
I agree, the PATCH
                                operation is not consistent.

                                

                                We shall need to put some clarifying
                                text that the outer path applies to
                                selection of the resource (in place of
                                URL) and the inner path for the
                                operation applies to attribute/value
                                selection.

                                

                                The rule of thumb should be that the
                                JSON blob within the “data” attribute
                                should match the body payload of any
                                other SCIM HTTP request?  Correct?

                                

                                Phil

                                

                                @independentid

                                www.independentid.com

                                phil.hunt@oracle.com

                                

                                

                                

                                On Oct 21, 2014, at 6:11 AM, Erik
                                Wahlström, neXus <erik.wahlstrom@nexusgroup.com>

                                wrote:

                                

                                
Yes. Looks like
                                  it’s a typo in the spec. Should be a
                                  standard PATCH call within the data
                                  attribute.

                                  / Erik

                                  

                                  On 21 Oct 2014, at 04:53, ueda@exgen.co.jp
                                  wrote:

                                  

                                  
Hello

                                    

                                    In section 3.5.3(page 52) of api
                                    document,

                                    PATCH method is written as follows.

                                    

                                    "method": "PATCH",

                                    "path":
                                    "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                                    "version": "W/\"edac3253e2c0ef2\"",

                                    "data": {[

                                      {

                                          "op": "remove",

                                          "path": "nickName"

                                      },

                                    

                                    Questions.

                                    

                                    1."schemas" attrribute is not need
                                    in "data"?

                                    2."Operations" attribute is not need
                                    in "data"?

                                    

                                    as follows.

                                    

                                    "method": "PATCH",

                                    "path":
                                    "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                                    "version": "W/\"edac3253e2c0ef2\"",

                                    "data": {

                                      "schemas":
                                    ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],

                                      "Operations": [

                                        {

                                            "op": "remove",

                                            "path": "nickName"

                                        },

                                    

                                    -

                                    Takanori Ueda.

                                    

_______________________________________________

                                    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

                      

                    

                  

                  

                  

                  


                  

                  -- 

                  

                    
Ian Glazer

                    

                    
Senior Director, Identity

                    
+1 202 255 3166

                    
                  

                

              

              

              

              

              

              

                
                  

                        
                    
                      
 This email is free from
                        viruses and malware because avast! Antivirus
                        protection is active. 

                    		
                  

                
              

              

            

            _______________________________________________

            scim mailing list

            scim@ietf.org

            https://www.ietf.org/mailman/listinfo/scim

          

        

        

      

    

    

  







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	








--------------060909090402010102090306--


From nobody Wed Oct 22 07:50: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 D2DEF1ACD05 for ; Wed, 22 Oct 2014 07:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NZ_GPUoRYF7 for ; Wed, 22 Oct 2014 07:50:01 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2087D1ACD0F for ; Wed, 22 Oct 2014 07:50:01 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id hn18so1022771igb.5 for ; Wed, 22 Oct 2014 07:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X++1yumdypr8EphA15EOpMlI+1oBwF8+iEH0CApS3TI=; b=IPSJJEtIdLvwMGM0UQsmMqLIQMelPdrtFp6toAj4vwNVeoZKVB2B7PqneAhhSSuJq/ uidRpbo/5WuhE0l4Zu4pCJ9+APNO3uyI7wWgvMN9k8zbZDoFAwR3WMv9oW5VC5BcOphI SeBQdTRwod6kUeZVPdpdpmXzb85yudGej+2nmyYFOwP43nkyWZyhUtRkIltbspp5KOBO h//rEdif7VTJlwODdVarfy2W5lpWi74l2/CL0maemKHkohA6kxsdp6ybvAaQgPi61bM2 gQBIxWMMcTsu9noa9e0Uj1P0xv28YPgCp1RwRihiUv+G7uvz2MT5kWRrLV8OWwVGtJfO W+HA==
MIME-Version: 1.0
X-Received: by 10.107.37.15 with SMTP id l15mr45942406iol.40.1413989400436; Wed, 22 Oct 2014 07:50:00 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Wed, 22 Oct 2014 07:50:00 -0700 (PDT)
In-Reply-To: <5446B9D2.8040005@switchresearch.com>
References:  <5446B9D2.8040005@switchresearch.com>
Date: Wed, 22 Oct 2014 09:50:00 -0500
Message-ID: 
From: Shelley 
To: Alex Redston , "scim@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11402fbcede6e50506040f1b
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/bNyzs-4LAxmD7UYqGlDls-cmn9c
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 14:50:10 -0000

--001a11402fbcede6e50506040f1b
Content-Type: text/plain; charset=UTF-8

The simplest approach would be to require SCIM consumers to provide phone
numbers in the RFC 3966 format, which at least helps to guarantee the
validity of the format and canonicalizes it into a standard global format
consumable by both external systems and users. This also accounts for some
of the scenarios you mentioned, such as sip calls.

As far as validating whether the phone number is actually a potentially
valid number (based on country, area code, etc.), this can be discussed
further/separately as well. I agree that validating whether a phone number
is actually in service is probably not feasible but there are some
standards and libraries that *could *potentially be used to deter
completely bogus numbers [1], but the value in this may be debatable.

The overall problem is just that without centralized data validation in the
service, SCIM consumers cannot rely on the syntax/validity of the data and
therefore the burden of validating and normalizing falls to them.

[1] https://code.google.com/p/libphonenumber/


On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston 
wrote:

>  Of course the challenge here comes down to the extent to which that
> particular data can be standardised and validated. Taking phone numbers as
> the example you have sip calls, invalid numbers, country specific
> shortcodes, this is potentially a minefield.
>
> Well formed and valid values are two distinct concepts and with multiple
> carrier technologies the anatomy of simple +4412345678901 style numbers is
> no longer fit for purpose. For this reason I do not think that it is
> feasible for this particular data type to be rejected as bad data because
> the only way to know if a phone number is valid is to dial it.
>
> What do you think?
>
> Alex
>
> Alex Redston
>
> CEO
> Switch Identity Governance Ltd
> 07973 320 795
> 020 3434 3888
>
> On 21/10/2014 20:36, Shelley wrote:
>
>  The SCIM specification expects service providers should be able to
> canonicalize provided data into a common format (e.g. RFC 3966 for
> phoneNumbers), yet it does not explicitly describe input requirements or
> validation for attributes such as these.* Is it expected that values that
> cannot accurately be canonicalized are rejected by the SCIM service or that
> the SCIM service accepts this invalid data and merely persists and returns
> this bad data to consumers?*
>
> As a SCIM Service Provider, we are currently performing validation on
> attributes such as phoneNumbers and emails to ensure that they contain
> well-formed, valid values, and returning a 400 with a description of the
> error if validation fails. One of the benefits of SCIM is that data may
> come from multiple sources and may be consumed by multiple clients, and
> SCIM provides a repository of structured and well-formed data so that
> consumers can reliably derive meaning and use from this data. Without
> attribute validation and a guarantee of canonicalized values, this goal
> does not seem feasible and puts the burden on consumers to make sense of
> potentially invalid data.
>
> The downside to attribute validation is that it requires the SCIM
> consumers sending data to ensure valid data as well. As these consumers are
> closest to the source data, though, this seems like the most reasonable
> approach rather than putting the burden on the service provider and/or
> other SCIM consumers to make sense of the data. Aside from just "bad data"
> (e.g. sending "not a phone number" or "000-0000" for a phone number), for
> example, if the SCIM consumer sending source data sends phone numbers
> without area codes or sends only internal extensions, another SCIM consumer
> may not be able to make sense of this data. It seems reasonable to require
> the consumer sending the data to ensure that this data is well-formed and
> canonicalized/canonicalizable.
>
> A *good *example in the SCIM specification is the country attribute,
> which clearly indicates the attribute's requirements. A *bad *example is
> the phoneNumbers attribute, which doesn't describe the expected format to
> be provided by consumers, yet recommends that the service provider
> canonicalize the value even though the input may not be able to be
> canonicalized.
>
>  I'd be interested in hearing others' opinions on this matter, and whether
> the SCIM specification should clarify further restrictions on attribute
> values.
>
>
>
>
> ------------------------------
>    
>
> This email is free from viruses and malware because avast! Antivirus
>  protection is active.
>
>

--001a11402fbcede6e50506040f1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The simplest approach would be to require SCIM consum=
ers to provide phone numbers in the RFC 3966 format, which at least helps t=
o guarantee the validity of the format and canonicalizes it into a standard=
 global format consumable by both external systems and users. This also acc=
ounts for some of the scenarios you mentioned, such as sip calls.

As far as validating whether the phone number is actually a potent=
ially valid number (based on country, area code, etc.), this can be discuss=
ed further/separately as well. I agree that validating whether a phone numb=
er is actually in service is probably not feasible but there are some stand=
ards and libraries that could potentially be used to deter completel=
y bogus numbers [1], but the value in this may be debatable.

<=
div>The overall problem is just that without centralized data validation in=
 the service, SCIM consumers cannot rely on the syntax/validity of the data=
 and therefore the burden of validating and normalizing falls to them.
<=
/div>

[1] https://code.google.com/p/libphonenumber/


On Tue, Oct 21, 2014 at=
 2:53 PM, Alex Redston <aredston@switchresearch.com> wrote:

 =20
   =20
 =20
  

    
Of course the challenge here comes down
      to the extent to which that particular data can be standardised
      and validated. Taking phone numbers as the example you have sip
      calls, invalid numbers, country specific shortcodes, this is
      potentially a minefield.

      

      Well formed and valid values are two distinct concepts and with
      multiple carrier technologies the anatomy of simple +4412345678901
      style numbers is no longer fit for purpose. For this reason I do
      not think that it is feasible for this particular data type to be
      rejected as bad data because the only way to know if a phone
      number is valid is to dial it.

      

      What do you think?

      

      Alex

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 21/10/2014 20:36, Shelley wrote:

    

    

      

        
The SCIM specification expects service providers should be
          able to canonicalize provided data into a common format (e.g.
          RFC 3966 for ph=
oneNumbers),
          yet it does not explicitly describe input requirements or
          validation for attributes such as these. Is it expected
            that values that cannot accurately be canonicalized are
            rejected by the SCIM service or that the SCIM service
            accepts this invalid data and merely persists and returns
            this bad data to consumers?

          

          As a SCIM Service Provider, we are currently performing
          validation on attributes such as phoneNumbers and
          emails t=
o
          ensure that they contain well-formed, valid values, and
          returning a 400 with a description of the error if validation
          fails. One of the benefits of SCIM is that data may come from
          multiple sources and may be consumed by multiple clients, and
          SCIM provides a repository of structured and well-formed data
          so that consumers can reliably derive meaning and use from
          this data. Without attribute validation and a guarantee of
          canonicalized values, this goal does not seem feasible and
          puts the burden on consumers to make sense of potentially
          invalid data.

          

          The downside to attribute validation is that it requires the
          SCIM consumers sending data to ensure valid data as well. As
          these consumers are closest to the source data, though, this
          seems like the most reasonable approach rather than putting
          the burden on the service provider and/or other SCIM consumers
          to make sense of the data. Aside from just "bad data" (=
e.g.
          sending "not a phone number" or "000-0000" fo=
r a phone
          number), for example, if the SCIM consumer sending source data
          sends phone numbers without area codes or sends only internal
          extensions, another SCIM consumer may not be able to make
          sense of this data. It seems reasonable to require the
          consumer sending the data to ensure that this data is
          well-formed and canonicalized/canonicalizable.

          

          A good example in the SCIM specification is the country attribute,
          which clearly indicates the attribute's requirements. A ba=
d
          example is the phoneNumbers attribute, which doesn't
          describe the expected format to be provided by consumers, yet
          recommends that the service provider canonicalize the value
          even though the input may not be able to be canonicalized.

          

        

        I'd be interested in hearing others' opinions on this matte=
r,
        and whether the SCIM specification should clarify further
        restrictions on attribute values.

      

    

    

 =20







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	












--001a11402fbcede6e50506040f1b--


From nobody Wed Oct 22 08:41: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 2564F1ACD6D for ; Wed, 22 Oct 2014 08:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok50th4FBlbA for ; Wed, 22 Oct 2014 08:41:45 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1374E1ACD5F for ; Wed, 22 Oct 2014 08:41:45 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id a141so2960395oig.34 for ; Wed, 22 Oct 2014 08:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7v9Hry8g8CNNzswVDztrny7xwbpRcU6u+kGszGZ1apE=; b=FE+C/z+c63+xMlqvz87kCZS/XBVcPkC8use94rKLGccX1vQkKURiMKvHwWSf2x8v1S UXuvqOEyO67PRiqz9VAMjRQGrY9QHAGg3V+pP7ouZrUty70RtGZLoT0LorN1loBNq9mb Wzk57gnmBxF8f3bmif5A7iQJZgZ/NlQltzuuWvxk3UImmYMem+YGTlyZ9CC9+fXtyoRm 4W9rxUarXRus9oksaOj03U8rbK7C3rz6XYhCeeVjqadL9rLXpbOGuy9UJRRawC8PIQol HN1LycZYWFIVi0ubqmP6Tf/ds5u5vBhSS1Z+xsHlE1e5dIfywYEVouTsPr+L1Q84jIiu RjJQ==
MIME-Version: 1.0
X-Received: by 10.202.195.215 with SMTP id t206mr147246oif.121.1413992504512;  Wed, 22 Oct 2014 08:41:44 -0700 (PDT)
Received: by 10.60.78.232 with HTTP; Wed, 22 Oct 2014 08:41:44 -0700 (PDT)
In-Reply-To: <5447C7C1.9000704@switchresearch.com>
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>
Date: Wed, 22 Oct 2014 10:41:44 -0500
Message-ID: 
From: Shelley 
To: Alex Redston , "scim@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113530ccf256c7050604c8a3
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/NfGvfV3MgULMttqioBKOkgqH_5U
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 15:41:49 -0000

--001a113530ccf256c7050604c8a3
Content-Type: text/plain; charset=UTF-8

I'd also like to clarify/highlight this problem/challenge with the current
SCIM specification - the spec recommends that service providers
canonicalize phone numbers to RFC 3966, yet, if there are no requirements
for the data provided by the consumer, this may be impossible.

In the extreme scenario, how can a SCIM SP canonicalize "not a phone
number" to RFC 3966? In an incomplete scenario, how can an SP canonicalize
"222-2222" without a country/area code? And in an ambiguous scenario, how
can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
extension)?

While it may be possible for the SP to canonicalize *some *values under
some *assumptions *(e.g. country code may be assumed, and assumptions based
on patterns, etc), it is still possible that the canonicalization would be
incorrect and in some cases, impossible.

How are other SPs handling this? Is anyone doing validation or
canonicalization?

Likewise, how are SCIM clients consuming phone numbers (especially those
that may be read-only consumers of data and don't have visibility/control
over the source data)? Is anyone doing any normalizing, validating,
canonicalizing, or just leaving the data as-is regardless of the
format/validity?


On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston 
wrote:

>  Thanks - interesting link.
>
> Alex Redston
>
> CEO
> Switch Identity Governance Ltd
> 07973 320 795
> 020 3434 3888
>
> On 22/10/2014 15:50, Shelley wrote:
>
>  The simplest approach would be to require SCIM consumers to provide
> phone numbers in the RFC 3966 format, which at least helps to guarantee the
> validity of the format and canonicalizes it into a standard global format
> consumable by both external systems and users. This also accounts for some
> of the scenarios you mentioned, such as sip calls.
>
>  As far as validating whether the phone number is actually a potentially
> valid number (based on country, area code, etc.), this can be discussed
> further/separately as well. I agree that validating whether a phone number
> is actually in service is probably not feasible but there are some
> standards and libraries that *could *potentially be used to deter
> completely bogus numbers [1], but the value in this may be debatable.
>
>  The overall problem is just that without centralized data validation in
> the service, SCIM consumers cannot rely on the syntax/validity of the data
> and therefore the burden of validating and normalizing falls to them.
>
> [1] https://code.google.com/p/libphonenumber/
>
>
> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston  > wrote:
>
>>  Of course the challenge here comes down to the extent to which that
>> particular data can be standardised and validated. Taking phone numbers as
>> the example you have sip calls, invalid numbers, country specific
>> shortcodes, this is potentially a minefield.
>>
>> Well formed and valid values are two distinct concepts and with multiple
>> carrier technologies the anatomy of simple +4412345678901 style numbers is
>> no longer fit for purpose. For this reason I do not think that it is
>> feasible for this particular data type to be rejected as bad data because
>> the only way to know if a phone number is valid is to dial it.
>>
>> What do you think?
>>
>> Alex
>>
>> Alex Redston
>>
>> CEO
>> Switch Identity Governance Ltd
>> 07973 320 795
>> 020 3434 3888
>>
>>  On 21/10/2014 20:36, Shelley wrote:
>>
>>  The SCIM specification expects service providers should be able to
>> canonicalize provided data into a common format (e.g. RFC 3966 for
>> phoneNumbers), yet it does not explicitly describe input requirements or
>> validation for attributes such as these.* Is it expected that values
>> that cannot accurately be canonicalized are rejected by the SCIM service or
>> that the SCIM service accepts this invalid data and merely persists and
>> returns this bad data to consumers?*
>>
>> As a SCIM Service Provider, we are currently performing validation on
>> attributes such as phoneNumbers and emails to ensure that they contain
>> well-formed, valid values, and returning a 400 with a description of the
>> error if validation fails. One of the benefits of SCIM is that data may
>> come from multiple sources and may be consumed by multiple clients, and
>> SCIM provides a repository of structured and well-formed data so that
>> consumers can reliably derive meaning and use from this data. Without
>> attribute validation and a guarantee of canonicalized values, this goal
>> does not seem feasible and puts the burden on consumers to make sense of
>> potentially invalid data.
>>
>> The downside to attribute validation is that it requires the SCIM
>> consumers sending data to ensure valid data as well. As these consumers are
>> closest to the source data, though, this seems like the most reasonable
>> approach rather than putting the burden on the service provider and/or
>> other SCIM consumers to make sense of the data. Aside from just "bad data"
>> (e.g. sending "not a phone number" or "000-0000" for a phone number), for
>> example, if the SCIM consumer sending source data sends phone numbers
>> without area codes or sends only internal extensions, another SCIM consumer
>> may not be able to make sense of this data. It seems reasonable to require
>> the consumer sending the data to ensure that this data is well-formed and
>> canonicalized/canonicalizable.
>>
>> A *good *example in the SCIM specification is the country attribute,
>> which clearly indicates the attribute's requirements. A *bad *example is
>> the phoneNumbers attribute, which doesn't describe the expected format
>> to be provided by consumers, yet recommends that the service provider
>> canonicalize the value even though the input may not be able to be
>> canonicalized.
>>
>>  I'd be interested in hearing others' opinions on this matter, and
>> whether the SCIM specification should clarify further restrictions on
>> attribute values.
>>
>>
>>
>>
>>  ------------------------------
>>     
>>
>> This email is free from viruses and malware because avast! Antivirus
>>  protection is active.
>>
>>
>
>
>
> ------------------------------
>    
>
> This email is free from viruses and malware because avast! Antivirus
>  protection is active.
>
>

--001a113530ccf256c7050604c8a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'd also like to clarify/highlight this=
 problem/challenge with the current SCIM specification - the spec recommend=
s that service providers canonicalize phone numbers to RFC 3966, yet, if th=
ere are no requirements for the data provided by the consumer, this may be =
impossible.

In the extreme scenario, how can a SCIM SP canonicalize =
"not a phone number" to RFC 3966? In an incomplete scenario, how =
can an SP canonicalize "222-2222" without a country/area code? An=
d in an ambiguous scenario, how can an SP canonicalize "201-5399 123&q=
uot; (where 123 is assumed to be an extension)?

While it may b=
e possible for the SP to canonicalize some values under some assu=
mptions (e.g. country code may be assumed, and assumptions based on pat=
terns, etc), it is still possible that the canonicalization would be incorr=
ect and in some cases, impossible.

How are other SPs handling =
this? Is anyone doing validation or canonicalization? 

Likewis=
e, how are SCIM clients consuming phone numbers (especially those that may =
be read-only consumers of data and don't have visibility/control over t=
he source data)? Is anyone doing any normalizing, validating, canonicalizin=
g, or just leaving the data as-is regardless of the format/validity?


On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <aredston@switch=
research.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com><=
/span>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        
                          

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	












--001a113530ccf256c7050604c8a3--


From nobody Wed Oct 22 08:55:58 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 1AD0E1ACD8E for ; Wed, 22 Oct 2014 08:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu70eKarOU1j for ; Wed, 22 Oct 2014 08:55:45 -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 20D341ACD82 for ; Wed, 22 Oct 2014 08:55:45 -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 s9MFtfTK012967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Oct 2014 15:55:42 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 s9MFte9D006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 15:55:40 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 s9MFteLX006652; Wed, 22 Oct 2014 15:55:40 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Oct 2014 08:55:39 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_40D57901-59F3-4F1A-973A-2FFF92BC0DD7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: <544762D5.2040206@switchresearch.com>
Date: Wed, 22 Oct 2014 08:55:38 -0700
Message-Id: 
References:   <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com>  <5446B663.6030104@switchresearch.com>  <544762D5.2040206@switchresearch.com>
To: Alex Redston 
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/wyXrj9nvWlh4Lb2-Qw7JCgKOJv8
Cc: scim@ietf.org
Subject: Re: [scim] PATCH method in 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: Wed, 22 Oct 2014 15:55:52 -0000

--Apple-Mail=_40D57901-59F3-4F1A-973A-2FFF92BC0DD7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Alex,

What goes in the =93data" attribute should match what you would put in =
the body of a single HTTP PATCH request.

IOW, if you were to take the value of =93data=94 and put it as input =
into your PATCH operation parser it should work the same.=20

Sooo=85

In the case of PATCH, each sub-operation does not have a repeated =
schemas attribute. There is only one at the top of the array =97 =
following the same pattern as the normal PATCH request.

As a full example, the following bulk request has a patch and a delete =
operation. The patch operation also has 2 operations to the same User =
which removes the attribute =93members=94 and then adds 2 values back to =
members (note: this could be more concise using replace, but I=92m =
showing multiple repeated operations). Note that the bolded section =
should exactly match the body of the normal HTTP PATCH request:
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
  "failOnErrors":1,
  "Operations":[      =20
    {
      "method": "PATCH",
      "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
      "version": "W/\"edac3253e2c0ef2\"",
      "data":
        {
          "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
          "Operations": [
            {
              "op":"remove","path":"members"
            },
            {
              "op":"add",
              "path":"members",
              "value":[
                {
                  "display": "Babs Jensen",
                  "$ref": =
"https://example.com/v2/Users/2819c223...413861904646",
                  "value": "2819c223-7f76-453a-919d-413861904646"
                },
                {
                  "display": "James Smith",
                  "$ref": =
"https://example.com/v2/Users/08e1d05d...473d93df9210",
                  "value": "08e1d05d-121c-4561-8b96-473d93df9210"
                }]
            }
          ]
        }=20
    },
    {
      "method":"DELETE",
      "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "version":"W\/\"0ee8add0a938e1a\""
    }
  ]
}

I agree, in this compound case, it looks a bit complicated =
(=93operations=94, =93path" and =93schemas=94 are repeated). However, =
within each structure the JSON is consistent.  Meaning, you could cut =
and paste the body from HTTP PATCH and place it in the =93data=94 =
attribute.
=20
Phil

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



On Oct 22, 2014, at 12:55 AM, Alex Redston  =
wrote:

> Hi Phil
>=20
> Sorry if this is a naive question but I'm just wondering about how =
bulk patch operations will look and whether with the JSON syntax for =
such an operation would containing repeated references to the schema in =
each subsequent patch.=20
>=20
>  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"]
>=20
> Alex
> Alex Redston
>=20
> CEO
> Switch Identity Governance Ltd
> 07973 320 795
> 020 3434 3888
> On 21/10/2014 23:49, Phil Hunt wrote:
>> Alex,
>>=20
>> Thanks for your comments.=20
>>=20
>> Yes, our baby has been going through a healthy maturation indeed!
>>=20
>> Was there anything specific to this issue that you are recommending? =20=

>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>> On Oct 21, 2014, at 12:39 PM, Alex Redston =
 wrote:
>>=20
>>> Contributors
>>>=20
>>> I've been away from the list for a few months so the changes seem to =
be fairly dramatic, a bit like seeing a child for the first time in 6 =
months.
>>>=20
>>> Please don't be offended as this is a casual observation and is not =
meant in any derogatory way.
>>>=20
>>> I understand the reason for adding schema fields, it seems that the =
spec is becoming more verbose and I will be interested to see how many =
of the larger vendors who are not part of the core SCIM contributors go =
on to implement the v2 spec.
>>>=20
>>> I know the S in SCIM no longer stands for simple and the spec is =
more complete, robust, deterministic and flexible now but the syntax is =
becoming more verbose, as it does I can't help but think it would be =
cleaner if XML were restored to the spec.
>>>=20
>>> The trouble with specifications is that adoption rate often trumps =
quality.
>>>=20
>>> For me - I'm looking forward to implementing the new specification, =
in its current form which we will start work on shortly.
>>> Alex
>>> On 21/10/2014 19:22, Ian Glazer wrote:
>>>> Do we need the schemas element in the Operations section?
>>>>=20
>>>> On Tue, Oct 21, 2014 at 2:17 PM, Phil Hunt  =
wrote:
>>>> Looking this over, it looks like the example is erroneous:
>>>>        =85=20
>>>>        {
>>>>          "method": "PATCH",
>>>>          "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>          "version": "W/\"edac3253e2c0ef2\"",
>>>>          "data": {[
>>>>            {
>>>>                "op": "remove",
>>>>                "path": "nickName"
>>>>            },
>>>>            {
>>>>                "op": "add",
>>>>                "path": "userName",
>>>>                "value": "Dave"
>>>>            }
>>>>          ]}
>>>>        =85
>>>> It should be changed to (full example included):
>>>>=20
>>>>    POST /v2/Bulk
>>>>    Host: example.com
>>>>    Accept: application/scim+json
>>>>    Content-Type: application/scim+json
>>>>    Authorization: Bearer h480djs93hd8
>>>>    Content-Length: ...
>>>>=20
>>>>    {
>>>>      "schemas": =
["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
>>>>      "failOnErrors":1,
>>>>      "Operations":[
>>>>        {
>>>>          "method":"POST",
>>>>          "path":"/Users",
>>>>          "bulkId":"qwerty",
>>>>          "data":{
>>>>            "schemas": =
["urn:ietf:params:scim:api:messages:2.0:User"],
>>>>            "userName":"Alice"
>>>>          }
>>>>        },
>>>>        {
>>>>          "method":"PUT",
>>>>          "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
>>>>          "version":"W\/\"3694e05e9dff591\"",
>>>>          "data":{
>>>>            "schemas": =
["urn:ietf:params:scim:schemas:core:2.0:User"],
>>>>            "id":"b7c14771-226c-4d05-8860-134711653041",
>>>>            "userName":"Bob"
>>>>          }
>>>>        },
>>>>        {
>>>>          "method": "PATCH",
>>>>          "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>          "version": "W/\"edac3253e2c0ef2\"",
>>>>          "data": {
>>>>             "schemas": =
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>>            "Operations": [
>>>>                {
>>>>                    =93schemas=94:["
>>>>                   "op": "remove",
>>>>                   "path": "nickName"
>>>>                },
>>>>                {
>>>>                   "op": "add",
>>>>                   "path": "userName",
>>>>                   "value": "Dave"
>>>>                }
>>>>            ]
>>>>          }
>>>>        },
>>>>        {
>>>>          "method":"DELETE",
>>>>          "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
>>>>          "version":"W\/\"0ee8add0a938e1a\""
>>>>        }
>>>>      ]
>>>>    }
>>>>=20
>>>> If any have implemented according to the erroneous example and =
object to the change, please let the list know.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>> On Oct 21, 2014, at 8:43 AM, Phil Hunt  =
wrote:
>>>>=20
>>>>> I agree, the PATCH operation is not consistent.
>>>>>=20
>>>>> We shall need to put some clarifying text that the outer path =
applies to selection of the resource (in place of URL) and the inner =
path for the operation applies to attribute/value selection.
>>>>>=20
>>>>> The rule of thumb should be that the JSON blob within the =93data=94=
 attribute should match the body payload of any other SCIM HTTP request? =
 Correct?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Oct 21, 2014, at 6:11 AM, Erik Wahlstr=F6m, neXus =
 wrote:
>>>>>=20
>>>>>> Yes. Looks like it=92s a typo in the spec. Should be a standard =
PATCH call within the data attribute.
>>>>>> / Erik
>>>>>>=20
>>>>>> On 21 Oct 2014, at 04:53, ueda@exgen.co.jp wrote:
>>>>>>=20
>>>>>>> Hello
>>>>>>>=20
>>>>>>> In section 3.5.3(page 52) of api document,
>>>>>>> PATCH method is written as follows.
>>>>>>>=20
>>>>>>> "method": "PATCH",
>>>>>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>>>> "version": "W/\"edac3253e2c0ef2\"",
>>>>>>> "data": {[
>>>>>>>   {
>>>>>>>       "op": "remove",
>>>>>>>       "path": "nickName"
>>>>>>>   },
>>>>>>>=20
>>>>>>> Questions.
>>>>>>>=20
>>>>>>> 1."schemas" attrribute is not need in "data"?
>>>>>>> 2."Operations" attribute is not need in "data"?
>>>>>>>=20
>>>>>>> as follows.
>>>>>>>=20
>>>>>>> "method": "PATCH",
>>>>>>> "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
>>>>>>> "version": "W/\"edac3253e2c0ef2\"",
>>>>>>> "data": {
>>>>>>>   "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>>>>>   "Operations": [
>>>>>>>     {
>>>>>>>         "op": "remove",
>>>>>>>         "path": "nickName"
>>>>>>>     },
>>>>>>>=20
>>>>>>> -
>>>>>>> Takanori Ueda.
>>>>>>>=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
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --=20
>>>> Ian Glazer
>>>> Senior Director, Identity
>>>> +1 202 255 3166
>>>> @iglazer
>>>=20
>>>=20
>>>=20
>>>  =09
>>> This email is free from viruses and malware because avast! Antivirus =
protection is active.=20
>>>=20
>>>=20
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>>=20
>=20
>=20
>=20
>  =09
> This email is free from viruses and malware because avast! Antivirus =
protection is active. 		=09
>=20
>=20


--Apple-Mail=_40D57901-59F3-4F1A-973A-2FFF92BC0DD7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Alex,

What goes in the =93data" =
attribute should match what you would put in the body of a single HTTP =
PATCH request.

IOW, if you were to take the =
value of =93data=94 and put it as input into your PATCH operation parser =
it should work the =
same. 

Sooo=85

In =
the case of PATCH, each sub-operation does not have a repeated schemas =
attribute. There is only one at the top of the array =97 following the =
same pattern as the normal PATCH request.

As a =
full example, the following bulk request has a patch and a delete =
operation. The patch operation also has 2 operations to the same User =
which removes the attribute =93members=94 and then adds 2 values back to =
members (note: this could be more concise using replace, but I=92m =
showing multiple repeated operations). Note that the bolded section should exactly match the =
body of the normal HTTP PATCH request:
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
  "failOnErrors":1,
  "Operations":[      =
 
    {

      "method": "PATCH",
      "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
      "version": "W/\"edac3253e2c0ef2\"",
      "data":

        {
          "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
          "Operations": [
            {
              "op":"remove","path":"members"
            },
            {
              "op":"add",
              "path":"members",
              "value":[
                {
                  "display": "Babs Jensen",
                  "$ref": "https://exam=
ple.com/v2/Users/2819c223...413861904646",
                  "value": "2819c223-7f76-453a-919d-413861904646"
                },
                {
                  "display": "James Smith",
                  "$ref": "https://exam=
ple.com/v2/Users/08e1d05d...473d93df9210",
                  "value": "08e1d05d-121c-4561-8b96-473d93df9210"
                }]
            }
          ]
        } 
    },
    {
      "method":"DELETE",
      "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "version":"W\/\"0ee8add0a938e1a\""
    }
  ]
}


I agree, in this compound case, it looks =
a bit complicated (=93operations=94, =93path" and =93schemas=94 are =
repeated). However, within each structure the JSON is consistent. =
 Meaning, you could cut and paste the body from HTTP PATCH and =
place it in the =93data=94 attribute.
 


On Oct 22, 2014, at 12:55 AM, Alex Redston <aredston@switchresearch.com> wrote:


 =20
    
 =20
  

    
Hi Phil

      

      Sorry if this is a naive question but I'm just wondering about how
      bulk patch operations will look and whether with the JSON syntax
      for such an operation would containing repeated references to the
      schema in each subsequent patch. 

      

      
        
"schemas": =
["urn:ietf:params:scim:api:messages:2.0:PatchOp"]

      

      Alex

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 21/10/2014 23:49, Phil Hunt wrote:

    

    

      
      Alex,
      


      

      
Thanks for your comments. 

      


      

      
Yes, our baby has been going through a healthy maturation
        indeed!

      


      

      
Was there anything specific to this issue that you are
        recommending?  

      


      

      
Phil

      

        
        

        

          
On Oct 21, 2014, at 12:39 PM, Alex Redston <aredston@switchresearch.com>
            wrote:

          

          

            
            

              
Contributors

                

                I've been away from the list for a few months so the
                changes seem to be fairly dramatic, a bit like seeing a
                child for the first time in 6 months.

                

                Please don't be offended as this is a casual observation
                and is not meant in any derogatory way.

                

                I understand the reason for adding schema fields, it
                seems that the spec is becoming more verbose and I will
                be interested to see how many of the larger vendors who
                are not part of the core SCIM contributors go on to
                implement the v2 spec.

                

                I know the S in SCIM no longer stands for simple and the
                spec is more complete, robust, deterministic and
                flexible now but the syntax is becoming more verbose, as
                it does I can't help but think it would be cleaner if
                XML were restored to the spec.

                

                The trouble with specifications is that adoption rate
                often trumps quality.

                

                For me - I'm looking forward to implementing the new
                specification, in its current form which we will start
                work on shortly.

                
Alex

                On 21/10/2014 19:22, Ian Glazer wrote:

              

              

                
Do we need the schemas element in the
                  Operations section?

                


                  
On Tue, Oct 21, 2014 at =
2:17
                    PM, Phil Hunt <phil.hunt@oracle.com>
                    wrote:

                    

                      
Looking this
                        over, it looks like the example is erroneous:
                        

                          
       =85 =

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       =85

                          
It should be changed to (full example
                            included):

                          


                          

                          

                            
   POST =
/v2/Bulk
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
     "failOnErrors":1,
     "Operations":[
       {
         "method":"POST",
         "path":"/Users",
         "bulkId":"qwerty",
         "data":{
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:User"],
           "userName":"Alice"
         }
       },

                            
       {


                            
         =
"method":"PUT",
         "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
         "version":"W\/\"3694e05e9dff591\"",
         "data":{
           "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
           "id":"b7c14771-226c-4d05-8860-134711653041",
           "userName":"Bob"
         }
       },
       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {

                            
                              
           =
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {

                            
                            
             =
     =93schemas=94:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]

                            
         }
       },
       {
         "method":"DELETE",
         "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
         "version":"W\/\"0ee8add0a938e1a\""
       }
     ]
   }


                            


                            

                            
If any have implemented according to
                              the erroneous example and object to the
                              change, please let the list know.

                            


                            

                            
Regards,

                            


                            

                          

                          
                          

                            


                              On Oct 21, 2014, at 8:43 AM, Phil Hunt
                              <phil.hunt@oracle.com>

                              wrote:

                              

                              
I agree, the =
PATCH
                                operation is not consistent.

                                

                                We shall need to put some clarifying
                                text that the outer path applies to
                                selection of the resource (in place of
                                URL) and the inner path for the
                                operation applies to =
attribute/value
                                selection.

                                

                                The rule of thumb should be that the
                                JSON blob within the =93data=94 =
attribute
                                should match the body payload of any
                                other SCIM HTTP =
request?  Correct?

                                

                                Phil

                                

                                @independentid

                                www.independentid.com

                                phil.hunt@oracle.com

                                

                                

                                

                                On Oct 21, 2014, at 6:11 AM, Erik
                                Wahlstr=F6m, neXus <erik.wahlstrom@nexusgroup.com>

                                wrote:

                                

                                
Yes. Looks =
like
                                  it=92s a typo in the spec. Should be a
                                  standard PATCH call within the data
                                  attribute.

                                  / Erik

                                  

                                  On 21 Oct 2014, at 04:53, ueda@exgen.co.jp
                                  wrote:

                                  

                                  
Hello

                                    

                                    In section 3.5.3(page 52) of api
                                    document,

                                    PATCH method is written as =
follows.

                                    

                                    "method": "PATCH",

                                    "path":
                                    =
"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                                    "version": =
"W/\"edac3253e2c0ef2\"",

                                    "data": {[

                                      {

                                          "op": =
"remove",

                                          "path": =
"nickName"

                                      },

                                    

                                    Questions.

                                    

                                    1."schemas" attrribute is not need
                                    in "data"?

                                    2."Operations" attribute is not need
                                    in "data"?

                                    

                                    as follows.

                                    

                                    "method": "PATCH",

                                    "path":
                                    =
"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",

                                    "version": =
"W/\"edac3253e2c0ef2\"",

                                    "data": {

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

                                      "Operations": [

                                        {

                                            "op": =
"remove",

                                            "path": =
"nickName"

                                        },

                                    

                                    -

                                    Takanori Ueda.

                                    

_______________________________________________

                                    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

                      

                    

                  

                  

                  

                  


                  

                  -- 

                  

                    
Ian Glazer

                    

                    
Senior Director, Identity

                    
+1 202 255 3166

                    
                  

                

              

              

              

              

              

              

                
                  

                     =
  =
 
                    
 This email is free from
                        viruses and malware because avast! =
Antivirus
                        protection is active. 

                    		
                  

                
              

              

            

            _______________________________________________

            scim mailing list

            scim@ietf.org

            https://www.ietf.org/m=
ailman/listinfo/scim

          

        

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and =
malware because avast! Antivirus =
protection is active.
			

				
	










=

--Apple-Mail=_40D57901-59F3-4F1A-973A-2FFF92BC0DD7--


From nobody Wed Oct 22 09:04:38 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 21A4B1ACDBE for ; Wed, 22 Oct 2014 09:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osUjC-oNr_rd for ; Wed, 22 Oct 2014 09:04:33 -0700 (PDT)
Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id B53511ACD6B for ; Wed, 22 Oct 2014 09:04:33 -0700 (PDT)
Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr21g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id s9MG4WpU3088464; Wed, 22 Oct 2014 12:04:32 -0400
Date: Wed, 22 Oct 2014 12:04:31 -0400 (EDT)
From: Steve Moyer 
To: Shelley 
Message-ID: <1634174574.753815.1413993871859.JavaMail.zimbra@psu.edu>
In-Reply-To: 
References: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu>  
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_753814_907414503.1413993871858"
X-Originating-IP: [128.118.58.157]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922)
Thread-Topic: address.display versus address.formatted
Thread-Index: ahVyI5hKs/oXttJYSZiQjrLqYOpGYw==
X-Virus-Scanned: by amavisd-new
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/IceAGnksxUh6A6MN3CVu_-rJ2Kw
Cc: scim@ietf.org, Phil Hunt 
Subject: Re: [scim] address.display versus address.formatted
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, 22 Oct 2014 16:04:36 -0000

------=_Part_753814_907414503.1413993871858
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I should also have noted that we haven't implemented all the attributes (th=
e ones we didn't need) yet. We do however have 2.5m users with an LDAP back=
-end currently available via both our v1 API (completely non-standard) and =
through the SCIM interface. We've got some additional restrictions (on user=
Name and externalId) that are specific to our system but we're working towa=
rds being compliant with the specification when it's ratified.=20

If address.formatted and address.display are essentially the same thing, I'=
d be happy to change my system to use display so that address is consistent=
 with all the other multi-valued attributes. Can we drop address.formatted =
altogether?=20

Steve=20

--=20

=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=20

----- Original Message -----

From: "Shelley" =20
To: "Phil Hunt" =20
Cc: "Steve Moyer" , scim@ietf.org=20
Sent: Tuesday, October 21, 2014 3:45:56 PM=20
Subject: Re: [scim] address.display versus address.formatted=20

Our implementation does the same thing, such that we ignore the address " d=
isplay " sub-attribute. Likewise, we do not support the " display " attribu=
te for several other multi-valued attributes since it seems to provide no a=
dditional value beyond the " value " attribute:=20

    * addresses=20
    * emails=20
    * phoneNumbers=20
    * photos=20
    * roles=20


(We also current ly ignore the ims , entitlements , and x509Certificates at=
tributes completely since we have no use cases for these, but would likely =
ignore the "display" attribute for these attributes as well should we add s=
upport for these attributes.)=20

On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt < phil.hunt@oracle.com > wrote:=
=20


+1=20

Thanks Steve. Curious to hear what others have implemented too.=20

Phil=20

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



On Oct 21, 2014, at 8:53 AM, Steve Moyer < smoyer@psu.edu > wrote:=20

> Are the address.display attribute (inherited from SCIM Multi-Valued Attri=
bute) and the address.formatted attribute (part of the address definition) =
ambiguous? Can anyone provide insight into how they're being used? Our curr=
ent implementation sets address.formatted and ignores address.display but I=
'm curious to know how others are populating these fields.=20
>=20
> Thanks,=20
>=20
> Steve=20
>=20
> --=20
>=20
> =E2=80=9CThe 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 fo=
r one.=E2=80=9D - Wilhelm Stekel=20
>=20
> _______________________________________________=20
> scim mailing list=20
> scim@ietf.org=20
> https://www.ietf.org/mailman/listinfo/scim=20

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






------=_Part_753814_907414503.1413993871858
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


I should also have noted that we=
 haven't implemented all the attributes (the ones we didn't need) yet. =
; We do however have 2.5m users with an LDAP back-end currently available v=
ia both our v1 API (completely non-standard) and through the SCIM interface=
.  We've got some additional restrictions (on userName and externalId)=
 that are specific to our system but we're working towards being compliant =
with the specification when it's ratified.

If =
address.formatted and address.display are essentially the same thing, I'd b=
e happy to change my system to use display so that address is consistent wi=
th all the other multi-valued attributes.  Can we drop address.formatt=
ed altogether?

Steve

--

=E2=80=9CThe 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.=E2=80=9D - Wilhelm Stekel

From: "Shelley" <ran=
domshelley@gmail.com>
To: "Phil Hunt" <phil.hunt@oracle.com=
>
Cc: "Steve Moyer" <smoyer@psu.edu>, scim@ietf.org
<=
b>Sent: Tuesday, October 21, 2014 3:45:56 PM
Subject: Re: [sc=
im] address.display versus address.formatted

Our implementation does the same thing, such that we ignore the addres=
s "display" sub-at=
tribute. Likewise, we do not support the "display" attribute for several other multi-valued a=
ttributes since it seems to provide no additional value beyond the "value" attribute:
    =

  • addresses
    <=
/li>
  • emails
  • phoneNumbers<=
/li>
  • photos
  • roles
    • (We also currently ignore the ims, entitlements=
, and x509Certificates attributes completely since we have no use cases for these, but would =
likely ignore the "displa=
y" attribute for these attributes as well should we add support for =
these attributes.)

=

On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
+1



Thanks Steve.  Curious to hear what others have implemented too.



Phil



@independentid

www.independenti=
d.com

phil.hunt@oracle.=
com








On Oct 21, 2014, at 8:53 AM, Steve Moyer <smoyer@psu.edu> wrote:



> Are the address.display attribute (inherited from SCIM Multi-Valued At=
tribute) and the address.formatted attribute (part of the address definitio=
n) ambiguous?  Can anyone provide insight into how they're being used?=
  Our current implementation sets address.formatted and ignores addres=
s.display but I'm curious to know how others are populating these fields.
>

> Thanks,

>

> Steve

>

> --

>

> =E2=80=9CThe mark of the immature man is that he wants to die nobly fo=
r a cause, while the mark of the mature man is that he wants to live humbly=
 for one.=E2=80=9D - Wilhelm Stekel

>

> _______________________________________________

> 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







------=_Part_753814_907414503.1413993871858--


From nobody Wed Oct 22 09:40:08 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 CF1751ACDAA for ; Wed, 22 Oct 2014 09:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UePE41jUX3K for ; Wed, 22 Oct 2014 09:40:02 -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 0CBD31ACDD2 for ; Wed, 22 Oct 2014 09:40:02 -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 s9MGdxuL010326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Oct 2014 16:40:00 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9MGdx4T011785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Oct 2014 16:39:59 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 s9MGdwvN011762; Wed, 22 Oct 2014 16:39:58 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Oct 2014 09:39:57 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2CB37B3-D2F5-4960-9E7F-0FBBDF62EBE7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 22 Oct 2014 09:39:56 -0700
Message-Id: <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com> 
To: Shelley 
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/Mm5jawwp4T8ZR2NkA-ufaN1RXSI
Cc: Alex Redston , "scim@ietf.org" 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 16:40:06 -0000

--Apple-Mail=_B2CB37B3-D2F5-4960-9E7F-0FBBDF62EBE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Shelley,

Thanks for your comments and bringing this to the groups attention.

Overall, I would like to strike a balance in favour of being flexible in =
what is accepted.  If the SP can understand the value, it may accept it. =
Further it may modify the value to conform to RFC3966 and return the =
modified value in the HTTP response. For example a service provider =
should feel free to correct something in telephone-subscriber format to =
be returned as a URI instead.
=97> maybe Postel=92s Law is one of the general principles of SCIM that =
we should make more clearer?

I think one of the problems with 3966 is that it seems quite broadly =
defined. Enforcement may be quite valid. But will it improve quality of =
information given the complication it will cause for clients (e.g. when =
a request fails due to format, what is the corrective action)?  Many =
service providers would rather accept the POST and simply ignore the =
value than to loose the transaction.

I agree we should adjust the language a bit. For example, are we =
expecting a telephone-uri or a telephone-subscriber as the value?  The =
spec is not clear. =20

There are also some other parts to 3966 which duplicate what we are =
doing in multi-valued attributes. For example the ABNF =93parameter=94 =
enables the following example:=20
  tel:7042;phone-context=3Dexample.com
In this case, =93phone-context=94 could be seen as duplicative of the =
function of =93type=94.

Maybe it is not only that we want to following RFC3966, but we actually =
want to fully specify how 3966 is mapped to phoneNumber=92s multi-valued =
JSON structure?

Phil

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



On Oct 22, 2014, at 8:41 AM, Shelley  wrote:

> I'd also like to clarify/highlight this problem/challenge with the =
current SCIM specification - the spec recommends that service providers =
canonicalize phone numbers to RFC 3966, yet, if there are no =
requirements for the data provided by the consumer, this may be =
impossible.
>=20
> In the extreme scenario, how can a SCIM SP canonicalize "not a phone =
number" to RFC 3966? In an incomplete scenario, how can an SP =
canonicalize "222-2222" without a country/area code? And in an ambiguous =
scenario, how can an SP canonicalize "201-5399 123" (where 123 is =
assumed to be an extension)?
>=20
> While it may be possible for the SP to canonicalize some values under =
some assumptions (e.g. country code may be assumed, and assumptions =
based on patterns, etc), it is still possible that the canonicalization =
would be incorrect and in some cases, impossible.
>=20
> How are other SPs handling this? Is anyone doing validation or =
canonicalization?=20
>=20
> Likewise, how are SCIM clients consuming phone numbers (especially =
those that may be read-only consumers of data and don't have =
visibility/control over the source data)? Is anyone doing any =
normalizing, validating, canonicalizing, or just leaving the data as-is =
regardless of the format/validity?
>=20
>=20
> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston =
 wrote:
> Thanks - interesting link.
> Alex Redston
>=20
> CEO
> Switch Identity Governance Ltd
> 07973 320 795
> 020 3434 3888
> On 22/10/2014 15:50, Shelley wrote:
>> The simplest approach would be to require SCIM consumers to provide =
phone numbers in the RFC 3966 format, which at least helps to guarantee =
the validity of the format and canonicalizes it into a standard global =
format consumable by both external systems and users. This also accounts =
for some of the scenarios you mentioned, such as sip calls.
>>=20
>> As far as validating whether the phone number is actually a =
potentially valid number (based on country, area code, etc.), this can =
be discussed further/separately as well. I agree that validating whether =
a phone number is actually in service is probably not feasible but there =
are some standards and libraries that could potentially be used to deter =
completely bogus numbers [1], but the value in this may be debatable.
>>=20
>> The overall problem is just that without centralized data validation =
in the service, SCIM consumers cannot rely on the syntax/validity of the =
data and therefore the burden of validating and normalizing falls to =
them.
>>=20
>> [1] https://code.google.com/p/libphonenumber/
>>=20
>>=20
>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston =
 wrote:
>> Of course the challenge here comes down to the extent to which that =
particular data can be standardised and validated. Taking phone numbers =
as the example you have sip calls, invalid numbers, country specific =
shortcodes, this is potentially a minefield.
>>=20
>> Well formed and valid values are two distinct concepts and with =
multiple carrier technologies the anatomy of simple +4412345678901 style =
numbers is no longer fit for purpose. For this reason I do not think =
that it is feasible for this particular data type to be rejected as bad =
data because the only way to know if a phone number is valid is to dial =
it.
>>=20
>> What do you think?
>>=20
>> Alex
>> Alex Redston
>>=20
>> CEO
>> Switch Identity Governance Ltd
>> 07973 320 795
>> 020 3434 3888
>> On 21/10/2014 20:36, Shelley wrote:
>>> The SCIM specification expects service providers should be able to =
canonicalize provided data into a common format (e.g. RFC 3966 for =
phoneNumbers), yet it does not explicitly describe input requirements or =
validation for attributes such as these. Is it expected that values that =
cannot accurately be canonicalized are rejected by the SCIM service or =
that the SCIM service accepts this invalid data and merely persists and =
returns this bad data to consumers?
>>>=20
>>> As a SCIM Service Provider, we are currently performing validation =
on attributes such as phoneNumbers and emails to ensure that they =
contain well-formed, valid values, and returning a 400 with a =
description of the error if validation fails. One of the benefits of =
SCIM is that data may come from multiple sources and may be consumed by =
multiple clients, and SCIM provides a repository of structured and =
well-formed data so that consumers can reliably derive meaning and use =
from this data. Without attribute validation and a guarantee of =
canonicalized values, this goal does not seem feasible and puts the =
burden on consumers to make sense of potentially invalid data.
>>>=20
>>> The downside to attribute validation is that it requires the SCIM =
consumers sending data to ensure valid data as well. As these consumers =
are closest to the source data, though, this seems like the most =
reasonable approach rather than putting the burden on the service =
provider and/or other SCIM consumers to make sense of the data. Aside =
from just "bad data" (e.g. sending "not a phone number" or "000-0000" =
for a phone number), for example, if the SCIM consumer sending source =
data sends phone numbers without area codes or sends only internal =
extensions, another SCIM consumer may not be able to make sense of this =
data. It seems reasonable to require the consumer sending the data to =
ensure that this data is well-formed and canonicalized/canonicalizable.
>>>=20
>>> A good example in the SCIM specification is the country attribute, =
which clearly indicates the attribute's requirements. A bad example is =
the phoneNumbers attribute, which doesn't describe the expected format =
to be provided by consumers, yet recommends that the service provider =
canonicalize the value even though the input may not be able to be =
canonicalized.
>>>=20
>>> I'd be interested in hearing others' opinions on this matter, and =
whether the SCIM specification should clarify further restrictions on =
attribute values.
>>=20
>>=20
>>=20
>>  =09
>> This email is free from viruses and malware because avast! Antivirus =
protection is active.=20
>>=20
>>=20
>>=20
>=20
>=20
>=20
>  =09
> This email is free from viruses and malware because avast! Antivirus =
protection is active. 		=09
>=20
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_B2CB37B3-D2F5-4960-9E7F-0FBBDF62EBE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Shelley,

Thanks for =
your comments and bringing this to the groups =
attention.

Overall, I would like to strike a balance =
in favour of being flexible in what is accepted.  If the SP can =
understand the value, it may accept it. Further it may modify the value =
to conform to RFC3966 and return the modified value in the HTTP =
response. For example a service =
provider should feel free to correct something in telephone-subscriber =
format to be returned as a URI instead.
=97> maybe =
Postel=92s Law is one of the general principles of SCIM that we should =
make more clearer?

I think one of the problems =
with 3966 is that it seems quite broadly defined. Enforcement may be =
quite valid. But will it improve quality of information given the =
complication it will cause for clients (e.g. when a request fails due to =
format, what is the corrective action)?  Many service providers =
would rather accept the POST and simply ignore the value than to loose =
the transaction.

I agree we should adjust =
the language a bit. For example, are we expecting a telephone-uri or a =
telephone-subscriber as the value?  The spec is not clear. =
 

There are also some other parts to 3966 =
which duplicate what we are doing in multi-valued attributes. For =
example the ABNF =93parameter=94 enables the following =
example: 
  tel:7042;phone-context=3Dexample.com
In this =
case, =93phone-context=94 could be seen as duplicative of the function =
of =93type=94.

Maybe it is not only that we =
want to following RFC3966, but we actually want to fully specify how =
3966 is mapped to phoneNumber=92s multi-valued JSON =
structure?

Phil

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






On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com> =
wrote:

I'd also like to =
clarify/highlight this problem/challenge with the current SCIM =
specification - the spec recommends that service providers canonicalize =
phone numbers to RFC 3966, yet, if there are no requirements for the =
data provided by the consumer, this may be impossible.

In the =
extreme scenario, how can a SCIM SP canonicalize "not a phone number" to =
RFC 3966? In an incomplete scenario, how can an SP canonicalize =
"222-2222" without a country/area code? And in an ambiguous scenario, =
how can an SP canonicalize "201-5399 123" (where 123 is assumed to be an =
extension)?

While it may be possible for the SP to =
canonicalize some values under some assumptions (e.g. =
country code may be assumed, and assumptions based on patterns, etc), it =
is still possible that the canonicalization would be incorrect and in =
some cases, impossible.

How are other SPs handling this? Is =
anyone doing validation or canonicalization? 

Likewise, how =
are SCIM clients consuming phone numbers (especially those that may be =
read-only consumers of data and don't have visibility/control over the =
source data)? Is anyone doing any normalizing, validating, =
canonicalizing, or just leaving the data as-is regardless of the =
format/validity?


On Wed, Oct 22, =
2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> =
wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial =
it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and emails
                            to ensure that they contain
                            well-formed, valid values, and returning a
                            400 with a description of the error if
                            validation fails. One of the benefits of
                            SCIM is that data may come from multiple
                            sources and may be consumed by multiple
                            clients, and SCIM provides a repository of
                            structured and well-formed data so that
                            consumers can reliably derive meaning and
                            use from this data. Without attribute
                            validation and a guarantee of canonicalized
                            values, this goal does not seem feasible and
                            puts the burden on consumers to make sense
                            of potentially invalid data.

                            

                            The downside to attribute validation is that
                            it requires the SCIM consumers sending data
                            to ensure valid data as well. As these
                            consumers are closest to the source data,
                            though, this seems like the most reasonable
                            approach rather than putting the burden on
                            the service provider and/or other SCIM
                            consumers to make sense of the data. Aside
                            from just "bad data" (e.g. sending "not a
                            phone number" or "000-0000" for a phone
                            number), for example, if the SCIM consumer
                            sending source data sends phone numbers
                            without area codes or sends only internal
                            extensions, another SCIM consumer may not be
                            able to make sense of this data. It seems
                            reasonable to require the consumer sending
                            the data to ensure that this data is
                            well-formed and
                            canonicalized/canonicalizable.

                            

                            A good example in the SCIM
                            specification is the country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opinions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                             =
 
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and =
malware because avast!=
 Antivirus protection is active.
			

				
	











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

=

--Apple-Mail=_B2CB37B3-D2F5-4960-9E7F-0FBBDF62EBE7--


From nobody Wed Oct 22 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 3D68E1ACE0C for ; Wed, 22 Oct 2014 09:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFVcrIgQbG5T for ; Wed, 22 Oct 2014 09:44:11 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF581ACDCC for ; Wed, 22 Oct 2014 09:44:11 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id x19so3278470ier.30 for ; Wed, 22 Oct 2014 09:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bbkPX5pvxkMKIu+l4sn2FdoEz1Nh/3/nhtsrC57a3xg=; b=dGA7+Br1IHlqeWfF/zKEJCaA+OYQZGCqIfTY7asQuTp7Aw1dgii4XVuQNCnGW78JMi bK6twIrxC3HpkqWP77aFa7FpLZPzjm1GPb3/vtx+vujUFRAzemK4iHrY6kp/jJCWgtqj aN0N90bwdz7TzR6PSm0uwlivoG6/k64wWaJzZ1AdIVh/eHVsNTQKu7fHcsz4k9PjfvkY LxEiCpTHWaOXa4Jk7jZ6hpT4Xb4Z9CWnSqQOt7Fn9QnhsIHoG0jFcTLfYJMtsq5fPaiT 68ciQiS07ab+LtRyVK4g98G+wiQ66ugXJnqIhEqdpzVIvDIjSo1PO2Zqb70MTNBHsYVm 1lFw==
MIME-Version: 1.0
X-Received: by 10.107.13.80 with SMTP id 77mr46524402ion.2.1413996250824; Wed, 22 Oct 2014 09:44:10 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Wed, 22 Oct 2014 09:44:10 -0700 (PDT)
In-Reply-To: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com> 
Date: Wed, 22 Oct 2014 11:44:10 -0500
Message-ID: 
From: Shelley 
To: Alex Redston , "scim@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1140a8c63e93f5050605a8a7
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/zkTW8YwXO-96rOP2iSAz8oZwghE
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 16:44:15 -0000

--001a1140a8c63e93f5050605a8a7
Content-Type: text/plain; charset=UTF-8

While I'd prefer to put more requirements on the data provided by SCIM
clients given all the aforementioned concerns, here is a potential
temporary mitigation/compromise
given the *current *state of the spec:

   - Strongly recommend SCIM clients provide data in specific formats (e.g.
   RFC3966 phone numbers)
   - SCIM SP performs no validation, accepts any values
   - SCIM SP attempts to canonicalize the value in the response
      - Use the "value" sub-attribute to return the raw value
      - Use the "display" sub-attribute to return the canonicalized value,
      if canonicalization is possible; otherwise, return the raw value

This helps limit the burden on SCIM consumers of the data, though they may
still have to deal with bad values and inconsistent formats. The use of the
display and value sub-attributes helps bring better visibility to cases
where the SP may have canonicalized a value using different assumptions.
(For example, if a country code is assumed, or in the case of "201-5399
123" where 123 is assumed to be an extension, but the SCIM SP assumes this
is a 10-digit phone number.)

Is this usage of the display and value sub-attributes consistent with the
intended usage in SCIM?

 "phoneNumbers": [
    {
      "value": "555-555-5555",
      "display": "tel:+1-555-555-5555",
      "type": "work"
    },
    {
      "value": "tel:+1-555-555-5555",
      "display": "tel:+1-555-555-5555",
      "type": "work"
    },
    {
      "value": "not a phone number",
      "display": "not a phone number",
      "type": "mobile"
    },
    {
      "value": "555-5555",
      "display": "555-5555",
      "type": "mobile"
    },
    {
      "value": "555-5555 123",
      "display": "tel:+1-555-555-5123",
      "type": "mobile"
    }
  ]

On Wed, Oct 22, 2014 at 10:41 AM, Shelley  wrote:

> I'd also like to clarify/highlight this problem/challenge with the current
> SCIM specification - the spec recommends that service providers
> canonicalize phone numbers to RFC 3966, yet, if there are no requirements
> for the data provided by the consumer, this may be impossible.
>
> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
> number" to RFC 3966? In an incomplete scenario, how can an SP canonicalize
> "222-2222" without a country/area code? And in an ambiguous scenario, how
> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
> extension)?
>
> While it may be possible for the SP to canonicalize *some *values under
> some *assumptions *(e.g. country code may be assumed, and assumptions
> based on patterns, etc), it is still possible that the canonicalization
> would be incorrect and in some cases, impossible.
>
> How are other SPs handling this? Is anyone doing validation or
> canonicalization?
>
> Likewise, how are SCIM clients consuming phone numbers (especially those
> that may be read-only consumers of data and don't have visibility/control
> over the source data)? Is anyone doing any normalizing, validating,
> canonicalizing, or just leaving the data as-is regardless of the
> format/validity?
>
>
> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
> aredston@switchresearch.com> wrote:
>
>>  Thanks - interesting link.
>>
>> Alex Redston
>>
>> CEO
>> Switch Identity Governance Ltd
>> 07973 320 795
>> 020 3434 3888
>>
>> On 22/10/2014 15:50, Shelley wrote:
>>
>>  The simplest approach would be to require SCIM consumers to provide
>> phone numbers in the RFC 3966 format, which at least helps to guarantee the
>> validity of the format and canonicalizes it into a standard global format
>> consumable by both external systems and users. This also accounts for some
>> of the scenarios you mentioned, such as sip calls.
>>
>>  As far as validating whether the phone number is actually a potentially
>> valid number (based on country, area code, etc.), this can be discussed
>> further/separately as well. I agree that validating whether a phone number
>> is actually in service is probably not feasible but there are some
>> standards and libraries that *could *potentially be used to deter
>> completely bogus numbers [1], but the value in this may be debatable.
>>
>>  The overall problem is just that without centralized data validation in
>> the service, SCIM consumers cannot rely on the syntax/validity of the data
>> and therefore the burden of validating and normalizing falls to them.
>>
>> [1] https://code.google.com/p/libphonenumber/
>>
>>
>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>> aredston@switchresearch.com> wrote:
>>
>>>  Of course the challenge here comes down to the extent to which that
>>> particular data can be standardised and validated. Taking phone numbers as
>>> the example you have sip calls, invalid numbers, country specific
>>> shortcodes, this is potentially a minefield.
>>>
>>> Well formed and valid values are two distinct concepts and with multiple
>>> carrier technologies the anatomy of simple +4412345678901 style numbers is
>>> no longer fit for purpose. For this reason I do not think that it is
>>> feasible for this particular data type to be rejected as bad data because
>>> the only way to know if a phone number is valid is to dial it.
>>>
>>> What do you think?
>>>
>>> Alex
>>>
>>> Alex Redston
>>>
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>>
>>>  On 21/10/2014 20:36, Shelley wrote:
>>>
>>>  The SCIM specification expects service providers should be able to
>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>> phoneNumbers), yet it does not explicitly describe input requirements
>>> or validation for attributes such as these.* Is it expected that values
>>> that cannot accurately be canonicalized are rejected by the SCIM service or
>>> that the SCIM service accepts this invalid data and merely persists and
>>> returns this bad data to consumers?*
>>>
>>> As a SCIM Service Provider, we are currently performing validation on
>>> attributes such as phoneNumbers and emails to ensure that they contain
>>> well-formed, valid values, and returning a 400 with a description of the
>>> error if validation fails. One of the benefits of SCIM is that data may
>>> come from multiple sources and may be consumed by multiple clients, and
>>> SCIM provides a repository of structured and well-formed data so that
>>> consumers can reliably derive meaning and use from this data. Without
>>> attribute validation and a guarantee of canonicalized values, this goal
>>> does not seem feasible and puts the burden on consumers to make sense of
>>> potentially invalid data.
>>>
>>> The downside to attribute validation is that it requires the SCIM
>>> consumers sending data to ensure valid data as well. As these consumers are
>>> closest to the source data, though, this seems like the most reasonable
>>> approach rather than putting the burden on the service provider and/or
>>> other SCIM consumers to make sense of the data. Aside from just "bad data"
>>> (e.g. sending "not a phone number" or "000-0000" for a phone number), for
>>> example, if the SCIM consumer sending source data sends phone numbers
>>> without area codes or sends only internal extensions, another SCIM consumer
>>> may not be able to make sense of this data. It seems reasonable to require
>>> the consumer sending the data to ensure that this data is well-formed and
>>> canonicalized/canonicalizable.
>>>
>>> A *good *example in the SCIM specification is the country attribute,
>>> which clearly indicates the attribute's requirements. A *bad *example
>>> is the phoneNumbers attribute, which doesn't describe the expected
>>> format to be provided by consumers, yet recommends that the service
>>> provider canonicalize the value even though the input may not be able to be
>>> canonicalized.
>>>
>>>  I'd be interested in hearing others' opinions on this matter, and
>>> whether the SCIM specification should clarify further restrictions on
>>> attribute values.
>>>
>>>
>>>
>>>
>>>  ------------------------------
>>>     
>>>
>>> This email is free from viruses and malware because avast! Antivirus
>>>  protection is active.
>>>
>>>
>>
>>
>>
>> ------------------------------
>>    
>>
>> This email is free from viruses and malware because avast! Antivirus
>>  protection is active.
>>
>>
>

--001a1140a8c63e93f5050605a8a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


While I'd prefer to put more requirements on the data =
provided by SCIM clients given all the aforementioned concerns, here is a p=
otential temporary mitigation/compromise given the current st=
ate of the spec:
  • Strongly recommend SCIM clients provide data in=
 specific formats (e.g. RFC3966 phone numbers)
  • SCIM SP performs no =
validation, accepts any values
  • SCIM SP attempts to canonicalize=
 the value in the response
    • Use the "value" sub-attribute to return the =
raw value
    • Use the "display" sub-attribute to return the canonicalized value=
, if canonicalization is possible; otherwise, return the raw value
      • =

This helps limit the burden on SCIM consumers of the data, tho=
ugh they may still have to deal with bad values and inconsistent formats. T=
he use of the display and value sub-=
attributes helps bring better visibility to cases where the SP may have can=
onicalized a value using different assumptions. (For example, if a country =
code is assumed, or  in the case of "201-5399 123" where 123 is a=
ssumed to be an extension, but the SCIM SP assumes this is a 10-digit phone=
 number.)
Is this usage of the display and value sub-attributes consistent with the intended usage in=
 SCIM?
=C2=A0"phoneNumbers": [
=C2=A0=C2=A0=C2=A0 {=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "value": "555-555-5555"=
,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "display": "tel:+1-555-5=
55-5555",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": "wo=
rk"
=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 "value": "tel:+1-555-555-5555",
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "display": "tel:+1-555-555-55=
55",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": "work&qu=
ot;
=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "value": "not a phone number",
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "display": "not a phone number"=
;,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": "mobile"=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "value": "555-5555",
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "display": "555-5555",
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 "type": "mobile"
=C2=A0=C2=A0=C2=A0 },
=
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "value": &=
quot;555-5555 123",
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "display": "tel:+1-555-555-5123",
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "type": "mobile"
=C2=A0=C2=A0=C2=A0 }
=C2=
=A0 ]

On Wed, Oct 22, 2014 at 10:41 AM, Shelley <randomshelley@gm=
ail.com> wrote:
I'd also like to clarify/highlight this problem/ch=
allenge with the current SCIM specification - the spec recommends that serv=
ice providers canonicalize phone numbers to RFC 3966, yet, if there are no =
requirements for the data provided by the consumer, this may be impossible.=


In the extreme scenario, how can a SCIM SP canonicalize "not a=
 phone number" to RFC 3966? In an incomplete scenario, how can an SP c=
anonicalize "222-2222" without a country/area code? And in an amb=
iguous scenario, how can an SP canonicalize "201-5399 123" (where=
 123 is assumed to be an extension)?

While it may be possible =
for the SP to canonicalize some values under some assumptions (e.g. country code may be assumed, and assumptions based on patterns, etc)=
, it is still possible that the canonicalization would be incorrect and in =
some cases, impossible.

How are other SPs handling this? Is an=
yone doing validation or canonicalization? 

Likewise, how are =
SCIM clients consuming phone numbers (especially those that may be read-onl=
y consumers of data and don't have visibility/control over the source d=
ata)? Is anyone doing any normalizing, validating, canonicalizing, or just =
leaving the data as-is regardless of the format/validity?

<=
br>
On Wed, Oct 22, 2014 at 10:05 AM, Alex Redsto=
n <aredston@switchresearch.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com><=
/span>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        
                          

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		
			

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	















--001a1140a8c63e93f5050605a8a7--


From nobody Wed Oct 22 10:22: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 B34BE1ACE7C for ; Wed, 22 Oct 2014 10:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 djjh_v1rKIku for ; Wed, 22 Oct 2014 10:22:36 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C702B1ACE77 for ; Wed, 22 Oct 2014 10:22:35 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so1333344igc.12 for ; Wed, 22 Oct 2014 10:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iZmaBvglC09/ztwfIVuisl9MFLYFuQejbN3LUdzHjlU=; b=TvuZcuGV4znzQZHMETLthGt/DXjWuM2jDuHTm6HLy4TBu7e/8mHAcb+1SMZYRt2Rq4 7R4yflmbZZBlKOnsynyYVp1yQLgCKxt4cuRo3PZSzXLzoOVMjwIcJ6P5P82KfY+J8739 6ghn3pTD4+HuR+CE8gbA7IADeGT+IpWDF5mX+YkQi0DvW0h84rPfrcAwQzCCDElC5GWv 4anIIIE6b3ip37Nqch9LSzRdLanx5rdk5BogGAy5HEq5mxhKb0Xmx66IsnOc7SkRIIQP mG+rQgg5dcbkI99kiaepVsxBPeLX5K2VPNT2bO+WzrWg5qLh46FV0OcCkZlPcy6pAYdx tMnQ==
MIME-Version: 1.0
X-Received: by 10.107.162.16 with SMTP id l16mr4661520ioe.54.1413998555114; Wed, 22 Oct 2014 10:22:35 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Wed, 22 Oct 2014 10:22:35 -0700 (PDT)
In-Reply-To: <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>
Date: Wed, 22 Oct 2014 12:22:35 -0500
Message-ID: 
From: Shelley 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a1140a1b497332005060631e7
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/QIoCXF-e9oGr_MdfE3boT0z_fYw
Cc: Alex Redston , "scim@ietf.org" 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 17:22:40 -0000

--001a1140a1b497332005060631e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the response, Phil.

 If the SP can understand the value, it may accept it.
>

Right, but what values can/should SPs attempt to "understand" since these
aren't described in the spec? What assumptions, if any, can be made about
the format provided by consumers? Further, what happens if the SP doesn't
"accept" the value: 400 response? value is silently ignored? value is
stored, but not canonicalized?

Further it may modify the value to conform to RFC3966 and return the
> modified value in the HTTP response.


The problem here is that modifying the value is not always possible or may
be done incorrectly depending on the format provided by the consumer.

Many service providers would rather accept the POST and simply ignore the
> value than to loose the transaction.
>

Silently ignoring unknown values seems a bit dangerous as well. I agree
that the corrective action may be difficult to determine automatically if
the transaction fails fast, but at least it brings some form of visibility
to the problem.


On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  wrote:

> Shelley,
>
> Thanks for your comments and bringing this to the groups attention.
>
> Overall, I would like to strike a balance in favour of being flexible in
> what is accepted.  If the SP can understand the value, it may accept it.
> Further it may modify the value to conform to RFC3966 and return the
> modified value in the HTTP response. For example a service provider
> should feel free to correct something in telephone-subscriber format to b=
e
> returned as a URI instead.
> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles of=
 SCIM that we
> should make more clearer?
>
> I think one of the problems with 3966 is that it seems quite broadly
> defined. Enforcement may be quite valid. But will it improve quality of
> information given the complication it will cause for clients (e.g. when a
> request fails due to format, what is the corrective action)?  Many servic=
e
> providers would rather accept the POST and simply ignore the value than t=
o
> loose the transaction.
>
> I agree we should adjust the language a bit. For example, are we expectin=
g
> a telephone-uri or a telephone-subscriber as the value?  The spec is not
> clear.
>
> There are also some other parts to 3966 which duplicate what we are doing
> in multi-valued attributes. For example the ABNF =E2=80=9Cparameter=E2=80=
=9D enables the
> following example:
>   tel:7042;phone-context=3Dexample.com
> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplicativ=
e of the function
> of =E2=80=9Ctype=E2=80=9D.
>
> Maybe it is not only that we want to following RFC3966, but we actually
> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi-v=
alued JSON
> structure?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>
> I'd also like to clarify/highlight this problem/challenge with the curren=
t
> SCIM specification - the spec recommends that service providers
> canonicalize phone numbers to RFC 3966, yet, if there are no requirements
> for the data provided by the consumer, this may be impossible.
>
> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
> number" to RFC 3966? In an incomplete scenario, how can an SP canonicaliz=
e
> "222-2222" without a country/area code? And in an ambiguous scenario, how
> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
> extension)?
>
> While it may be possible for the SP to canonicalize *some *values under
> some *assumptions *(e.g. country code may be assumed, and assumptions
> based on patterns, etc), it is still possible that the canonicalization
> would be incorrect and in some cases, impossible.
>
> How are other SPs handling this? Is anyone doing validation or
> canonicalization?
>
> Likewise, how are SCIM clients consuming phone numbers (especially those
> that may be read-only consumers of data and don't have visibility/control
> over the source data)? Is anyone doing any normalizing, validating,
> canonicalizing, or just leaving the data as-is regardless of the
> format/validity?
>
>
> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
> aredston@switchresearch.com> wrote:
>
>>  Thanks - interesting link.
>>
>> Alex Redston
>>
>> CEO
>> Switch Identity Governance Ltd
>> 07973 320 795
>> 020 3434 3888
>>
>> On 22/10/2014 15:50, Shelley wrote:
>>
>>  The simplest approach would be to require SCIM consumers to provide
>> phone numbers in the RFC 3966 format, which at least helps to guarantee =
the
>> validity of the format and canonicalizes it into a standard global forma=
t
>> consumable by both external systems and users. This also accounts for so=
me
>> of the scenarios you mentioned, such as sip calls.
>>
>>  As far as validating whether the phone number is actually a potentially
>> valid number (based on country, area code, etc.), this can be discussed
>> further/separately as well. I agree that validating whether a phone numb=
er
>> is actually in service is probably not feasible but there are some
>> standards and libraries that *could *potentially be used to deter
>> completely bogus numbers [1], but the value in this may be debatable.
>>
>>  The overall problem is just that without centralized data validation in
>> the service, SCIM consumers cannot rely on the syntax/validity of the da=
ta
>> and therefore the burden of validating and normalizing falls to them.
>>
>> [1] https://code.google.com/p/libphonenumber/
>>
>>
>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>> aredston@switchresearch.com> wrote:
>>
>>>  Of course the challenge here comes down to the extent to which that
>>> particular data can be standardised and validated. Taking phone numbers=
 as
>>> the example you have sip calls, invalid numbers, country specific
>>> shortcodes, this is potentially a minefield.
>>>
>>> Well formed and valid values are two distinct concepts and with multipl=
e
>>> carrier technologies the anatomy of simple +4412345678901 style numbers=
 is
>>> no longer fit for purpose. For this reason I do not think that it is
>>> feasible for this particular data type to be rejected as bad data becau=
se
>>> the only way to know if a phone number is valid is to dial it.
>>>
>>> What do you think?
>>>
>>> Alex
>>>
>>> Alex Redston
>>>
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>>
>>>  On 21/10/2014 20:36, Shelley wrote:
>>>
>>>  The SCIM specification expects service providers should be able to
>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>> phoneNumbers), yet it does not explicitly describe input requirements
>>> or validation for attributes such as these.* Is it expected that values
>>> that cannot accurately be canonicalized are rejected by the SCIM servic=
e or
>>> that the SCIM service accepts this invalid data and merely persists and
>>> returns this bad data to consumers?*
>>>
>>> As a SCIM Service Provider, we are currently performing validation on
>>> attributes such as phoneNumbers and emails to ensure that they contain
>>> well-formed, valid values, and returning a 400 with a description of th=
e
>>> error if validation fails. One of the benefits of SCIM is that data may
>>> come from multiple sources and may be consumed by multiple clients, and
>>> SCIM provides a repository of structured and well-formed data so that
>>> consumers can reliably derive meaning and use from this data. Without
>>> attribute validation and a guarantee of canonicalized values, this goal
>>> does not seem feasible and puts the burden on consumers to make sense o=
f
>>> potentially invalid data.
>>>
>>> The downside to attribute validation is that it requires the SCIM
>>> consumers sending data to ensure valid data as well. As these consumers=
 are
>>> closest to the source data, though, this seems like the most reasonable
>>> approach rather than putting the burden on the service provider and/or
>>> other SCIM consumers to make sense of the data. Aside from just "bad da=
ta"
>>> (e.g. sending "not a phone number" or "000-0000" for a phone number), f=
or
>>> example, if the SCIM consumer sending source data sends phone numbers
>>> without area codes or sends only internal extensions, another SCIM cons=
umer
>>> may not be able to make sense of this data. It seems reasonable to requ=
ire
>>> the consumer sending the data to ensure that this data is well-formed a=
nd
>>> canonicalized/canonicalizable.
>>>
>>> A *good *example in the SCIM specification is the country attribute,
>>> which clearly indicates the attribute's requirements. A *bad *example
>>> is the phoneNumbers attribute, which doesn't describe the expected
>>> format to be provided by consumers, yet recommends that the service
>>> provider canonicalize the value even though the input may not be able t=
o be
>>> canonicalized.
>>>
>>>  I'd be interested in hearing others' opinions on this matter, and
>>> whether the SCIM specification should clarify further restrictions on
>>> attribute values.
>>>
>>>
>>>
>>>
>>>  ------------------------------
>>>     
>>>
>>> This email is free from viruses and malware because avast! Antivirus
>>>  protection is active.
>>>
>>>
>>
>>
>>
>> ------------------------------
>>    
>>
>> This email is free from viruses and malware because avast! Antivirus
>>  protection is active.
>>
>>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>
>

--001a1140a1b497332005060631e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the response, Phil.

=C2=A0If the SP can understand the value=
, it may accept it.

Right, but what values can/sh=
ould SPs attempt to "understand" since these aren't described=
 in the spec? What assumptions, if any, can be made about the format provid=
ed by consumers? Further, what happens if the SP doesn't "accept&q=
uot; the value: 400 response? value is silently ignored? value is stored, b=
ut not canonicalized?

Further it may modify the value to conform to RFC3966 and return t=
he modified value in the HTTP response.

The=
 problem here is that modifying the value is not always possible or may be =
done incorrectly depending on the format provided by the consumer.

<=
blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex" class=3D"gmail_quote">Many service providers wou=
ld rather accept the POST and simply ignore the value than to loose the tra=
nsaction.

Silently ignoring unknown values s=
eems a bit dangerous as well. I agree that the corrective action may be dif=
ficult to determine automatically if the transaction fails fast, but at lea=
st it brings some form of visibility to the problem.
=C2=A0

On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Shelley,

Thanks for your comme=
nts and bringing this to the groups attention.

Overall,=
 I would like to strike a balance in favour of being flexible in what is ac=
cepted.=C2=A0 If the SP can understand the value, it may accept it. Further=
 it may modify the value to conform to RFC3966 and return the modified valu=
e in the HTTP response. For example a service provider should feel fr=
ee to correct something in telephone-subscriber format to be returned as a =
URI instead.
=E2=80=94> maybe Postel=E2=80=99s Law is one of =
the general principles of SCIM that we should make more clearer?
I think one of the problems with 3966 is that it seems quite b=
roadly defined. Enforcement may be quite valid. But will it improve quality=
 of information given the complication it will cause for clients (e.g. when=
 a request fails due to format, what is the corrective action)?=C2=A0 Many =
service providers would rather accept the POST and simply ignore the value =
than to loose the transaction.



On Oct 22, 2014, at 8:41 AM, Shelley &=
lt;randomshell=
ey@gmail.com> wrote:

=

I'd also like to=
 clarify/highlight this problem/challenge with the current SCIM specificati=
on - the spec recommends that service providers canonicalize phone numbers =
to RFC 3966, yet, if there are no requirements for the data provided by the=
 consumer, this may be impossible.

In the extreme scenario, how can =
a SCIM SP canonicalize "not a phone number" to RFC 3966? In an in=
complete scenario, how can an SP canonicalize "222-2222" without =
a country/area code? And in an ambiguous scenario, how can an SP canonicali=
ze "201-5399 123" (where 123 is assumed to be an extension)?
<=
br>
While it may be possible for the SP to canonicalize some va=
lues under some assumptions (e.g. country code may be assumed, and a=
ssumptions based on patterns, etc), it is still possible that the canonical=
ization would be incorrect and in some cases, impossible.

How =
are other SPs handling this? Is anyone doing validation or canonicalization=
? 

Likewise, how are SCIM clients consuming phone numbers (esp=
ecially those that may be read-only consumers of data and don't have vi=
sibility/control over the source data)? Is anyone doing any normalizing, va=
lidating, canonicalizing, or just leaving the data as-is regardless of the =
format/validity?


On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com><=
/span>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	











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




--001a1140a1b497332005060631e7--


From nobody Wed Oct 22 10:37: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 C7C4B1ACE97 for ; Wed, 22 Oct 2014 10:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi0tPojQkIfo for ; Wed, 22 Oct 2014 10:37:10 -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 F03A61ACE9C for ; Wed, 22 Oct 2014 10:37:09 -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 s9MHb8Dn026688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Oct 2014 17:37:08 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 s9MHb7bl000422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 17:37:07 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 s9MHb7wB002720; Wed, 22 Oct 2014 17:37:07 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Oct 2014 10:37:06 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BCA6BD2-DD56-40C4-A9C7-0805A9F6DC13"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 22 Oct 2014 10:37:04 -0700
Message-Id: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com> 
To: Shelley 
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/YuFQt_ZTTxrl6Rnoj85GbFmaaa4
Cc: Alex Redston , "scim@ietf.org" 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 17:37:21 -0000

--Apple-Mail=_2BCA6BD2-DD56-40C4-A9C7-0805A9F6DC13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Shelley,

I think we are pretty much in agreement. Would you mind providing some =
new text for the definition of phoneNumbers?  I like where you are going =
with value vs. displayName etc.

It would be good to see how the group feels on a some new proposed text.

Thanks,

Phil

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



On Oct 22, 2014, at 10:22 AM, Shelley  wrote:

> Thanks for the response, Phil.
>=20
>  If the SP can understand the value, it may accept it.
>=20
> Right, but what values can/should SPs attempt to "understand" since =
these aren't described in the spec? What assumptions, if any, can be =
made about the format provided by consumers? Further, what happens if =
the SP doesn't "accept" the value: 400 response? value is silently =
ignored? value is stored, but not canonicalized?
>=20
> Further it may modify the value to conform to RFC3966 and return the =
modified value in the HTTP response.
>=20
> The problem here is that modifying the value is not always possible or =
may be done incorrectly depending on the format provided by the =
consumer.
>=20
> Many service providers would rather accept the POST and simply ignore =
the value than to loose the transaction.
>=20
> Silently ignoring unknown values seems a bit dangerous as well. I =
agree that the corrective action may be difficult to determine =
automatically if the transaction fails fast, but at least it brings some =
form of visibility to the problem.
> =20
>=20
> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  =
wrote:
> Shelley,
>=20
> Thanks for your comments and bringing this to the groups attention.
>=20
> Overall, I would like to strike a balance in favour of being flexible =
in what is accepted.  If the SP can understand the value, it may accept =
it. Further it may modify the value to conform to RFC3966 and return the =
modified value in the HTTP response. For example a service provider =
should feel free to correct something in telephone-subscriber format to =
be returned as a URI instead.
> =97> maybe Postel=92s Law is one of the general principles of SCIM =
that we should make more clearer?
>=20
> I think one of the problems with 3966 is that it seems quite broadly =
defined. Enforcement may be quite valid. But will it improve quality of =
information given the complication it will cause for clients (e.g. when =
a request fails due to format, what is the corrective action)?  Many =
service providers would rather accept the POST and simply ignore the =
value than to loose the transaction.
>=20
> I agree we should adjust the language a bit. For example, are we =
expecting a telephone-uri or a telephone-subscriber as the value?  The =
spec is not clear. =20
>=20
> There are also some other parts to 3966 which duplicate what we are =
doing in multi-valued attributes. For example the ABNF =93parameter=94 =
enables the following example:=20
>   tel:7042;phone-context=3Dexample.com
> In this case, =93phone-context=94 could be seen as duplicative of the =
function of =93type=94.
>=20
> Maybe it is not only that we want to following RFC3966, but we =
actually want to fully specify how 3966 is mapped to phoneNumber=92s =
multi-valued JSON structure?
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>=20
>> I'd also like to clarify/highlight this problem/challenge with the =
current SCIM specification - the spec recommends that service providers =
canonicalize phone numbers to RFC 3966, yet, if there are no =
requirements for the data provided by the consumer, this may be =
impossible.
>>=20
>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone =
number" to RFC 3966? In an incomplete scenario, how can an SP =
canonicalize "222-2222" without a country/area code? And in an ambiguous =
scenario, how can an SP canonicalize "201-5399 123" (where 123 is =
assumed to be an extension)?
>>=20
>> While it may be possible for the SP to canonicalize some values under =
some assumptions (e.g. country code may be assumed, and assumptions =
based on patterns, etc), it is still possible that the canonicalization =
would be incorrect and in some cases, impossible.
>>=20
>> How are other SPs handling this? Is anyone doing validation or =
canonicalization?=20
>>=20
>> Likewise, how are SCIM clients consuming phone numbers (especially =
those that may be read-only consumers of data and don't have =
visibility/control over the source data)? Is anyone doing any =
normalizing, validating, canonicalizing, or just leaving the data as-is =
regardless of the format/validity?
>>=20
>>=20
>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston =
 wrote:
>> Thanks - interesting link.
>> Alex Redston
>>=20
>> CEO
>> Switch Identity Governance Ltd
>> 07973 320 795
>> 020 3434 3888
>> On 22/10/2014 15:50, Shelley wrote:
>>> The simplest approach would be to require SCIM consumers to provide =
phone numbers in the RFC 3966 format, which at least helps to guarantee =
the validity of the format and canonicalizes it into a standard global =
format consumable by both external systems and users. This also accounts =
for some of the scenarios you mentioned, such as sip calls.
>>>=20
>>> As far as validating whether the phone number is actually a =
potentially valid number (based on country, area code, etc.), this can =
be discussed further/separately as well. I agree that validating whether =
a phone number is actually in service is probably not feasible but there =
are some standards and libraries that could potentially be used to deter =
completely bogus numbers [1], but the value in this may be debatable.
>>>=20
>>> The overall problem is just that without centralized data validation =
in the service, SCIM consumers cannot rely on the syntax/validity of the =
data and therefore the burden of validating and normalizing falls to =
them.
>>>=20
>>> [1] https://code.google.com/p/libphonenumber/
>>>=20
>>>=20
>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston =
 wrote:
>>> Of course the challenge here comes down to the extent to which that =
particular data can be standardised and validated. Taking phone numbers =
as the example you have sip calls, invalid numbers, country specific =
shortcodes, this is potentially a minefield.
>>>=20
>>> Well formed and valid values are two distinct concepts and with =
multiple carrier technologies the anatomy of simple +4412345678901 style =
numbers is no longer fit for purpose. For this reason I do not think =
that it is feasible for this particular data type to be rejected as bad =
data because the only way to know if a phone number is valid is to dial =
it.
>>>=20
>>> What do you think?
>>>=20
>>> Alex
>>> Alex Redston
>>>=20
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>> On 21/10/2014 20:36, Shelley wrote:
>>>> The SCIM specification expects service providers should be able to =
canonicalize provided data into a common format (e.g. RFC 3966 for =
phoneNumbers), yet it does not explicitly describe input requirements or =
validation for attributes such as these. Is it expected that values that =
cannot accurately be canonicalized are rejected by the SCIM service or =
that the SCIM service accepts this invalid data and merely persists and =
returns this bad data to consumers?
>>>>=20
>>>> As a SCIM Service Provider, we are currently performing validation =
on attributes such as phoneNumbers and emails to ensure that they =
contain well-formed, valid values, and returning a 400 with a =
description of the error if validation fails. One of the benefits of =
SCIM is that data may come from multiple sources and may be consumed by =
multiple clients, and SCIM provides a repository of structured and =
well-formed data so that consumers can reliably derive meaning and use =
from this data. Without attribute validation and a guarantee of =
canonicalized values, this goal does not seem feasible and puts the =
burden on consumers to make sense of potentially invalid data.
>>>>=20
>>>> The downside to attribute validation is that it requires the SCIM =
consumers sending data to ensure valid data as well. As these consumers =
are closest to the source data, though, this seems like the most =
reasonable approach rather than putting the burden on the service =
provider and/or other SCIM consumers to make sense of the data. Aside =
from just "bad data" (e.g. sending "not a phone number" or "000-0000" =
for a phone number), for example, if the SCIM consumer sending source =
data sends phone numbers without area codes or sends only internal =
extensions, another SCIM consumer may not be able to make sense of this =
data. It seems reasonable to require the consumer sending the data to =
ensure that this data is well-formed and canonicalized/canonicalizable.
>>>>=20
>>>> A good example in the SCIM specification is the country attribute, =
which clearly indicates the attribute's requirements. A bad example is =
the phoneNumbers attribute, which doesn't describe the expected format =
to be provided by consumers, yet recommends that the service provider =
canonicalize the value even though the input may not be able to be =
canonicalized.
>>>>=20
>>>> I'd be interested in hearing others' opinions on this matter, and =
whether the SCIM specification should clarify further restrictions on =
attribute values.
>>>=20
>>>=20
>>>=20
>>>  =09
>>> This email is free from viruses and malware because avast! Antivirus =
protection is active.=20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>>  =09
>> This email is free from viruses and malware because avast! Antivirus =
protection is active. 		=09
>>=20
>>=20
>>=20
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>=20
>=20


--Apple-Mail=_2BCA6BD2-DD56-40C4-A9C7-0805A9F6DC13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Shelley,

I think we are pretty =
much in agreement. Would you mind providing some new text for the =
definition of phoneNumbers?  I like where you are going with value =
vs. displayName etc.

It would be good to see =
how the group feels on a some new proposed =
text.

Thanks,





On Oct 22, 2014, at 10:22 AM, Shelley <randomshelley@gmail.com> =
wrote:

Thanks for the response, =
Phil.

 If the SP can understand the value, it may =
accept it.

Right, but what values can/should =
SPs attempt to "understand" since these aren't described in the spec? =
What assumptions, if any, can be made about the format provided by =
consumers? Further, what happens if the SP doesn't "accept" the value: =
400 response? value is silently ignored? value is stored, but not =
canonicalized?

Further it may modify the value to conform to =
RFC3966 and return the modified value in the HTTP =
response.

The problem here is that =
modifying the value is not always possible or may be done incorrectly =
depending on the format provided by the consumer.

Many service =
providers would rather accept the POST and simply ignore the value than =
to loose the transaction.

Silently =
ignoring unknown values seems a bit dangerous as well. I agree that the =
corrective action may be difficult to determine automatically if the =
transaction fails fast, but at least it brings some form of visibility =
to the problem.
 

On Wed, Oct 22, =
2014 at 11:39 AM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
Shelley,

Than=
ks for your comments and bringing this to the groups =
attention.

Overall, I would like to strike a balance =
in favour of being flexible in what is accepted.  If the SP can =
understand the value, it may accept it. Further it may modify the value =
to conform to RFC3966 and return the modified value in the HTTP =
response. For example a service provider should feel free to =
correct something in telephone-subscriber format to be returned as a URI =
instead.
=97> maybe Postel=92s Law is one of the general =
principles of SCIM that we should make more =
clearer?

I think one of the problems with 3966 is =
that it seems quite broadly defined. Enforcement may be quite valid. But =
will it improve quality of information given the complication it will =
cause for clients (e.g. when a request fails due to format, what is the =
corrective action)?  Many service providers would rather accept the =
POST and simply ignore the value than to loose the =
transaction.

I agree we should adjust the =
language a bit. For example, are we expecting a telephone-uri or a =
telephone-subscriber as the value?  The spec is not clear. =
 

There are also some other parts to 3966 =
which duplicate what we are doing in multi-valued attributes. For =
example the ABNF =93parameter=94 enables the following =
example: 
  tel:704=
2;phone-context=3Dexample.com
In this case, =
=93phone-context=94 could be seen as duplicative of the function of =
=93type=94.

Maybe it is not only that we want =
to following RFC3966, but we actually want to fully specify how 3966 is =
mapped to phoneNumber=92s multi-valued JSON =
structure?

Phil

@in=
dependentid
phil.hunt@oracle.com

=






On Oct 22, 2014, at 8:41 AM, =
Shelley <randomshelley@gmail.com> =
wrote:

I'd also like to =
clarify/highlight this problem/challenge with the current SCIM =
specification - the spec recommends that service providers canonicalize =
phone numbers to RFC 3966, yet, if there are no requirements for the =
data provided by the consumer, this may be impossible.

In the =
extreme scenario, how can a SCIM SP canonicalize "not a phone number" to =
RFC 3966? In an incomplete scenario, how can an SP canonicalize =
"222-2222" without a country/area code? And in an ambiguous scenario, =
how can an SP canonicalize "201-5399 123" (where 123 is assumed to be an =
extension)?

While it may be possible for the SP to =
canonicalize some values under some assumptions (e.g. =
country code may be assumed, and assumptions based on patterns, etc), it =
is still possible that the canonicalization would be incorrect and in =
some cases, impossible.

How are other SPs handling this? Is =
anyone doing validation or canonicalization? 

Likewise, how =
are SCIM clients consuming phone numbers (especially those that may be =
read-only consumers of data and don't have visibility/control over the =
source data)? Is anyone doing any normalizing, validating, =
canonicalizing, or just leaving the data as-is regardless of the =
format/validity?


On Wed, Oct 22, =
2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> =
wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial =
it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and emails
                            to ensure that they contain
                            well-formed, valid values, and returning a
                            400 with a description of the error if
                            validation fails. One of the benefits of
                            SCIM is that data may come from multiple
                            sources and may be consumed by multiple
                            clients, and SCIM provides a repository of
                            structured and well-formed data so that
                            consumers can reliably derive meaning and
                            use from this data. Without attribute
                            validation and a guarantee of canonicalized
                            values, this goal does not seem feasible and
                            puts the burden on consumers to make sense
                            of potentially invalid data.

                            

                            The downside to attribute validation is that
                            it requires the SCIM consumers sending data
                            to ensure valid data as well. As these
                            consumers are closest to the source data,
                            though, this seems like the most reasonable
                            approach rather than putting the burden on
                            the service provider and/or other SCIM
                            consumers to make sense of the data. Aside
                            from just "bad data" (e.g. sending "not a
                            phone number" or "000-0000" for a phone
                            number), for example, if the SCIM consumer
                            sending source data sends phone numbers
                            without area codes or sends only internal
                            extensions, another SCIM consumer may not be
                            able to make sense of this data. It seems
                            reasonable to require the consumer sending
                            the data to ensure that this data is
                            well-formed and
                            canonicalized/canonicalizable.

                            

                            A good example in the SCIM
                            specification is the country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opinions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                             =
 
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and =
malware because avast!=
 Antivirus protection is active.
			

				
	











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





=

--Apple-Mail=_2BCA6BD2-DD56-40C4-A9C7-0805A9F6DC13--


From nobody Wed Oct 22 11:11: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 5F9191ACEA9 for ; Wed, 22 Oct 2014 11:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.267
X-Spam-Level: 
X-Spam-Status: No, score=-1.267 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, T_FILL_THIS_FORM_SHORT=0.01] 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 qgLPxFuYMcTd for ; Wed, 22 Oct 2014 11:11:36 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805821ACF14 for ; Wed, 22 Oct 2014 11:11:18 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id nt9so2033082obb.15 for ; Wed, 22 Oct 2014 11:11:18 -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=XzseXdGxW8a60/BKR4BIxZhgF4t5w0IOisHts0C+J5I=; b=b8xChH4Up76Ww3AOckNlb67aBB66ZikbgSUlCrn6tragWuEKi3JPdLZzpgsdlYu17M Vico/W1Y9FsZCBbrSiTncyFXDogdWaeKSXazn/jp5NGC8JTiIx2cKPvQEPmqJ4w+d5Fy KnPsIym9jt+uEVn7d64J356V/VJFSG9nlIv0iC3qOyyCTfwLUgU5dK0lMBgm6cWwzG9z Q/c1HLqNTjvI/qLuohKOiixy9CJAZ2oDnT33hGBLlQdRSzWGriS8dEmUkW9ESBtWJCqB /cO2CrJguKQiEZBkgNqKhZOggHU3f3KDwX4cpLuEYOGvI4HQGTpzI5HFhrNxpGHSWCu0 5FZw==
MIME-Version: 1.0
X-Received: by 10.182.33.67 with SMTP id p3mr16216105obi.15.1414001477974; Wed, 22 Oct 2014 11:11:17 -0700 (PDT)
Sender: grahameg@gmail.com
Received: by 10.60.39.232 with HTTP; Wed, 22 Oct 2014 11:11:17 -0700 (PDT)
In-Reply-To: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com> 
Date: Thu, 23 Oct 2014 05:11:17 +1100
X-Google-Sender-Auth: 8vW6o2PfoJxW-wD-DEIIQF9Sbfk
Message-ID: 
From: Grahame Grieve 
To: Shelley 
Content-Type: multipart/alternative; boundary=001a11c1e8d0ce8176050606df09
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/mHNF4yyWDlDs3GOModVlbpN4GVk
Cc: Alex Redston , "scim@ietf.org" , Phil Hunt 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 18:11:40 -0000

--001a11c1e8d0ce8176050606df09
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In healthcare, we defined some global standards that required all telephone
numbers to be in rfc3966 format

In practice, implementers have not conformed to this - they simply ignore
that part of the specification. Not only do they have vast amounts of
existing non-conformant data that they can't rectify automatically, there
is very little value in it - telephone numbers are almost exclusively used
by people to communicate with people, and conforming to rfc 3966 is
actually a negative value.

Yes, there are some limitations to this - systems that have integrated
pabxs have the load of doing the data validation on the fly. But if they're
using a telephone, they almost always have a person to mediate that process=
.

Mobile phone numbers, and email addresses, on the other hand, the use case
for valid data is extremely clear, and the validation is already generally
performed for this reason. So I suggest that a distinction be made in this
regard in the spec - through this is definitely a policy issue, not a
conformance one. Still, the use cases are sufficiently different that I
argue it's worth mentioning

Grahame


On Thursday, October 23, 2014, Shelley  wrote:

> Thanks for the response, Phil.
>
>  If the SP can understand the value, it may accept it.
>>
>
> Right, but what values can/should SPs attempt to "understand" since these
> aren't described in the spec? What assumptions, if any, can be made about
> the format provided by consumers? Further, what happens if the SP doesn't
> "accept" the value: 400 response? value is silently ignored? value is
> stored, but not canonicalized?
>
> Further it may modify the value to conform to RFC3966 and return the
>> modified value in the HTTP response.
>
>
> The problem here is that modifying the value is not always possible or ma=
y
> be done incorrectly depending on the format provided by the consumer.
>
> Many service providers would rather accept the POST and simply ignore the
>> value than to loose the transaction.
>>
>
> Silently ignoring unknown values seems a bit dangerous as well. I agree
> that the corrective action may be difficult to determine automatically if
> the transaction fails fast, but at least it brings some form of visibilit=
y
> to the problem.
>
>
> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  > wrote:
>
>> Shelley,
>>
>> Thanks for your comments and bringing this to the groups attention.
>>
>> Overall, I would like to strike a balance in favour of being flexible in
>> what is accepted.  If the SP can understand the value, it may accept it.
>> Further it may modify the value to conform to RFC3966 and return the
>> modified value in the HTTP response. For example a service provider
>> should feel free to correct something in telephone-subscriber format to =
be
>> returned as a URI instead.
>> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles o=
f SCIM that we
>> should make more clearer?
>>
>> I think one of the problems with 3966 is that it seems quite broadly
>> defined. Enforcement may be quite valid. But will it improve quality of
>> information given the complication it will cause for clients (e.g. when =
a
>> request fails due to format, what is the corrective action)?  Many servi=
ce
>> providers would rather accept the POST and simply ignore the value than =
to
>> loose the transaction.
>>
>> I agree we should adjust the language a bit. For example, are we
>> expecting a telephone-uri or a telephone-subscriber as the value?  The s=
pec
>> is not clear.
>>
>> There are also some other parts to 3966 which duplicate what we are doin=
g
>> in multi-valued attributes. For example the ABNF =E2=80=9Cparameter=E2=
=80=9D enables the
>> following example:
>>   tel:7042;phone-context=3Dexample.com
>> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplicati=
ve of the
>> function of =E2=80=9Ctype=E2=80=9D.
>>
>> Maybe it is not only that we want to following RFC3966, but we actually
>> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi-=
valued JSON
>> structure?
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>>
>>
>>
>> On Oct 22, 2014, at 8:41 AM, Shelley > > wrote:
>>
>> I'd also like to clarify/highlight this problem/challenge with the
>> current SCIM specification - the spec recommends that service providers
>> canonicalize phone numbers to RFC 3966, yet, if there are no requirement=
s
>> for the data provided by the consumer, this may be impossible.
>>
>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
>> number" to RFC 3966? In an incomplete scenario, how can an SP canonicali=
ze
>> "222-2222" without a country/area code? And in an ambiguous scenario, ho=
w
>> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
>> extension)?
>>
>> While it may be possible for the SP to canonicalize *some *values under
>> some *assumptions *(e.g. country code may be assumed, and assumptions
>> based on patterns, etc), it is still possible that the canonicalization
>> would be incorrect and in some cases, impossible.
>>
>> How are other SPs handling this? Is anyone doing validation or
>> canonicalization?
>>
>> Likewise, how are SCIM clients consuming phone numbers (especially those
>> that may be read-only consumers of data and don't have visibility/contro=
l
>> over the source data)? Is anyone doing any normalizing, validating,
>> canonicalizing, or just leaving the data as-is regardless of the
>> format/validity?
>>
>>
>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
>> aredston@switchresearch.com
>> > wrote:
>>
>>>  Thanks - interesting link.
>>>
>>> Alex Redston
>>>
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>>
>>> On 22/10/2014 15:50, Shelley wrote:
>>>
>>>  The simplest approach would be to require SCIM consumers to provide
>>> phone numbers in the RFC 3966 format, which at least helps to guarantee=
 the
>>> validity of the format and canonicalizes it into a standard global form=
at
>>> consumable by both external systems and users. This also accounts for s=
ome
>>> of the scenarios you mentioned, such as sip calls.
>>>
>>>  As far as validating whether the phone number is actually a
>>> potentially valid number (based on country, area code, etc.), this can =
be
>>> discussed further/separately as well. I agree that validating whether a
>>> phone number is actually in service is probably not feasible but there =
are
>>> some standards and libraries that *could *potentially be used to deter
>>> completely bogus numbers [1], but the value in this may be debatable.
>>>
>>>  The overall problem is just that without centralized data validation
>>> in the service, SCIM consumers cannot rely on the syntax/validity of th=
e
>>> data and therefore the burden of validating and normalizing falls to th=
em.
>>>
>>> [1] https://code.google.com/p/libphonenumber/
>>>
>>>
>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>>> aredston@switchresearch.com
>>> > wrote:
>>>
>>>>  Of course the challenge here comes down to the extent to which that
>>>> particular data can be standardised and validated. Taking phone number=
s as
>>>> the example you have sip calls, invalid numbers, country specific
>>>> shortcodes, this is potentially a minefield.
>>>>
>>>> Well formed and valid values are two distinct concepts and with
>>>> multiple carrier technologies the anatomy of simple +4412345678901 sty=
le
>>>> numbers is no longer fit for purpose. For this reason I do not think t=
hat
>>>> it is feasible for this particular data type to be rejected as bad dat=
a
>>>> because the only way to know if a phone number is valid is to dial it.
>>>>
>>>> What do you think?
>>>>
>>>> Alex
>>>>
>>>> Alex Redston
>>>>
>>>> CEO
>>>> Switch Identity Governance Ltd
>>>> 07973 320 795
>>>> 020 3434 3888
>>>>
>>>>  On 21/10/2014 20:36, Shelley wrote:
>>>>
>>>>  The SCIM specification expects service providers should be able to
>>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>>> phoneNumbers), yet it does not explicitly describe input requirements
>>>> or validation for attributes such as these.* Is it expected that
>>>> values that cannot accurately be canonicalized are rejected by the SCI=
M
>>>> service or that the SCIM service accepts this invalid data and merely
>>>> persists and returns this bad data to consumers?*
>>>>
>>>> As a SCIM Service Provider, we are currently performing validation on
>>>> attributes such as phoneNumbers and emails to ensure that they contain
>>>> well-formed, valid values, and returning a 400 with a description of t=
he
>>>> error if validation fails. One of the benefits of SCIM is that data ma=
y
>>>> come from multiple sources and may be consumed by multiple clients, an=
d
>>>> SCIM provides a repository of structured and well-formed data so that
>>>> consumers can reliably derive meaning and use from this data. Without
>>>> attribute validation and a guarantee of canonicalized values, this goa=
l
>>>> does not seem feasible and puts the burden on consumers to make sense =
of
>>>> potentially invalid data.
>>>>
>>>> The downside to attribute validation is that it requires the SCIM
>>>> consumers sending data to ensure valid data as well. As these consumer=
s are
>>>> closest to the source data, though, this seems like the most reasonabl=
e
>>>> approach rather than putting the burden on the service provider and/or
>>>> other SCIM consumers to make sense of the data. Aside from just "bad d=
ata"
>>>> (e.g. sending "not a phone number" or "000-0000" for a phone number), =
for
>>>> example, if the SCIM consumer sending source data sends phone numbers
>>>> without area codes or sends only internal extensions, another SCIM con=
sumer
>>>> may not be able to make sense of this data. It seems reasonable to req=
uire
>>>> the consumer sending the data to ensure that this data is well-formed =
and
>>>> canonicalized/canonicalizable.
>>>>
>>>> A *good *example in the SCIM specification is the country attribute,
>>>> which clearly indicates the attribute's requirements. A *bad *example
>>>> is the phoneNumbers attribute, which doesn't describe the expected
>>>> format to be provided by consumers, yet recommends that the service
>>>> provider canonicalize the value even though the input may not be able =
to be
>>>> canonicalized.
>>>>
>>>>  I'd be interested in hearing others' opinions on this matter, and
>>>> whether the SCIM specification should clarify further restrictions on
>>>> attribute values.
>>>>
>>>>
>>>>
>>>>
>>>>  ------------------------------
>>>>     
>>>>
>>>> This email is free from viruses and malware because avast! Antivirus
>>>>  protection is active.
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------
>>>    
>>>
>>> This email is free from viruses and malware because avast! Antivirus
>>>  protection is active.
>>>
>>>
>> _______________________________________________
>> 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

--001a11c1e8d0ce8176050606df09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In healthcare, we defined some global standards that required all telephone=
 numbers to be in rfc3966 format

In practice, implemente=
rs have not conformed to this - they simply ignore that part of the specifi=
cation. Not only do they have vast amounts of existing non-conformant data =
that they can't rectify automatically, there is very little value in it=
 - telephone numbers are almost exclusively used by people to communicate w=
ith people, and conforming to rfc 3966 is actually a negative value.
<=
div>
Yes, there are some limitations to this - systems that h=
ave integrated pabxs have the load of doing the data validation on the fly.=
 But if they're using a telephone, they almost always have a person to =
mediate that process.

Mobile phone numbers, and em=
ail addresses, on the other hand, the use case for valid data=C2=A0is extre=
mely clear, and the validation is already=C2=A0generally performed for this=
 reason. So I=C2=A0suggest that a distinction be made in this regard in the=
 spec=C2=A0- through this is definitely a policy issue, not a conformance o=
ne. Still, the use=C2=A0cases are sufficiently different that I argue it=
9;s worth mentioning

Grahame

<=
div>
On Thursday, October 23, 2014, Shelley <randomshelley@gmail.com> wrote:
Thanks for the response, Phil.
=C2=A0If the SP can und=
erstand the value, it may accept it.

Right, but w=
hat values can/should SPs attempt to "understand" since these are=
n't described in the spec? What assumptions, if any, can be made about =
the format provided by consumers? Further, what happens if the SP doesn'=
;t "accept" the value: 400 response? value is silently ignored? v=
alue is stored, but not canonicalized?

Further it may modify the value to conform to RFC=
3966 and return the modified value in the HTTP response.
<=
br>
The problem here is that modifying the value is not always po=
ssible or may be done incorrectly depending on the format provided by the c=
onsumer.

Many serv=
ice providers would rather accept the POST and simply ignore the value than=
 to loose the transaction.

Silently ignoring=
 unknown values seems a bit dangerous as well. I agree that the corrective =
action may be difficult to determine automatically if the transaction fails=
 fast, but at least it brings some form of visibility to the problem.
=C2=A0

On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt <phil.hunt@oracle.com> wr=
ote:
=

Shelley,

Thanks for your comments and bringin=
g this to the groups attention.

Overall, I would like t=
o strike a balance in favour of being flexible in what is accepted.=C2=A0 I=
f the SP can understand the value, it may accept it. Further it may modify =
the value to conform to RFC3966 and return the modified value in the HTTP r=
esponse. For example a service provider should feel free to correct s=
omething in telephone-subscriber format to be returned as a URI instead.
=E2=80=94> maybe Postel=E2=80=99s Law is one of the general pri=
nciples of SCIM that we should make more clearer?

I =
think one of the problems with 3966 is that it seems quite broadly defined.=
 Enforcement may be quite valid. But will it improve quality of information=
 given the complication it will cause for clients (e.g. when a request fail=
s due to format, what is the corrective action)?=C2=A0 Many service provide=
rs would rather accept the POST and simply ignore the value than to loose t=
he transaction.

<=
span style=3D"border-collapse:separate;color:rgb(0,0,0);font-family:Helveti=
ca;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;=
letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px;border-spacing:0px">
I agree we should adjust the language a bit. For ex=
ample, are we expecting a telephone-uri or a telephone-subscriber as the va=
lue?=C2=A0 The spec is not clear. =C2=A0

There are=
 also some other parts to 3966 which duplicate what we are doing in multi-v=
alued attributes. For example the ABNF =E2=80=9Cparameter=E2=80=9D enables =
the following example:=C2=A0
=C2=A0=C2=A0tel:7042;phone-context=3D<=
a href=3D"http://example.com" target=3D"_blank">example.com
In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplic=
ative of the function of =E2=80=9Ctype=E2=80=9D.

M=
aybe it is not only that we want to following RFC3966, but we actually want=
 to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi-valued =
JSON structure?

Phil

@independentid
phil.hunt@oracle.com
=







On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com> wrote:

I'=
;d also like to clarify/highlight this problem/challenge with the current S=
CIM specification - the spec recommends that service providers canonicalize=
 phone numbers to RFC 3966, yet, if there are no requirements for the data =
provided by the consumer, this may be impossible.

In the extreme sce=
nario, how can a SCIM SP canonicalize "not a phone number" to RFC=
 3966? In an incomplete scenario, how can an SP canonicalize "222-2222=
" without a country/area code? And in an ambiguous scenario, how can a=
n SP canonicalize "201-5399 123" (where 123 is assumed to be an e=
xtension)?

While it may be possible for the SP to canonicalize=
 some values under some assumptions (e.g. country code may be=
 assumed, and assumptions based on patterns, etc), it is still possible tha=
t the canonicalization would be incorrect and in some cases, impossible.
How are other SPs handling this? Is anyone doing validation or c=
anonicalization? 

Likewise, how are SCIM clients consuming pho=
ne numbers (especially those that may be read-only consumers of data and do=
n't have visibility/control over the source data)? Is anyone doing any =
normalizing, validating, canonicalizing, or just leaving the data as-is reg=
ardless of the format/validity?


On Wed, Oct 22, 2014 at 10:05 AM, Al=
ex Redston <aredston@sw=
itchresearch.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	











_______________________________________________
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


--001a11c1e8d0ce8176050606df09--


From nobody Wed Oct 22 12:14: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 5C2BC1AD050 for ; Wed, 22 Oct 2014 12:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 t17ByqaON_Kq for ; Wed, 22 Oct 2014 12:13:55 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8271AD018 for ; Wed, 22 Oct 2014 12:13:51 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id h18so56118igc.12 for ; Wed, 22 Oct 2014 12:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=387AJ9jpNdpJ8tmuArVJ/ecqcxvlXX2/C2HlzE4+eBM=; b=G+nGisqnfWgkrFf8arpbE+uwpUKR95h9pkPVsTm6xi0x68O26JxN2jJfNh6go1YM4R oScMGy8EboX5FUPy1ij/5hHlyanR3GCng7I4AHjD2wKDC3rGp3ZO5cBYx3tfKJguw/6S R/cWUnyBkYtnUPwNrko8DIywZdVDY9VovK0WP9wDmx3ENs/eCPou1/W7rHxSU/WVMPLF 4xgtxjYbyPn8aeC3RqLwJzQyN4iIBQ5gmbDD2TgbQJmWtb9WD6iAROnavP4vmhpEh0hQ rJ8XXQxUwL8TljVSxJqDkF8C7GUwFtsILh3GvDBDiglqlDiKVb/bCbCHtEv0sTib1cvT YcqA==
MIME-Version: 1.0
X-Received: by 10.107.13.80 with SMTP id 77mr230730ion.2.1414005230795; Wed, 22 Oct 2014 12:13:50 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Wed, 22 Oct 2014 12:13:50 -0700 (PDT)
In-Reply-To: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>  
Date: Wed, 22 Oct 2014 14:13:50 -0500
Message-ID: 
From: Shelley 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a1140a8c67e0341050607bfcf
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/4qX5Knok2JXOq4taok4uVdMMizU
Cc: Alex Redston , "scim@ietf.org" 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 19:14:09 -0000

--001a1140a8c67e0341050607bfcf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Before any specific text is proposed, I'd like to get a general
understanding for what the agreement/direction is. It seems there are still
some major open questions that I'd appreciate some input on.

   - Should consumers be required to provide values in specific formats?
      - For example, for phone numbers, must consumers provide RFC 3966
      format, an international format, any of multiple common/pre-defined
      formats, or is any value allowed? If not in RFC/international format,=
 is
      the country/area code assumed?
   - Should service providers perform attribute validation or accept any
   values?
      - If service providers perform validation, what is the expected
      behavior when validation fails? (400 / ignore the value / store the v=
alue
      as-is?)
   - Particularly if there are no requirements for data input and/or no
   validation is performed:
      - What are the assumptions that service providers can make during
      canonicalization?
      - What should service providers / consumers do if canonicalization is
      not possible?
      - Should the use of both the "value" and "display" attributes be
      recommended?

There are minimally two major variations of possible changes on the table,
with various flavors in between:

   - Require consumers to provide values in specified formats and SPs
   perform validation, rejecting invalid values
      - SCIM serves as a repository of well-formed, valid data. This
      results in the most usable data for SCIM consumers *reading *data,
      but puts some burden on SCIM consumers *providing *the data to
      conform.

*-OR-*

   - Allow consumers to provide values in any format, SP performs no
   validation though it may *attempt *perform canonicalization
   - SCIM serves as a repository of data from third parties, data may not
      be consistent, valid, or normalized. This results in the least effort=
 for
      SCIM consumers *providing *data, but puts some burden on SCIM
      consumers *reading *the data to make sense of the data.
      - SCIM SPs may *attempt *to normalize some of the data, but there may
      be no guarantees with respect to the consistency or accuracy of these
      normalizations.


On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt  wrote:

> Shelley,
>
> I think we are pretty much in agreement. Would you mind providing some ne=
w
> text for the definition of phoneNumbers?  I like where you are going with
> value vs. displayName etc.
>
> It would be good to see how the group feels on a some new proposed text.
>
> Thanks,
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
> On Oct 22, 2014, at 10:22 AM, Shelley  wrote:
>
> Thanks for the response, Phil.
>
>  If the SP can understand the value, it may accept it.
>>
>
> Right, but what values can/should SPs attempt to "understand" since these
> aren't described in the spec? What assumptions, if any, can be made about
> the format provided by consumers? Further, what happens if the SP doesn't
> "accept" the value: 400 response? value is silently ignored? value is
> stored, but not canonicalized?
>
> Further it may modify the value to conform to RFC3966 and return the
>> modified value in the HTTP response.
>
>
> The problem here is that modifying the value is not always possible or ma=
y
> be done incorrectly depending on the format provided by the consumer.
>
> Many service providers would rather accept the POST and simply ignore the
>> value than to loose the transaction.
>>
>
> Silently ignoring unknown values seems a bit dangerous as well. I agree
> that the corrective action may be difficult to determine automatically if
> the transaction fails fast, but at least it brings some form of visibilit=
y
> to the problem.
>
>
> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  wrote:
>
>> Shelley,
>>
>> Thanks for your comments and bringing this to the groups attention.
>>
>> Overall, I would like to strike a balance in favour of being flexible in
>> what is accepted.  If the SP can understand the value, it may accept it.
>> Further it may modify the value to conform to RFC3966 and return the
>> modified value in the HTTP response. For example a service provider
>> should feel free to correct something in telephone-subscriber format to =
be
>> returned as a URI instead.
>> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles o=
f SCIM that we
>> should make more clearer?
>>
>> I think one of the problems with 3966 is that it seems quite broadly
>> defined. Enforcement may be quite valid. But will it improve quality of
>> information given the complication it will cause for clients (e.g. when =
a
>> request fails due to format, what is the corrective action)?  Many servi=
ce
>> providers would rather accept the POST and simply ignore the value than =
to
>> loose the transaction.
>>
>> I agree we should adjust the language a bit. For example, are we
>> expecting a telephone-uri or a telephone-subscriber as the value?  The s=
pec
>> is not clear.
>>
>> There are also some other parts to 3966 which duplicate what we are doin=
g
>> in multi-valued attributes. For example the ABNF =E2=80=9Cparameter=E2=
=80=9D enables the
>> following example:
>>   tel:7042;phone-context=3Dexample.com
>> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplicati=
ve of the
>> function of =E2=80=9Ctype=E2=80=9D.
>>
>> Maybe it is not only that we want to following RFC3966, but we actually
>> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi-=
valued JSON
>> structure?
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>
>>
>>
>> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>>
>> I'd also like to clarify/highlight this problem/challenge with the
>> current SCIM specification - the spec recommends that service providers
>> canonicalize phone numbers to RFC 3966, yet, if there are no requirement=
s
>> for the data provided by the consumer, this may be impossible.
>>
>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
>> number" to RFC 3966? In an incomplete scenario, how can an SP canonicali=
ze
>> "222-2222" without a country/area code? And in an ambiguous scenario, ho=
w
>> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
>> extension)?
>>
>> While it may be possible for the SP to canonicalize *some *values under
>> some *assumptions *(e.g. country code may be assumed, and assumptions
>> based on patterns, etc), it is still possible that the canonicalization
>> would be incorrect and in some cases, impossible.
>>
>> How are other SPs handling this? Is anyone doing validation or
>> canonicalization?
>>
>> Likewise, how are SCIM clients consuming phone numbers (especially those
>> that may be read-only consumers of data and don't have visibility/contro=
l
>> over the source data)? Is anyone doing any normalizing, validating,
>> canonicalizing, or just leaving the data as-is regardless of the
>> format/validity?
>>
>>
>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
>> aredston@switchresearch.com> wrote:
>>
>>>  Thanks - interesting link.
>>>
>>> Alex Redston
>>>
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>>
>>> On 22/10/2014 15:50, Shelley wrote:
>>>
>>>  The simplest approach would be to require SCIM consumers to provide
>>> phone numbers in the RFC 3966 format, which at least helps to guarantee=
 the
>>> validity of the format and canonicalizes it into a standard global form=
at
>>> consumable by both external systems and users. This also accounts for s=
ome
>>> of the scenarios you mentioned, such as sip calls.
>>>
>>>  As far as validating whether the phone number is actually a
>>> potentially valid number (based on country, area code, etc.), this can =
be
>>> discussed further/separately as well. I agree that validating whether a
>>> phone number is actually in service is probably not feasible but there =
are
>>> some standards and libraries that *could *potentially be used to deter
>>> completely bogus numbers [1], but the value in this may be debatable.
>>>
>>>  The overall problem is just that without centralized data validation
>>> in the service, SCIM consumers cannot rely on the syntax/validity of th=
e
>>> data and therefore the burden of validating and normalizing falls to th=
em.
>>>
>>> [1] https://code.google.com/p/libphonenumber/
>>>
>>>
>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>>> aredston@switchresearch.com> wrote:
>>>
>>>>  Of course the challenge here comes down to the extent to which that
>>>> particular data can be standardised and validated. Taking phone number=
s as
>>>> the example you have sip calls, invalid numbers, country specific
>>>> shortcodes, this is potentially a minefield.
>>>>
>>>> Well formed and valid values are two distinct concepts and with
>>>> multiple carrier technologies the anatomy of simple +4412345678901 sty=
le
>>>> numbers is no longer fit for purpose. For this reason I do not think t=
hat
>>>> it is feasible for this particular data type to be rejected as bad dat=
a
>>>> because the only way to know if a phone number is valid is to dial it.
>>>>
>>>> What do you think?
>>>>
>>>> Alex
>>>>
>>>> Alex Redston
>>>>
>>>> CEO
>>>> Switch Identity Governance Ltd
>>>> 07973 320 795
>>>> 020 3434 3888
>>>>
>>>>  On 21/10/2014 20:36, Shelley wrote:
>>>>
>>>>  The SCIM specification expects service providers should be able to
>>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>>> phoneNumbers), yet it does not explicitly describe input requirements
>>>> or validation for attributes such as these.* Is it expected that
>>>> values that cannot accurately be canonicalized are rejected by the SCI=
M
>>>> service or that the SCIM service accepts this invalid data and merely
>>>> persists and returns this bad data to consumers?*
>>>>
>>>> As a SCIM Service Provider, we are currently performing validation on
>>>> attributes such as phoneNumbers and emails to ensure that they contain
>>>> well-formed, valid values, and returning a 400 with a description of t=
he
>>>> error if validation fails. One of the benefits of SCIM is that data ma=
y
>>>> come from multiple sources and may be consumed by multiple clients, an=
d
>>>> SCIM provides a repository of structured and well-formed data so that
>>>> consumers can reliably derive meaning and use from this data. Without
>>>> attribute validation and a guarantee of canonicalized values, this goa=
l
>>>> does not seem feasible and puts the burden on consumers to make sense =
of
>>>> potentially invalid data.
>>>>
>>>> The downside to attribute validation is that it requires the SCIM
>>>> consumers sending data to ensure valid data as well. As these consumer=
s are
>>>> closest to the source data, though, this seems like the most reasonabl=
e
>>>> approach rather than putting the burden on the service provider and/or
>>>> other SCIM consumers to make sense of the data. Aside from just "bad d=
ata"
>>>> (e.g. sending "not a phone number" or "000-0000" for a phone number), =
for
>>>> example, if the SCIM consumer sending source data sends phone numbers
>>>> without area codes or sends only internal extensions, another SCIM con=
sumer
>>>> may not be able to make sense of this data. It seems reasonable to req=
uire
>>>> the consumer sending the data to ensure that this data is well-formed =
and
>>>> canonicalized/canonicalizable.
>>>>
>>>> A *good *example in the SCIM specification is the country attribute,
>>>> which clearly indicates the attribute's requirements. A *bad *example
>>>> is the phoneNumbers attribute, which doesn't describe the expected
>>>> format to be provided by consumers, yet recommends that the service
>>>> provider canonicalize the value even though the input may not be able =
to be
>>>> canonicalized.
>>>>
>>>>  I'd be interested in hearing others' opinions on this matter, and
>>>> whether the SCIM specification should clarify further restrictions on
>>>> attribute values.
>>>>
>>>>
>>>>
>>>>
>>>>  ------------------------------
>>>>     
>>>>
>>>> This email is free from viruses and malware because avast! Antivirus
>>>>  protection is active.
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------
>>>    
>>>
>>> This email is free from viruses and malware because avast! Antivirus
>>>  protection is active.
>>>
>>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>
>

--001a1140a8c67e0341050607bfcf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Before any specific text is proposed, I'd like to get =
a general understanding for what the agreement/direction is. It seems there=
 are still some major open questions that I'd appreciate some input on.=

  • Should consumers be required to provide values in specific form=
ats?
    • For example, for phone numbers, must consumers provide RFC=
 3966 format, an international format, any of multiple common/pre-defined f=
ormats, or is any value allowed? If not in RFC/international format, is the=
 country/area code assumed?
  • Should service providers perform a=
ttribute validation or accept any values?
    • If service providers =
perform validation, what is the expected behavior when validation fails? (4=
00 / ignore the value / store the value as-is?)
  • Particularly i=
f there are no requirements for data input and/or no validation is performe=
d:
    • What are the assumptions that service providers can make dur=
ing canonicalization?
    • What should service providers / consumers do =
if canonicalization is not possible?
    • Should the use of both the &qu=
ot;value" and "display" attributes be recommended?
    =

There are minimally two major variations of possible changes on the=
 table, with various flavors in between:
  • Require consumers to pr=
ovide values in specified formats and SPs perform validation, rejecting inv=
alid values
    • SCIM serves as a repository of well-formed, valid d=
ata. This results in the most usable data for SCIM consumers reading data, but puts some burden on SCIM consumers providing the data to =
conform.
-OR-
<=
/div>
  • Allow consumers to provide values in any format, SP performs n=
o validation though it may attempt perform canonicalization
    • =

    • SCIM serves as a repository of data from third parties, data may no=
t be consistent, valid, or normalized. This results in the least effort for=
 SCIM consumers providing data, but puts some burden on SCIM consume=
rs reading the data to make sense of the data.
    • SCIM SPs may =
attempt to normalize some of the data, but there may be no guarantee=
s with respect to the consistency or accuracy of these normalizations.
      <=
/li>

On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Shelley,

I think we are pretty much in ag=
reement. Would you mind providing some new text for the definition of phone=
Numbers?=C2=A0 I like where you are going with value vs. displayName etc.

It would be good to see how the group feels on a so=
me new proposed text.

Thanks,





On Oct 22, 2014, at 10:22 AM, Shelley <randomshelley@gmail.com> w=
rote:

Thanks for t=
he response, Phil.

=C2=A0If the SP can understand the value, it may accept it.

Right, but what values can/should SPs attempt to "understa=
nd" since these aren't described in the spec? What assumptions, if=
 any, can be made about the format provided by consumers? Further, what hap=
pens if the SP doesn't "accept" the value: 400 response? valu=
e is silently ignored? value is stored, but not canonicalized?

=

Further it may modify the=
 value to conform to RFC3966 and return the modified value in the HTTP resp=
onse.

The problem here is that modifying th=
e value is not always possible or may be done incorrectly depending on the =
format provided by the consumer.

Many service providers would rather accept the POST and si=
mply ignore the value than to loose the transaction.

Silently ignoring unknown values seems a bit dangerous as well. I =
agree that the corrective action may be difficult to determine automaticall=
y if the transaction fails fast, but at least it brings some form of visibi=
lity to the problem.
=C2=A0

On Wed, Oct 22, 2014 at 11:=
39 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Shelley,

Thanks for your comments and bringing this to the g=
roups attention.

Overall, I would like to strike a bala=
nce in favour of being flexible in what is accepted.=C2=A0 If the SP can un=
derstand the value, it may accept it. Further it may modify the value to co=
nform to RFC3966 and return the modified value in the HTTP response. For example a service provider should feel free to correct something in tel=
ephone-subscriber format to be returned as a URI instead.
=E2=80=
=94> maybe Postel=E2=80=99s Law is one of the general principles of SCIM=
 that we should make more clearer?

I think one of th=
e problems with 3966 is that it seems quite broadly defined. Enforcement ma=
y be quite valid. But will it improve quality of information given the comp=
lication it will cause for clients (e.g. when a request fails due to format=
, what is the corrective action)?=C2=A0 Many service providers would rather=
 accept the POST and simply ignore the value than to loose the transaction.=


I agree we should adjust the languag=
e a bit. For example, are we expecting a telephone-uri or a telephone-subsc=
riber as the value?=C2=A0 The spec is not clear. =C2=A0

There are also some other parts to 3966 which duplicate what we are d=
oing in multi-valued attributes. For example the ABNF =E2=80=9Cparameter=E2=
=80=9D enables the following example:=C2=A0
=C2=A0=C2=A0tel:7042;ph=
one-context=3Dexample.com=

In this case, =E2=80=9Cphone-context=E2=80=9D could b=
e seen as duplicative of the function of =E2=80=9Ctype=E2=80=9D.
=

Maybe it is not only that we want to following RFC3966, but =
we actually want to fully specify how 3966 is mapped to phoneNumber=E2=80=
=99s multi-valued JSON structure?

Phil

@independentid=

phil.hunt@oracle.com

=






On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com<=
/a>> wrote:

I'd also like to clarify/highlight this pr=
oblem/challenge with the current SCIM specification - the spec recommends t=
hat service providers canonicalize phone numbers to RFC 3966, yet, if there=
 are no requirements for the data provided by the consumer, this may be imp=
ossible.

In the extreme scenario, how can a SCIM SP canonicalize &qu=
ot;not a phone number" to RFC 3966? In an incomplete scenario, how can=
 an SP canonicalize "222-2222" without a country/area code? And i=
n an ambiguous scenario, how can an SP canonicalize "201-5399 123"=
; (where 123 is assumed to be an extension)?

While it may be p=
ossible for the SP to canonicalize some values under some assumpt=
ions (e.g. country code may be assumed, and assumptions based on patter=
ns, etc), it is still possible that the canonicalization would be incorrect=
 and in some cases, impossible.

How are other SPs handling thi=
s? Is anyone doing validation or canonicalization? 

Likewise, =
how are SCIM clients consuming phone numbers (especially those that may be =
read-only consumers of data and don't have visibility/control over the =
source data)? Is anyone doing any normalizing, validating, canonicalizing, =
or just leaving the data as-is regardless of the format/validity?
<=
br>

On=
 Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <aredston@switchre=
search.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com><=
/span>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	











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








--001a1140a8c67e0341050607bfcf--


From nobody Wed Oct 22 12:16:03 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 BE9661AD0F0 for ; Wed, 22 Oct 2014 12:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1yOnmnklc3E for ; Wed, 22 Oct 2014 12:15:47 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD171ACF8B for ; Wed, 22 Oct 2014 12:14:57 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id at20so4212046iec.11 for ; Wed, 22 Oct 2014 12:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+uOvBpIiIANA6VIfJ1UXcXYTcd+Om9JSPS4364rvtpA=; b=XEyaQlQAsgzNQMhcVRXM5N4qyemIB2TXL3z9lvDRUOG39rlUUNTCjgdQyRSXIg0b0B Uhr0AGnv0NA7HD9gxQwefFKb/MH/5XuuU3pSBp/Q/rWX09mOb23J4ogh8aJ+82Ee4zRU g9VTnqCxZ4IURFEnEcjmsLWP6QNiE3sHBxNa0LVFFW7bZaNgbuUR213QM6PFX/3TW+Ea BAkGE0DWNlKNPvSwleDbSP6YczyYvRXxeHV5qGtd9SfoeNCS+LqymLh6xByiZoUsXq9l tRpi65e8744s2cVRRDJmX4TYb2+CNaMb6Q48FkE1vCAWDjxc/OSWEh418C8zNM7MSRKD oVsA==
MIME-Version: 1.0
X-Received: by 10.107.37.15 with SMTP id l15mr181995iol.40.1414005296744; Wed, 22 Oct 2014 12:14:56 -0700 (PDT)
Received: by 10.64.120.225 with HTTP; Wed, 22 Oct 2014 12:14:56 -0700 (PDT)
In-Reply-To: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>  
Date: Wed, 22 Oct 2014 14:14:56 -0500
Message-ID: 
From: Shelley 
To: Grahame Grieve 
Content-Type: multipart/alternative; boundary=001a11402fbc6c5b81050607c3b5
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/2kn-zmN_N4fHFS_L4DAXWpPNdE0
Cc: Alex Redston , "scim@ietf.org" , Phil Hunt 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 19:16:01 -0000

--001a11402fbc6c5b81050607c3b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for your input, Grahame. To clarify, it sounds like you are in favor
of the following SCIM SP behavior? Please correct me if I've misunderstood.

   - Performing validation on email addresses
   - Performing validation on mobile phone numbers
   - Not performing validation on other phone numbers
   - Not canonicalizing phone numbers??

Are you currently implementing this approach in a SCIM implementation? If
you are in favor of performing validation on mobile numbers, would you
recommend/require the use of a certain format? What happens when validation
fails?

Personally, I don't know that we should be differentiating required formats
or validation based on the attribute "type" (i.e. treating mobile numbers
differently than other numbers). The use cases for these may often be the
same, and further, some numbers may not even specify a type, so drawing a
line here would be ambiguous.

On Wed, Oct 22, 2014 at 1:11 PM, Grahame Grieve <
grahame@healthintersections.com.au> wrote:

> In healthcare, we defined some global standards that required all
> telephone numbers to be in rfc3966 format
>
> In practice, implementers have not conformed to this - they simply ignore
> that part of the specification. Not only do they have vast amounts of
> existing non-conformant data that they can't rectify automatically, there
> is very little value in it - telephone numbers are almost exclusively use=
d
> by people to communicate with people, and conforming to rfc 3966 is
> actually a negative value.
>
> Yes, there are some limitations to this - systems that have integrated
> pabxs have the load of doing the data validation on the fly. But if they'=
re
> using a telephone, they almost always have a person to mediate that proce=
ss.
>
> Mobile phone numbers, and email addresses, on the other hand, the use cas=
e
> for valid data is extremely clear, and the validation is already generall=
y
> performed for this reason. So I suggest that a distinction be made in thi=
s
> regard in the spec - through this is definitely a policy issue, not a
> conformance one. Still, the use cases are sufficiently different that I
> argue it's worth mentioning
>
> Grahame
>
>
> On Thursday, October 23, 2014, Shelley  wrote:
>
>> Thanks for the response, Phil.
>>
>>  If the SP can understand the value, it may accept it.
>>>
>>
>> Right, but what values can/should SPs attempt to "understand" since thes=
e
>> aren't described in the spec? What assumptions, if any, can be made abou=
t
>> the format provided by consumers? Further, what happens if the SP doesn'=
t
>> "accept" the value: 400 response? value is silently ignored? value is
>> stored, but not canonicalized?
>>
>> Further it may modify the value to conform to RFC3966 and return the
>>> modified value in the HTTP response.
>>
>>
>> The problem here is that modifying the value is not always possible or
>> may be done incorrectly depending on the format provided by the consumer=
.
>>
>> Many service providers would rather accept the POST and simply ignore th=
e
>>> value than to loose the transaction.
>>>
>>
>> Silently ignoring unknown values seems a bit dangerous as well. I agree
>> that the corrective action may be difficult to determine automatically i=
f
>> the transaction fails fast, but at least it brings some form of visibili=
ty
>> to the problem.
>>
>>
>> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  wrote=
:
>>
>>> Shelley,
>>>
>>> Thanks for your comments and bringing this to the groups attention.
>>>
>>> Overall, I would like to strike a balance in favour of being flexible i=
n
>>> what is accepted.  If the SP can understand the value, it may accept it=
.
>>> Further it may modify the value to conform to RFC3966 and return the
>>> modified value in the HTTP response. For example a service provider
>>> should feel free to correct something in telephone-subscriber format to=
 be
>>> returned as a URI instead.
>>> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles =
of SCIM that we
>>> should make more clearer?
>>>
>>> I think one of the problems with 3966 is that it seems quite broadly
>>> defined. Enforcement may be quite valid. But will it improve quality of
>>> information given the complication it will cause for clients (e.g. when=
 a
>>> request fails due to format, what is the corrective action)?  Many serv=
ice
>>> providers would rather accept the POST and simply ignore the value than=
 to
>>> loose the transaction.
>>>
>>> I agree we should adjust the language a bit. For example, are we
>>> expecting a telephone-uri or a telephone-subscriber as the value?  The =
spec
>>> is not clear.
>>>
>>> There are also some other parts to 3966 which duplicate what we are
>>> doing in multi-valued attributes. For example the ABNF =E2=80=9Cparamet=
er=E2=80=9D enables
>>> the following example:
>>>   tel:7042;phone-context=3Dexample.com
>>> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplicat=
ive of the
>>> function of =E2=80=9Ctype=E2=80=9D.
>>>
>>> Maybe it is not only that we want to following RFC3966, but we actually
>>> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s multi=
-valued JSON
>>> structure?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>>>
>>> I'd also like to clarify/highlight this problem/challenge with the
>>> current SCIM specification - the spec recommends that service providers
>>> canonicalize phone numbers to RFC 3966, yet, if there are no requiremen=
ts
>>> for the data provided by the consumer, this may be impossible.
>>>
>>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
>>> number" to RFC 3966? In an incomplete scenario, how can an SP canonical=
ize
>>> "222-2222" without a country/area code? And in an ambiguous scenario, h=
ow
>>> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
>>> extension)?
>>>
>>> While it may be possible for the SP to canonicalize *some *values under
>>> some *assumptions *(e.g. country code may be assumed, and assumptions
>>> based on patterns, etc), it is still possible that the canonicalization
>>> would be incorrect and in some cases, impossible.
>>>
>>> How are other SPs handling this? Is anyone doing validation or
>>> canonicalization?
>>>
>>> Likewise, how are SCIM clients consuming phone numbers (especially thos=
e
>>> that may be read-only consumers of data and don't have visibility/contr=
ol
>>> over the source data)? Is anyone doing any normalizing, validating,
>>> canonicalizing, or just leaving the data as-is regardless of the
>>> format/validity?
>>>
>>>
>>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
>>> aredston@switchresearch.com> wrote:
>>>
>>>>  Thanks - interesting link.
>>>>
>>>> Alex Redston
>>>>
>>>> CEO
>>>> Switch Identity Governance Ltd
>>>> 07973 320 795
>>>> 020 3434 3888
>>>>
>>>> On 22/10/2014 15:50, Shelley wrote:
>>>>
>>>>  The simplest approach would be to require SCIM consumers to provide
>>>> phone numbers in the RFC 3966 format, which at least helps to guarante=
e the
>>>> validity of the format and canonicalizes it into a standard global for=
mat
>>>> consumable by both external systems and users. This also accounts for =
some
>>>> of the scenarios you mentioned, such as sip calls.
>>>>
>>>>  As far as validating whether the phone number is actually a
>>>> potentially valid number (based on country, area code, etc.), this can=
 be
>>>> discussed further/separately as well. I agree that validating whether =
a
>>>> phone number is actually in service is probably not feasible but there=
 are
>>>> some standards and libraries that *could *potentially be used to deter
>>>> completely bogus numbers [1], but the value in this may be debatable.
>>>>
>>>>  The overall problem is just that without centralized data validation
>>>> in the service, SCIM consumers cannot rely on the syntax/validity of t=
he
>>>> data and therefore the burden of validating and normalizing falls to t=
hem.
>>>>
>>>> [1] https://code.google.com/p/libphonenumber/
>>>>
>>>>
>>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>>>> aredston@switchresearch.com> wrote:
>>>>
>>>>>  Of course the challenge here comes down to the extent to which that
>>>>> particular data can be standardised and validated. Taking phone numbe=
rs as
>>>>> the example you have sip calls, invalid numbers, country specific
>>>>> shortcodes, this is potentially a minefield.
>>>>>
>>>>> Well formed and valid values are two distinct concepts and with
>>>>> multiple carrier technologies the anatomy of simple +4412345678901 st=
yle
>>>>> numbers is no longer fit for purpose. For this reason I do not think =
that
>>>>> it is feasible for this particular data type to be rejected as bad da=
ta
>>>>> because the only way to know if a phone number is valid is to dial it=
.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Alex
>>>>>
>>>>> Alex Redston
>>>>>
>>>>> CEO
>>>>> Switch Identity Governance Ltd
>>>>> 07973 320 795
>>>>> 020 3434 3888
>>>>>
>>>>>  On 21/10/2014 20:36, Shelley wrote:
>>>>>
>>>>>  The SCIM specification expects service providers should be able to
>>>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>>>> phoneNumbers), yet it does not explicitly describe input requirements
>>>>> or validation for attributes such as these.* Is it expected that
>>>>> values that cannot accurately be canonicalized are rejected by the SC=
IM
>>>>> service or that the SCIM service accepts this invalid data and merely
>>>>> persists and returns this bad data to consumers?*
>>>>>
>>>>> As a SCIM Service Provider, we are currently performing validation on
>>>>> attributes such as phoneNumbers and emails to ensure that they
>>>>> contain well-formed, valid values, and returning a 400 with a descrip=
tion
>>>>> of the error if validation fails. One of the benefits of SCIM is that=
 data
>>>>> may come from multiple sources and may be consumed by multiple client=
s, and
>>>>> SCIM provides a repository of structured and well-formed data so that
>>>>> consumers can reliably derive meaning and use from this data. Without
>>>>> attribute validation and a guarantee of canonicalized values, this go=
al
>>>>> does not seem feasible and puts the burden on consumers to make sense=
 of
>>>>> potentially invalid data.
>>>>>
>>>>> The downside to attribute validation is that it requires the SCIM
>>>>> consumers sending data to ensure valid data as well. As these consume=
rs are
>>>>> closest to the source data, though, this seems like the most reasonab=
le
>>>>> approach rather than putting the burden on the service provider and/o=
r
>>>>> other SCIM consumers to make sense of the data. Aside from just "bad =
data"
>>>>> (e.g. sending "not a phone number" or "000-0000" for a phone number),=
 for
>>>>> example, if the SCIM consumer sending source data sends phone numbers
>>>>> without area codes or sends only internal extensions, another SCIM co=
nsumer
>>>>> may not be able to make sense of this data. It seems reasonable to re=
quire
>>>>> the consumer sending the data to ensure that this data is well-formed=
 and
>>>>> canonicalized/canonicalizable.
>>>>>
>>>>> A *good *example in the SCIM specification is the country attribute,
>>>>> which clearly indicates the attribute's requirements. A *bad *example
>>>>> is the phoneNumbers attribute, which doesn't describe the expected
>>>>> format to be provided by consumers, yet recommends that the service
>>>>> provider canonicalize the value even though the input may not be able=
 to be
>>>>> canonicalized.
>>>>>
>>>>>  I'd be interested in hearing others' opinions on this matter, and
>>>>> whether the SCIM specification should clarify further restrictions on
>>>>> attribute values.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  ------------------------------
>>>>>     
>>>>>
>>>>> This email is free from viruses and malware because avast! Antivirus
>>>>>  protection is active.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>    
>>>>
>>>> This email is free from viruses and malware because avast! Antivirus
>>>>  protection is active.
>>>>
>>>>
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>>>
>>>
>>>
>>
>
> --
> -----
> http://www.healthintersections.com.au / grahame@healthintersections.com.a=
u
> / +61 411 867 065
>

--001a11402fbc6c5b81050607c3b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for your input, Grahame. To clarify, it sounds like=
 you are in favor of the following SCIM SP behavior? Please correct me if I=
've misunderstood.
  • Performing validation on email addresses<=
/li>
  • Performing validation on mobile phone numbers
  • Not performin=
g validation on other phone numbers
  • Not canonicalizing phone number=
s??
Are you currently implementing this approach in a SCIM impl=
ementation? If you are in favor of performing validation on mobile numbers,=
 would you recommend/require the use of a certain format? What happens when=
 validation fails?
Personally, I don't know that we should=
 be differentiating required formats or validation based on the attribute &=
quot;type" (i.e. treating mobile numbers differently than other number=
s). The use cases for these may often be the same, and further, some number=
s may not even specify a type, so drawing a line here would be ambiguous.

On We=
d, Oct 22, 2014 at 1:11 PM, Grahame Grieve <grahame@healt=
hintersections.com.au> wrote:
In healthcare, we defined some global standards that required all teleph=
one numbers to be in rfc3966 format

In practice, impleme=
nters have not conformed to this - they simply ignore that part of the spec=
ification. Not only do they have vast amounts of existing non-conformant da=
ta that they can't rectify automatically, there is very little value in=
 it - telephone numbers are almost exclusively used by people to communicat=
e with people, and conforming to rfc 3966 is actually a negative value.

Yes, there are some limitations to this - systems tha=
t have integrated pabxs have the load of doing the data validation on the f=
ly. But if they're using a telephone, they almost always have a person =
to mediate that process.

Mobile phone numbers, and=
 email addresses, on the other hand, the use case for valid data=C2=A0is ex=
tremely clear, and the validation is already=C2=A0generally performed for t=
his reason. So I=C2=A0suggest that a distinction be made in this regard in =
the spec=C2=A0- through this is definitely a policy issue, not a conformanc=
e one. Still, the use=C2=A0cases are sufficiently different that I argue it=
's worth mentioning

Grahame


On Thursday, October 23,=
 2014, Shelley <randomshelley@gmail.com> wrote:
Thanks for the response, Phil.

=C2=A0If the SP can understand the va=
lue, it may accept it.

Right, but what values can=
/should SPs attempt to "understand" since these aren't descri=
bed in the spec? What assumptions, if any, can be made about the format pro=
vided by consumers? Further, what happens if the SP doesn't "accep=
t" the value: 400 response? value is silently ignored? value is stored=
, but not canonicalized?

Further it may modify the value to conform to RFC3966 and retur=
n the modified value in the HTTP response.

=
The problem here is that modifying the value is not always possible or may =
be done incorrectly depending on the format provided by the consumer.
Many service providers =
would rather accept the POST and simply ignore the value than to loose the =
transaction.

Silently ignoring unknown value=
s seems a bit dangerous as well. I agree that the corrective action may be =
difficult to determine automatically if the transaction fails fast, but at =
least it brings some form of visibility to the problem.
=C2=
=A0

On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt <<=
a>phil.hunt@oracle.com> wrote:
Shelley,

<=
div>Thanks for your comments and bringing this to the groups attention.

Overall, I would like to strike a balance in favour of bei=
ng flexible in what is accepted.=C2=A0 If the SP can understand the value, =
it may accept it. Further it may modify the value to conform to RFC3966 and=
 return the modified value in the HTTP response. For example a servic=
e provider should feel free to correct something in telephone-subscriber fo=
rmat to be returned as a URI instead.
=E2=80=94> maybe Postel=
=E2=80=99s Law is one of the general principles of SCIM that we should make=
 more clearer?

I think one of the problems with 3966=
 is that it seems quite broadly defined. Enforcement may be quite valid. Bu=
t will it improve quality of information given the complication it will cau=
se for clients (e.g. when a request fails due to format, what is the correc=
tive action)?=C2=A0 Many service providers would rather accept the POST and=
 simply ignore the value than to loose the transaction.

I agree we s=
hould adjust the language a bit. For example, are we expecting a telephone-=
uri or a telephone-subscriber as the value?=C2=A0 The spec is not clear. =
=C2=A0

There are also some other parts to 3966 whi=
ch duplicate what we are doing in multi-valued attributes. For example the =
ABNF =E2=80=9Cparameter=E2=80=9D enables the following example:=C2=A0
=

=C2=A0=C2=A0tel:7042;phone-context=3Dexample.com
In this case, =E2=80=9Cphone=
-context=E2=80=9D could be seen as duplicative of the function of =E2=80=9C=
type=E2=80=9D.

Maybe it is not only that we want t=
o following RFC3966, but we actually want to fully specify how 3966 is mapp=
ed to phoneNumber=E2=80=99s multi-valued JSON structure?






On Oct 22, 2014, at 8:41 AM, Shelley <randoms=
helley@gmail.com> wrote:

I'd also like to clarify/=
highlight this problem/challenge with the current SCIM specification - the =
spec recommends that service providers canonicalize phone numbers to RFC 39=
66, yet, if there are no requirements for the data provided by the consumer=
, this may be impossible.

In the extreme scenario, how can a SCIM SP=
 canonicalize "not a phone number" to RFC 3966? In an incomplete =
scenario, how can an SP canonicalize "222-2222" without a country=
/area code? And in an ambiguous scenario, how can an SP canonicalize "=
201-5399 123" (where 123 is assumed to be an extension)?

=
While it may be possible for the SP to canonicalize some values unde=
r some assumptions (e.g. country code may be assumed, and assumption=
s based on patterns, etc), it is still possible that the canonicalization w=
ould be incorrect and in some cases, impossible.

How are other=
 SPs handling this? Is anyone doing validation or canonicalization? 
Likewise, how are SCIM clients consuming phone numbers (especially t=
hose that may be read-only consumers of data and don't have visibility/=
control over the source data)? Is anyone doing any normalizing, validating,=
 canonicalizing, or just leaving the data as-is regardless of the format/va=
lidity?


On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch=
.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	











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






-- 
-----
http://www.healthintersections.com.au / grahame@he=
althintersections.com.au / +61 411 867 065




--001a11402fbc6c5b81050607c3b5--


From nobody Wed Oct 22 12:39: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 859701AD3C2 for ; Wed, 22 Oct 2014 12:39:39 -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 d4feHvJ6ojqD for ; Wed, 22 Oct 2014 12:39:35 -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 7E1C11AD3C1 for ; Wed, 22 Oct 2014 12:39:34 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id pn19so3611381lab.28 for ; Wed, 22 Oct 2014 12:39: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AV0JsHkuWPG5+LlkCO7xazuZQO7WlyRFhuFU5mgbKzg=; b=BpxIKyEiepuMAFywwiALZRJUsKAceJF8IE3wZtcfXCY3iL1iWa65w1IES5A6joHuQn ZImkoRAkNraDmO5zZoxCa8MXjqez91MxSn9dAewY5nycYmdpCaAI/EaUpTnOjA9O8gOm PuaqbEdXPYV02vE25ioWyYGqvTFg8+fSCB8LhysFNDFSvct5S0+Rj9f87CIp2yCLJqu4 48Ywc2lcwYz25ZoHiJEZLdw+uABLgahky3KrS+HEuxAh7HracSPo93t+PCct6yh+ORfH acEHQBkqyYhMsK+Ozbf/YVeCFOnv63pFIZ5rbMOOGfLGOv6lxYkHe7ogDWNEWJemzIVV j9Ng==
X-Gm-Message-State: ALoCoQk5ynAlDEKAY0BHIEhZ6TWP0Nz4kX41HP7r2N8wLxL0qKSTxdK1CCfmrx3qDrjPWXwdvvAb
X-Received: by 10.153.4.44 with SMTP id cb12mr323628lad.10.1414006772449; Wed, 22 Oct 2014 12:39:32 -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 nx6sm5225794lbb.20.2014.10.22.12.39.31 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 12:39:31 -0700 (PDT)
Message-ID: <544807F3.8090604@mnt.se>
Date: Wed, 22 Oct 2014 21:39:31 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: scim@ietf.org
References:   <803B963C-FD3A-473F-9E82-747FD4A9360D@oracle.com> <2508B747-F882-4205-8D99-E1E40307E790@oracle.com>  <5446B663.6030104@switchresearch.com>
In-Reply-To: <5446B663.6030104@switchresearch.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Lwo3bHm1Psz30DL06gf_KFv7Dys
Subject: Re: [scim] PATCH method in 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: Wed, 22 Oct 2014 19:39:39 -0000

> I know the S in SCIM no longer stands for simple and the spec is more
> complete, robust, deterministic and flexible now but the syntax is
> becoming more verbose, as it does I can't help but think it would be
> cleaner if XML were restored to the spec.

Hi Alex,

The XML issue has been settled by consensus in the WG already and based
on the (lack of response) to your comment above, we're not re-opening
that issue.

The documents are currently in WGLC (closing tomorrow) so if you have
specific concerns you should write them up right now and send them to
the list.

	Cheers Leif (with my chair hat on)


From nobody Wed Oct 22 12:42: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 CE0211AD3D9 for ; Wed, 22 Oct 2014 12:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.267
X-Spam-Level: 
X-Spam-Status: No, score=-1.267 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, T_FILL_THIS_FORM_SHORT=0.01] 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 J3PAVxDRGj3b for ; Wed, 22 Oct 2014 12:42:15 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773591AD3CC for ; Wed, 22 Oct 2014 12:42:15 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id a141so3294088oig.6 for ; Wed, 22 Oct 2014 12:42: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=eRlmdiWdMr0Ehe2Qbgu6MKAxGMnhCWCx9F+37F/nfYc=; b=r1VvEHKuMcJGRbnfHwulkG3GzAi9KVB2Ljxc4Pp/iNPVyKa3TA7BwITA3BX084GktF ZwQlS5HnfJWme1FfHUBH0t+uQPKxCHfbKgx/dMgke9rA91gRfpdBhWmG+yNeOz76/pVu YlZD9UnvEAUZB7E9OaubqH5Kan1+ohmxiIz8wSINvYDrI6YmUkIfYEUURi2WDcbADXAQ 7o6RVF8iPGaPd3yy3dwgCHpzjbxndoTXIA25gmF9AAUIPqt4F1CF+TVF7duW8IiFKxJp 161yrRt1FdkXC+uY5nObnFFZNhJH4r752Ff2WJQl4+o+b27gxko/tddu5W+2fBR02uX/ ObFQ==
MIME-Version: 1.0
X-Received: by 10.182.58.20 with SMTP id m20mr158187obq.82.1414006934861; Wed, 22 Oct 2014 12:42:14 -0700 (PDT)
Sender: grahameg@gmail.com
Received: by 10.60.39.232 with HTTP; Wed, 22 Oct 2014 12:42:14 -0700 (PDT)
In-Reply-To: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>   
Date: Thu, 23 Oct 2014 06:42:14 +1100
X-Google-Sender-Auth: vNfdo9JzbQJ2ZMzSegxXOB6Z6Zs
Message-ID: 
From: Grahame Grieve 
To: Shelley 
Content-Type: multipart/alternative; boundary=e89a8f83a8fd0ffdfa05060825c7
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/TlpzBatjzn-gIMtdckAbIfLhfTs
Cc: Alex Redston , "scim@ietf.org" , Phil Hunt 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 19:42:20 -0000

--e89a8f83a8fd0ffdfa05060825c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> Thanks for your input, Grahame. To clarify, it sounds like you are in
> favor of the following SCIM SP behavior? Please correct me if I've
> misunderstood.
>

I'm in favor of it, but not in favor of requiring it - there are too many
incompatible business processes out there, and it harms adoption and
outcomes if you require changes to business practice in these things

> Are you currently implementing this approach in a SCIM implementation?
>
no. I have done that approach in an enterprise information system, but not
a SCIM implementation. My SCIM implementation doesn't validate any
addresses. but since my SCIM implementation lives in prototype land, I
wouldn't think that my implementing validation or not would teach anything.


> If you are in favor of performing validation on mobile numbers, would you
> recommend/require the use of a certain format? What happens when validati=
on
> fails?
>
if we require anything, it would make sense to require RFC 3966. It would
be possible for clients with a known nation to remediate prefixes if people
wanted (e.g. switch out +1 in USA for display)

> Personally, I don't know that we should be differentiating required
> formats or validation based on the attribute "type" (i.e. treating mobile
> numbers differently than other numbers). The use cases for these may ofte=
n
> be the same, and further, some numbers may not even specify a type, so
> drawing a line here would be ambiguous.
>
well, no type would mean no validation. But I wasn't recommending that the
spec require validation. I think it should
(a) say that the recommended canonical representation is RFC 3966
(b) say that validation is not required, but may be implemented, and is
likely to be so more often for mobile phone numbers and email addresses
(c) say that if values fail validation, the error code should be 422. In my
health RESTful spec, we define a structured error format to be returned in
cases like this, SCIM could consider this, but this is borderline. (We have
compelling cases in other contexts where handling errors correctly is a
life/death matter, and inherit that in these simple cases)
(d) define a way to describe what validation occurs in the schema

Grahame


>
> On Wed, Oct 22, 2014 at 1:11 PM, Grahame Grieve <
> grahame@healthintersections.com.au> wrote:
>
>> In healthcare, we defined some global standards that required all
>> telephone numbers to be in rfc3966 format
>>
>> In practice, implementers have not conformed to this - they simply ignor=
e
>> that part of the specification. Not only do they have vast amounts of
>> existing non-conformant data that they can't rectify automatically, ther=
e
>> is very little value in it - telephone numbers are almost exclusively us=
ed
>> by people to communicate with people, and conforming to rfc 3966 is
>> actually a negative value.
>>
>> Yes, there are some limitations to this - systems that have integrated
>> pabxs have the load of doing the data validation on the fly. But if they=
're
>> using a telephone, they almost always have a person to mediate that proc=
ess.
>>
>> Mobile phone numbers, and email addresses, on the other hand, the use
>> case for valid data is extremely clear, and the validation is
>> already generally performed for this reason. So I suggest that a
>> distinction be made in this regard in the spec - through this is definit=
ely
>> a policy issue, not a conformance one. Still, the use cases are
>> sufficiently different that I argue it's worth mentioning
>>
>> Grahame
>>
>>
>> On Thursday, October 23, 2014, Shelley  wrote:
>>
>>> Thanks for the response, Phil.
>>>
>>>  If the SP can understand the value, it may accept it.
>>>>
>>>
>>> Right, but what values can/should SPs attempt to "understand" since
>>> these aren't described in the spec? What assumptions, if any, can be ma=
de
>>> about the format provided by consumers? Further, what happens if the SP
>>> doesn't "accept" the value: 400 response? value is silently ignored? va=
lue
>>> is stored, but not canonicalized?
>>>
>>> Further it may modify the value to conform to RFC3966 and return the
>>>> modified value in the HTTP response.
>>>
>>>
>>> The problem here is that modifying the value is not always possible or
>>> may be done incorrectly depending on the format provided by the consume=
r.
>>>
>>> Many service providers would rather accept the POST and simply ignore
>>>> the value than to loose the transaction.
>>>>
>>>
>>> Silently ignoring unknown values seems a bit dangerous as well. I agree
>>> that the corrective action may be difficult to determine automatically =
if
>>> the transaction fails fast, but at least it brings some form of visibil=
ity
>>> to the problem.
>>>
>>>
>>> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt 
>>> wrote:
>>>
>>>> Shelley,
>>>>
>>>> Thanks for your comments and bringing this to the groups attention.
>>>>
>>>> Overall, I would like to strike a balance in favour of being flexible
>>>> in what is accepted.  If the SP can understand the value, it may accep=
t it.
>>>> Further it may modify the value to conform to RFC3966 and return the
>>>> modified value in the HTTP response. For example a service provider
>>>> should feel free to correct something in telephone-subscriber format t=
o be
>>>> returned as a URI instead.
>>>> =E2=80=94> maybe Postel=E2=80=99s Law is one of the general principles=
 of SCIM that we
>>>> should make more clearer?
>>>>
>>>> I think one of the problems with 3966 is that it seems quite broadly
>>>> defined. Enforcement may be quite valid. But will it improve quality o=
f
>>>> information given the complication it will cause for clients (e.g. whe=
n a
>>>> request fails due to format, what is the corrective action)?  Many ser=
vice
>>>> providers would rather accept the POST and simply ignore the value tha=
n to
>>>> loose the transaction.
>>>>
>>>> I agree we should adjust the language a bit. For example, are we
>>>> expecting a telephone-uri or a telephone-subscriber as the value?  The=
 spec
>>>> is not clear.
>>>>
>>>> There are also some other parts to 3966 which duplicate what we are
>>>> doing in multi-valued attributes. For example the ABNF =E2=80=9Cparame=
ter=E2=80=9D enables
>>>> the following example:
>>>>   tel:7042;phone-context=3Dexample.com
>>>> In this case, =E2=80=9Cphone-context=E2=80=9D could be seen as duplica=
tive of the
>>>> function of =E2=80=9Ctype=E2=80=9D.
>>>>
>>>> Maybe it is not only that we want to following RFC3966, but we actuall=
y
>>>> want to fully specify how 3966 is mapped to phoneNumber=E2=80=99s mult=
i-valued JSON
>>>> structure?
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>
>>>>
>>>>
>>>> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>>>>
>>>> I'd also like to clarify/highlight this problem/challenge with the
>>>> current SCIM specification - the spec recommends that service provider=
s
>>>> canonicalize phone numbers to RFC 3966, yet, if there are no requireme=
nts
>>>> for the data provided by the consumer, this may be impossible.
>>>>
>>>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone
>>>> number" to RFC 3966? In an incomplete scenario, how can an SP canonica=
lize
>>>> "222-2222" without a country/area code? And in an ambiguous scenario, =
how
>>>> can an SP canonicalize "201-5399 123" (where 123 is assumed to be an
>>>> extension)?
>>>>
>>>> While it may be possible for the SP to canonicalize *some *values
>>>> under some *assumptions *(e.g. country code may be assumed, and
>>>> assumptions based on patterns, etc), it is still possible that the
>>>> canonicalization would be incorrect and in some cases, impossible.
>>>>
>>>> How are other SPs handling this? Is anyone doing validation or
>>>> canonicalization?
>>>>
>>>> Likewise, how are SCIM clients consuming phone numbers (especially
>>>> those that may be read-only consumers of data and don't have
>>>> visibility/control over the source data)? Is anyone doing any normaliz=
ing,
>>>> validating, canonicalizing, or just leaving the data as-is regardless =
of
>>>> the format/validity?
>>>>
>>>>
>>>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <
>>>> aredston@switchresearch.com> wrote:
>>>>
>>>>>  Thanks - interesting link.
>>>>>
>>>>> Alex Redston
>>>>>
>>>>> CEO
>>>>> Switch Identity Governance Ltd
>>>>> 07973 320 795
>>>>> 020 3434 3888
>>>>>
>>>>> On 22/10/2014 15:50, Shelley wrote:
>>>>>
>>>>>  The simplest approach would be to require SCIM consumers to provide
>>>>> phone numbers in the RFC 3966 format, which at least helps to guarant=
ee the
>>>>> validity of the format and canonicalizes it into a standard global fo=
rmat
>>>>> consumable by both external systems and users. This also accounts for=
 some
>>>>> of the scenarios you mentioned, such as sip calls.
>>>>>
>>>>>  As far as validating whether the phone number is actually a
>>>>> potentially valid number (based on country, area code, etc.), this ca=
n be
>>>>> discussed further/separately as well. I agree that validating whether=
 a
>>>>> phone number is actually in service is probably not feasible but ther=
e are
>>>>> some standards and libraries that *could *potentially be used to
>>>>> deter completely bogus numbers [1], but the value in this may be deba=
table.
>>>>>
>>>>>  The overall problem is just that without centralized data validation
>>>>> in the service, SCIM consumers cannot rely on the syntax/validity of =
the
>>>>> data and therefore the burden of validating and normalizing falls to =
them.
>>>>>
>>>>> [1] https://code.google.com/p/libphonenumber/
>>>>>
>>>>>
>>>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston <
>>>>> aredston@switchresearch.com> wrote:
>>>>>
>>>>>>  Of course the challenge here comes down to the extent to which that
>>>>>> particular data can be standardised and validated. Taking phone numb=
ers as
>>>>>> the example you have sip calls, invalid numbers, country specific
>>>>>> shortcodes, this is potentially a minefield.
>>>>>>
>>>>>> Well formed and valid values are two distinct concepts and with
>>>>>> multiple carrier technologies the anatomy of simple +4412345678901 s=
tyle
>>>>>> numbers is no longer fit for purpose. For this reason I do not think=
 that
>>>>>> it is feasible for this particular data type to be rejected as bad d=
ata
>>>>>> because the only way to know if a phone number is valid is to dial i=
t.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Alex Redston
>>>>>>
>>>>>> CEO
>>>>>> Switch Identity Governance Ltd
>>>>>> 07973 320 795
>>>>>> 020 3434 3888
>>>>>>
>>>>>>  On 21/10/2014 20:36, Shelley wrote:
>>>>>>
>>>>>>  The SCIM specification expects service providers should be able to
>>>>>> canonicalize provided data into a common format (e.g. RFC 3966 for
>>>>>> phoneNumbers), yet it does not explicitly describe input
>>>>>> requirements or validation for attributes such as these.* Is it
>>>>>> expected that values that cannot accurately be canonicalized are rej=
ected
>>>>>> by the SCIM service or that the SCIM service accepts this invalid da=
ta and
>>>>>> merely persists and returns this bad data to consumers?*
>>>>>>
>>>>>> As a SCIM Service Provider, we are currently performing validation o=
n
>>>>>> attributes such as phoneNumbers and emails to ensure that they
>>>>>> contain well-formed, valid values, and returning a 400 with a descri=
ption
>>>>>> of the error if validation fails. One of the benefits of SCIM is tha=
t data
>>>>>> may come from multiple sources and may be consumed by multiple clien=
ts, and
>>>>>> SCIM provides a repository of structured and well-formed data so tha=
t
>>>>>> consumers can reliably derive meaning and use from this data. Withou=
t
>>>>>> attribute validation and a guarantee of canonicalized values, this g=
oal
>>>>>> does not seem feasible and puts the burden on consumers to make sens=
e of
>>>>>> potentially invalid data.
>>>>>>
>>>>>> The downside to attribute validation is that it requires the SCIM
>>>>>> consumers sending data to ensure valid data as well. As these consum=
ers are
>>>>>> closest to the source data, though, this seems like the most reasona=
ble
>>>>>> approach rather than putting the burden on the service provider and/=
or
>>>>>> other SCIM consumers to make sense of the data. Aside from just "bad=
 data"
>>>>>> (e.g. sending "not a phone number" or "000-0000" for a phone number)=
, for
>>>>>> example, if the SCIM consumer sending source data sends phone number=
s
>>>>>> without area codes or sends only internal extensions, another SCIM c=
onsumer
>>>>>> may not be able to make sense of this data. It seems reasonable to r=
equire
>>>>>> the consumer sending the data to ensure that this data is well-forme=
d and
>>>>>> canonicalized/canonicalizable.
>>>>>>
>>>>>> A *good *example in the SCIM specification is the country attribute,
>>>>>> which clearly indicates the attribute's requirements. A *bad *exampl=
e
>>>>>> is the phoneNumbers attribute, which doesn't describe the expected
>>>>>> format to be provided by consumers, yet recommends that the service
>>>>>> provider canonicalize the value even though the input may not be abl=
e to be
>>>>>> canonicalized.
>>>>>>
>>>>>>  I'd be interested in hearing others' opinions on this matter, and
>>>>>> whether the SCIM specification should clarify further restrictions o=
n
>>>>>> attribute values.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ------------------------------
>>>>>>     
>>>>>>
>>>>>> This email is free from viruses and malware because avast! Antivirus
>>>>>>  protection is active.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>    
>>>>>
>>>>> This email is free from viruses and malware because avast! Antivirus
>>>>>  protection is active.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>


--=20
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065

--e89a8f83a8fd0ffdfa05060825c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for your input, Grahame.=
 To clarify, it sounds like you are in favor of the following SCIM SP behav=
ior? Please correct me if I've misunderstood.

I'm in favor of it, but not in favor of requiring it -=
 there are too many incompatible business processes out there, and it harms=
 adoption and outcomes if you require changes to business practice in these=
 things=C2=A0
Are y=
ou currently implementing this approach in a SCIM implementation?
=

no. I have done that approach in an enterprise informatio=
n system, but not a SCIM implementation. My SCIM implementation doesn't=
 validate any addresses. but since my SCIM implementation lives in prototyp=
e land, I wouldn't think that my implementing validation or not would t=
each anything. =C2=A0
=

 If you are in favor of performing validation on mobile numbers, would y=
ou recommend/require the use of a certain format? What happens when validat=
ion fails?
if we require anything, it would make=
 sense to require RFC 3966. It would be possible for clients with a known n=
ation to remediate prefixes if people wanted (e.g. switch out +1 in USA for=
 display)
Pe=
rsonally, I don't know that we should be differentiating required forma=
ts or validation based on the attribute "type" (i.e. treating mob=
ile numbers differently than other numbers). The use cases for these may of=
ten be the same, and further, some numbers may not even specify a type, so =
drawing a line here would be ambiguous.
well=
, no type would mean no validation. But I wasn't recommending that the =
spec require validation. I think it should 
(a) say that the recommended=
 canonical representation is RFC 3966
(b) say that validation is =
not required, but may be implemented, and is likely to be so more often for=
 mobile phone numbers and email addresses
(c) say that if values fail va=
lidation, the error code should be 422. In my health RESTful spec, we defin=
e a structured error format to be returned in cases like this, SCIM could c=
onsider this, but this is borderline. (We have compelling cases in other co=
ntexts where handling errors correctly is a life/death matter, and inherit =
that in these simple cases)
(d) define a way to describe what val=
idation occurs in the schema

Grahame
=C2=
=A0

On Wed, Oct 22, 2014 at 1:11 PM, Grahame Grieve <grahame@healthintersections.com.au> wrote:
In healthcare, we defined some global standards=
 that required all telephone numbers to be in rfc3966 format

=

In practice, implementers have not conformed to this - they simply ign=
ore that part of the specification. Not only do they have vast amounts of e=
xisting non-conformant data that they can't rectify automatically, ther=
e is very little value in it - telephone numbers are almost exclusively use=
d by people to communicate with people, and conforming to rfc 3966 is actua=
lly a negative value.

Yes, there are some limitati=
ons to this - systems that have integrated pabxs have the load of doing the=
 data validation on the fly. But if they're using a telephone, they alm=
ost always have a person to mediate that process.

=
Mobile phone numbers, and email addresses, on the other hand, the use case =
for valid data=C2=A0is extremely clear, and the validation is already=C2=A0=
generally performed for this reason. So I=C2=A0suggest that a distinction b=
e made in this regard in the spec=C2=A0- through this is definitely a polic=
y issue, not a conformance one. Still, the use=C2=A0cases are sufficiently =
different that I argue it's worth mentioning

G=
rahame


On Thursday, October 23, 2014=
, Shelley <=
randomshelley@gmail.com> wrote:
Thanks for the response, Phil.

=C2=A0If the SP can understand the value, =
it may accept it.

Right, but what values can/shou=
ld SPs attempt to "understand" since these aren't described i=
n the spec? What assumptions, if any, can be made about the format provided=
 by consumers? Further, what happens if the SP doesn't "accept&quo=
t; the value: 400 response? value is silently ignored? value is stored, but=
 not canonicalized?

Further it may modify the value to conform to RFC3966 and return the=
 modified value in the HTTP response.

The p=
roblem here is that modifying the value is not always possible or may be do=
ne incorrectly depending on the format provided by the consumer.

Many service providers would=
 rather accept the POST and simply ignore the value than to loose the trans=
action.

Silently ignoring unknown values see=
ms a bit dangerous as well. I agree that the corrective action may be diffi=
cult to determine automatically if the transaction fails fast, but at least=
 it brings some form of visibility to the problem.
=C2=A0
=


On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt <phil.=
hunt@oracle.com> wrote:
Shelley,

Tha=
nks for your comments and bringing this to the groups attention.
=

Overall, I would like to strike a balance in favour of being flex=
ible in what is accepted.=C2=A0 If the SP can understand the value, it may =
accept it. Further it may modify the value to conform to RFC3966 and return=
 the modified value in the HTTP response. For example a service provi=
der should feel free to correct something in telephone-subscriber format to=
 be returned as a URI instead.
=E2=80=94> maybe Postel=E2=80=
=99s Law is one of the general principles of SCIM that we should make more =
clearer?

I think one of the problems with 3966 is th=
at it seems quite broadly defined. Enforcement may be quite valid. But will=
 it improve quality of information given the complication it will cause for=
 clients (e.g. when a request fails due to format, what is the corrective a=
ction)?=C2=A0 Many service providers would rather accept the POST and simpl=
y ignore the value than to loose the transaction.

=

=

I agree we sho=
uld adjust the language a bit. For example, are we expecting a telephone-ur=
i or a telephone-subscriber as the value?=C2=A0 The spec is not clear. =C2=
=A0

There are also some other parts to 3966 which =
duplicate what we are doing in multi-valued attributes. For example the ABN=
F =E2=80=9Cparameter=E2=80=9D enables the following example:=C2=A0
=C2=A0=C2=A0tel:7042;phone-context=3Dexample.com
In this case, =E2=80=9Cphone-c=
ontext=E2=80=9D could be seen as duplicative of the function of =E2=80=9Cty=
pe=E2=80=9D.

Maybe it is not only that we want to =
following RFC3966, but we actually want to fully specify how 3966 is mapped=
 to phoneNumber=E2=80=99s multi-valued JSON structure?

=

Phil

@independentid
phil.hunt@or=
acle.com






On Oct 22, 2014, at 8:41 AM, Shelley <randoms=
helley@gmail.com> wrote:

I'd also like to clarify/=
highlight this problem/challenge with the current SCIM specification - the =
spec recommends that service providers canonicalize phone numbers to RFC 39=
66, yet, if there are no requirements for the data provided by the consumer=
, this may be impossible.

In the extreme scenario, how can a SCIM SP=
 canonicalize "not a phone number" to RFC 3966? In an incomplete =
scenario, how can an SP canonicalize "222-2222" without a country=
/area code? And in an ambiguous scenario, how can an SP canonicalize "=
201-5399 123" (where 123 is assumed to be an extension)?

=
While it may be possible for the SP to canonicalize some values unde=
r some assumptions (e.g. country code may be assumed, and assumption=
s based on patterns, etc), it is still possible that the canonicalization w=
ould be incorrect and in some cases, impossible.

How are other=
 SPs handling this? Is anyone doing validation or canonicalization? 
Likewise, how are SCIM clients consuming phone numbers (especially t=
hose that may be read-only consumers of data and don't have visibility/=
control over the source data)? Is anyone doing any normalizing, validating,=
 canonicalizing, or just leaving the data as-is regardless of the format/va=
lidity?


On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch=
.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opin=
ions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                              
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and malware because avast! Antivirus protection is active.
			

				
	











_______________________________________________
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






-- 
=
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.=
au / +61 411 867 065


--e89a8f83a8fd0ffdfa05060825c7--


From nobody Wed Oct 22 12:46: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 790D51AD3ED for ; Wed, 22 Oct 2014 12:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP0L8rFbZhVN for ; Wed, 22 Oct 2014 12:46: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 ABDB91AD3E9 for ; Wed, 22 Oct 2014 12:46:12 -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 s9MJkAKd024116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Oct 2014 19:46:11 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 s9MJk9mW015285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Oct 2014 19:46:10 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9MJk8w8001678; Wed, 22 Oct 2014 19:46:09 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Oct 2014 12:46:08 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_07284753-C484-42C3-BE7E-060332E8D8DE"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 22 Oct 2014 12:46:06 -0700
Message-Id: 
References:  <5446B9D2.8040005@switchresearch.com>  <5447C7C1.9000704@switchresearch.com>  <7F82BED8-8DBB-4BAC-B8A8-20C033A18DBA@oracle.com>   
To: Shelley 
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/28ziLVHlGPHRYlw2EGKDnUo54WM
Cc: Alex Redston , "scim@ietf.org" 
Subject: Re: [scim] SCIM Attribute Validation
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, 22 Oct 2014 19:46:19 -0000

--Apple-Mail=_07284753-C484-42C3-BE7E-060332E8D8DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Comments inline=85

Phil

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



On Oct 22, 2014, at 12:13 PM, Shelley  wrote:

> Before any specific text is proposed, I'd like to get a general =
understanding for what the agreement/direction is. It seems there are =
still some major open questions that I'd appreciate some input on.
> Should consumers be required to provide values in specific formats?
> For example, for phone numbers, must consumers provide RFC 3966 =
format, an international format, any of multiple common/pre-defined =
formats, or is any value allowed? If not in RFC/international format, is =
the country/area code assumed?
> Should service providers perform attribute validation or accept any =
values?
> If service providers perform validation, what is the expected behavior =
when validation fails? (400 / ignore the value / store the value as-is?)
> Particularly if there are no requirements for data input and/or no =
validation is performed:
> What are the assumptions that service providers can make during =
canonicalization?
> What should service providers / consumers do if canonicalization is =
not possible?
> Should the use of both the "value" and "display" attributes be =
recommended?
> There are minimally two major variations of possible changes on the =
table, with various flavors in between:
>=20
> Require consumers to provide values in specified formats and SPs =
perform validation, rejecting invalid values
> SCIM serves as a repository of well-formed, valid data. This results =
in the most usable data for SCIM consumers reading data, but puts some =
burden on SCIM consumers providing the data to conform.
> -OR-
> Allow consumers to provide values in any format, SP performs no =
validation though it may attempt perform canonicalization
> SCIM serves as a repository of data from third parties, data may not =
be consistent, valid, or normalized. This results in the least effort =
for SCIM consumers providing data, but puts some burden on SCIM =
consumers reading the data to make sense of the data.
> SCIM SPs may attempt to normalize some of the data, but there may be =
no guarantees with respect to the consistency or accuracy of these =
normalizations.
[PH - ] I prefer this because it aligns with Postel=92s =
Law.

I recommend stipulating that any modification to the supplied values =
(e.g. canonicalization) by the service providers MUST be reflected in =
the HTTP Response JSON representation (e.g. after a POST request).=20

I think we also need to be clear about how 3966 ABNF elements should map =
to SCIM's multi-valued attribute representation for phoneNumbers. The =
earlier suggestion you made is on the right track (mapping to display, =
type, value, etc).  This might get a bit complex if for example the =
telephone number includes embedded parameters *and* the client already =
specifies type, value, and display representations.  My feeling is that =
the SP should always honour any assigned =93type=94 value by the client. =
 However, if the client does not assign a =93type=94, the SP could =
assign one based on parsing parameters. For example, say a client =
provides a value of "tel:7042;phone-context=3Dinternal=94.  The server =
might canonicalize/map as:

=93type=94:=94internal=94,
=93display=94:=947042=94,
=93value=94:"tel:7042;phone-context=3Dinternal=94

More generically, here is one possible mapping based on the ABNF from =
RFC3966 to phoneNumbers attribute:

=93value=94: =93{telephone-uri}=94
=93display=94:=94{global-number-digits / local-number-digits}=94
=93type=94:=94{descriptor}=94

SP=92s may attempt to canonicalize =93value=94 and normalize it. SPs may =
assign values to =93display=94 and =93type=94 if the client has not =
asserted values for these sub-attribues.

Regarding mapping of context and descriptor to SCIM type, we would be =
profiling 3966 to say that the ABNF  =93context=94 component is used and =
interpreted as a type. (can anybody confirm I have interpreted use of =
context in 3966 correctly?)

>=20
> On Wed, Oct 22, 2014 at 12:37 PM, Phil Hunt  =
wrote:
> Shelley,
>=20
> I think we are pretty much in agreement. Would you mind providing some =
new text for the definition of phoneNumbers?  I like where you are going =
with value vs. displayName etc.
>=20
> It would be good to see how the group feels on a some new proposed =
text.
>=20
> Thanks,
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
> On Oct 22, 2014, at 10:22 AM, Shelley  wrote:
>=20
>> Thanks for the response, Phil.
>>=20
>>  If the SP can understand the value, it may accept it.
>>=20
>> Right, but what values can/should SPs attempt to "understand" since =
these aren't described in the spec? What assumptions, if any, can be =
made about the format provided by consumers? Further, what happens if =
the SP doesn't "accept" the value: 400 response? value is silently =
ignored? value is stored, but not canonicalized?
>>=20
>> Further it may modify the value to conform to RFC3966 and return the =
modified value in the HTTP response.
>>=20
>> The problem here is that modifying the value is not always possible =
or may be done incorrectly depending on the format provided by the =
consumer.
>>=20
>> Many service providers would rather accept the POST and simply ignore =
the value than to loose the transaction.
>>=20
>> Silently ignoring unknown values seems a bit dangerous as well. I =
agree that the corrective action may be difficult to determine =
automatically if the transaction fails fast, but at least it brings some =
form of visibility to the problem.
>> =20
>>=20
>> On Wed, Oct 22, 2014 at 11:39 AM, Phil Hunt  =
wrote:
>> Shelley,
>>=20
>> Thanks for your comments and bringing this to the groups attention.
>>=20
>> Overall, I would like to strike a balance in favour of being flexible =
in what is accepted.  If the SP can understand the value, it may accept =
it. Further it may modify the value to conform to RFC3966 and return the =
modified value in the HTTP response. For example a service provider =
should feel free to correct something in telephone-subscriber format to =
be returned as a URI instead.
>> =97> maybe Postel=92s Law is one of the general principles of SCIM =
that we should make more clearer?
>>=20
>> I think one of the problems with 3966 is that it seems quite broadly =
defined. Enforcement may be quite valid. But will it improve quality of =
information given the complication it will cause for clients (e.g. when =
a request fails due to format, what is the corrective action)?  Many =
service providers would rather accept the POST and simply ignore the =
value than to loose the transaction.
>>=20
>> I agree we should adjust the language a bit. For example, are we =
expecting a telephone-uri or a telephone-subscriber as the value?  The =
spec is not clear. =20
>>=20
>> There are also some other parts to 3966 which duplicate what we are =
doing in multi-valued attributes. For example the ABNF =93parameter=94 =
enables the following example:=20
>>   tel:7042;phone-context=3Dexample.com
>> In this case, =93phone-context=94 could be seen as duplicative of the =
function of =93type=94.
>>=20
>> Maybe it is not only that we want to following RFC3966, but we =
actually want to fully specify how 3966 is mapped to phoneNumber=92s =
multi-valued JSON structure?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>> On Oct 22, 2014, at 8:41 AM, Shelley  wrote:
>>=20
>>> I'd also like to clarify/highlight this problem/challenge with the =
current SCIM specification - the spec recommends that service providers =
canonicalize phone numbers to RFC 3966, yet, if there are no =
requirements for the data provided by the consumer, this may be =
impossible.
>>>=20
>>> In the extreme scenario, how can a SCIM SP canonicalize "not a phone =
number" to RFC 3966? In an incomplete scenario, how can an SP =
canonicalize "222-2222" without a country/area code? And in an ambiguous =
scenario, how can an SP canonicalize "201-5399 123" (where 123 is =
assumed to be an extension)?
>>>=20
>>> While it may be possible for the SP to canonicalize some values =
under some assumptions (e.g. country code may be assumed, and =
assumptions based on patterns, etc), it is still possible that the =
canonicalization would be incorrect and in some cases, impossible.
>>>=20
>>> How are other SPs handling this? Is anyone doing validation or =
canonicalization?=20
>>>=20
>>> Likewise, how are SCIM clients consuming phone numbers (especially =
those that may be read-only consumers of data and don't have =
visibility/control over the source data)? Is anyone doing any =
normalizing, validating, canonicalizing, or just leaving the data as-is =
regardless of the format/validity?
>>>=20
>>>=20
>>> On Wed, Oct 22, 2014 at 10:05 AM, Alex Redston =
 wrote:
>>> Thanks - interesting link.
>>> Alex Redston
>>>=20
>>> CEO
>>> Switch Identity Governance Ltd
>>> 07973 320 795
>>> 020 3434 3888
>>> On 22/10/2014 15:50, Shelley wrote:
>>>> The simplest approach would be to require SCIM consumers to provide =
phone numbers in the RFC 3966 format, which at least helps to guarantee =
the validity of the format and canonicalizes it into a standard global =
format consumable by both external systems and users. This also accounts =
for some of the scenarios you mentioned, such as sip calls.
>>>>=20
>>>> As far as validating whether the phone number is actually a =
potentially valid number (based on country, area code, etc.), this can =
be discussed further/separately as well. I agree that validating whether =
a phone number is actually in service is probably not feasible but there =
are some standards and libraries that could potentially be used to deter =
completely bogus numbers [1], but the value in this may be debatable.
>>>>=20
>>>> The overall problem is just that without centralized data =
validation in the service, SCIM consumers cannot rely on the =
syntax/validity of the data and therefore the burden of validating and =
normalizing falls to them.
>>>>=20
>>>> [1] https://code.google.com/p/libphonenumber/
>>>>=20
>>>>=20
>>>> On Tue, Oct 21, 2014 at 2:53 PM, Alex Redston =
 wrote:
>>>> Of course the challenge here comes down to the extent to which that =
particular data can be standardised and validated. Taking phone numbers =
as the example you have sip calls, invalid numbers, country specific =
shortcodes, this is potentially a minefield.
>>>>=20
>>>> Well formed and valid values are two distinct concepts and with =
multiple carrier technologies the anatomy of simple +4412345678901 style =
numbers is no longer fit for purpose. For this reason I do not think =
that it is feasible for this particular data type to be rejected as bad =
data because the only way to know if a phone number is valid is to dial =
it.
>>>>=20
>>>> What do you think?
>>>>=20
>>>> Alex
>>>> Alex Redston
>>>>=20
>>>> CEO
>>>> Switch Identity Governance Ltd
>>>> 07973 320 795
>>>> 020 3434 3888
>>>> On 21/10/2014 20:36, Shelley wrote:
>>>>> The SCIM specification expects service providers should be able to =
canonicalize provided data into a common format (e.g. RFC 3966 for =
phoneNumbers), yet it does not explicitly describe input requirements or =
validation for attributes such as these. Is it expected that values that =
cannot accurately be canonicalized are rejected by the SCIM service or =
that the SCIM service accepts this invalid data and merely persists and =
returns this bad data to consumers?
>>>>>=20
>>>>> As a SCIM Service Provider, we are currently performing validation =
on attributes such as phoneNumbers and emails to ensure that they =
contain well-formed, valid values, and returning a 400 with a =
description of the error if validation fails. One of the benefits of =
SCIM is that data may come from multiple sources and may be consumed by =
multiple clients, and SCIM provides a repository of structured and =
well-formed data so that consumers can reliably derive meaning and use =
from this data. Without attribute validation and a guarantee of =
canonicalized values, this goal does not seem feasible and puts the =
burden on consumers to make sense of potentially invalid data.
>>>>>=20
>>>>> The downside to attribute validation is that it requires the SCIM =
consumers sending data to ensure valid data as well. As these consumers =
are closest to the source data, though, this seems like the most =
reasonable approach rather than putting the burden on the service =
provider and/or other SCIM consumers to make sense of the data. Aside =
from just "bad data" (e.g. sending "not a phone number" or "000-0000" =
for a phone number), for example, if the SCIM consumer sending source =
data sends phone numbers without area codes or sends only internal =
extensions, another SCIM consumer may not be able to make sense of this =
data. It seems reasonable to require the consumer sending the data to =
ensure that this data is well-formed and canonicalized/canonicalizable.
>>>>>=20
>>>>> A good example in the SCIM specification is the country attribute, =
which clearly indicates the attribute's requirements. A bad example is =
the phoneNumbers attribute, which doesn't describe the expected format =
to be provided by consumers, yet recommends that the service provider =
canonicalize the value even though the input may not be able to be =
canonicalized.
>>>>>=20
>>>>> I'd be interested in hearing others' opinions on this matter, and =
whether the SCIM specification should clarify further restrictions on =
attribute values.
>>>>=20
>>>>=20
>>>>=20
>>>>  =09
>>>> This email is free from viruses and malware because avast! =
Antivirus protection is active.=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>>  =09
>>> This email is free from viruses and malware because avast! Antivirus =
protection is active. 		=09
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>>=20
>>=20
>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


--Apple-Mail=_07284753-C484-42C3-BE7E-060332E8D8DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Comments inline=85





On Oct 22, 2014, at 12:13 PM, Shelley <randomshelley@gmail.com> =
wrote:

Before any specific text is proposed, I'd =
like to get a general understanding for what the agreement/direction is. =
It seems there are still some major open questions that I'd appreciate =
some input on.
  • Should consumers be required to provide values =
in specific formats?
    • For example, for phone numbers, must =
consumers provide RFC 3966 format, an international format, any of =
multiple common/pre-defined formats, or is any value allowed? If not in =
RFC/international format, is the country/area code =
assumed?
  • Should service providers perform attribute =
validation or accept any values?
    • If service providers =
perform validation, what is the expected behavior when validation fails? =
(400 / ignore the value / store the value =
as-is?)
  • Particularly if there are no requirements for data =
input and/or no validation is performed:
    • What are the =
assumptions that service providers can make during =
canonicalization?
    • What should service providers / consumers do =
if canonicalization is not possible?
    • Should the use of both the =
"value" and "display" attributes be recommended?
There =
are minimally two major variations of possible changes on the table, =
with various flavors in between:
  • Require consumers to provide =
values in specified formats and SPs perform validation, rejecting =
invalid values
    • SCIM serves as a repository of well-formed, =
valid data. This results in the most usable data for SCIM consumers =
reading data, but puts some burden on SCIM consumers providing =
the data to conform.
-OR-
  • Allow consumers =
to provide values in any format, SP performs no validation though it may =
attempt perform canonicalization
    • SCIM serves as a =
repository of data from third parties, data may not be consistent, =
valid, or normalized. This results in the least effort for SCIM =
consumers providing data, but puts some burden on SCIM consumers =
reading the data to make sense of the data.
    • SCIM SPs may =
attempt to normalize some of the data, but there may be no =
guarantees with respect to the consistency or accuracy of these =
normalizations.
[PH - =
<individualHat/>] I prefer this because it aligns with Postel=92s =
Law.

I recommend stipulating that any =
modification to the supplied values (e.g. canonicalization) by the =
service providers MUST be reflected in the HTTP Response JSON =
representation (e.g. after a POST =
request). 

I think we also need to be =
clear about how 3966 ABNF elements should map to SCIM's multi-valued =
attribute representation for phoneNumbers. The earlier suggestion you =
made is on the right track (mapping to display, type, value, etc). =
 This might get a bit complex if for example the telephone number =
includes embedded parameters *and* the client already specifies type, =
value, and display representations.  My feeling is that the SP =
should always honour any assigned =93type=94 value by the client. =
 However, if the client does not assign a =93type=94, the SP could =
assign one based on parsing parameters. For example, say a client =
provides a value of "tel:7042;phone-context=3Dinternal=94.  The server might canonicalize/map =
as:

=93type=94:=94internal=94,
=93display=94:=947042=94,
=93value=94:"tel:7042;phone-context=3Dinternal=94

More generically, here is one possible mapping based =
on the ABNF from RFC3966 to phoneNumbers =
attribute:

=93value=94: =93{telephone-uri}=94
=93display=94:=94{global-number-digits / =
local-number-digits}=94
=93type=94:=94{descriptor}=94

SP=92s may attempt to canonicalize =93value=94 =
and normalize it. SPs may assign values to =93display=94 =
and =93type=94 if the client has not asserted values for these =
sub-attribues.

Regarding mapping of context and descriptor to =
SCIM type, we would be profiling 3966 to say that the ABNF =
 =93context=94 component is used and interpreted as a type. (can =
anybody confirm I have interpreted use of context in 3966 =
correctly?)


On Wed, Oct 22, =
2014 at 12:37 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
Shelley,

I think we =
are pretty much in agreement. Would you mind providing some new text for =
the definition of phoneNumbers?  I like where you are going with =
value vs. displayName etc.

It would be good to =
see how the group feels on a some new proposed =
text.

Thanks,



On Oct 22, 2014, at 10:22 AM, Shelley <randomshelley@gmail.com> =
wrote:

Thanks =
for the response, Phil.

 If the SP can understand the value, it may =
accept it.

Right, but what values can/should =
SPs attempt to "understand" since these aren't described in the spec? =
What assumptions, if any, can be made about the format provided by =
consumers? Further, what happens if the SP doesn't "accept" the value: =
400 response? value is silently ignored? value is stored, but not =
canonicalized?

Further it may modify the value to conform to =
RFC3966 and return the modified value in the HTTP =
response.

The problem here is that =
modifying the value is not always possible or may be done incorrectly =
depending on the format provided by the consumer.

Many service =
providers would rather accept the POST and simply ignore the value than =
to loose the transaction.

Silently =
ignoring unknown values seems a bit dangerous as well. I agree that the =
corrective action may be difficult to determine automatically if the =
transaction fails fast, but at least it brings some form of visibility =
to the problem.
 

On Wed, Oct 22, =
2014 at 11:39 AM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
Shelley,

Than=
ks for your comments and bringing this to the groups =
attention.

Overall, I would like to strike a balance =
in favour of being flexible in what is accepted.  If the SP can =
understand the value, it may accept it. Further it may modify the value =
to conform to RFC3966 and return the modified value in the HTTP =
response. For example a service provider should feel free to =
correct something in telephone-subscriber format to be returned as a URI =
instead.
=97> maybe Postel=92s Law is one of the general =
principles of SCIM that we should make more =
clearer?

I think one of the problems with 3966 is =
that it seems quite broadly defined. Enforcement may be quite valid. But =
will it improve quality of information given the complication it will =
cause for clients (e.g. when a request fails due to format, what is the =
corrective action)?  Many service providers would rather accept the =
POST and simply ignore the value than to loose the =
transaction.

I agree we should adjust the =
language a bit. For example, are we expecting a telephone-uri or a =
telephone-subscriber as the value?  The spec is not clear. =
 

There are also some other parts to 3966 =
which duplicate what we are doing in multi-valued attributes. For =
example the ABNF =93parameter=94 enables the following =
example: 
  tel:704=
2;phone-context=3Dexample.com
In this case, =
=93phone-context=94 could be seen as duplicative of the function of =
=93type=94.

Maybe it is not only that we want =
to following RFC3966, but we actually want to fully specify how 3966 is =
mapped to phoneNumber=92s multi-valued JSON =
structure?

Phil

@in=
dependentid
phil.hunt@oracle.com

=






On Oct 22, 2014, at 8:41 AM, Shelley <randomshelley@gmail.com> =
wrote:

I'd also like to clarify/highlight this =
problem/challenge with the current SCIM specification - the spec =
recommends that service providers canonicalize phone numbers to RFC =
3966, yet, if there are no requirements for the data provided by the =
consumer, this may be impossible.

In the extreme scenario, how =
can a SCIM SP canonicalize "not a phone number" to RFC 3966? In an =
incomplete scenario, how can an SP canonicalize "222-2222" without a =
country/area code? And in an ambiguous scenario, how can an SP =
canonicalize "201-5399 123" (where 123 is assumed to be an =
extension)?

While it may be possible for the SP to =
canonicalize some values under some assumptions (e.g. =
country code may be assumed, and assumptions based on patterns, etc), it =
is still possible that the canonicalization would be incorrect and in =
some cases, impossible.

How are other SPs handling this? Is =
anyone doing validation or canonicalization? 

Likewise, how =
are SCIM clients consuming phone numbers (especially those that may be =
read-only consumers of data and don't have visibility/control over the =
source data)? Is anyone doing any normalizing, validating, =
canonicalizing, or just leaving the data as-is regardless of the =
format/validity?


On Wed, Oct 22, =
2014 at 10:05 AM, Alex Redston <aredston@switchresearch.com> =
wrote:

 =20
   =20
 =20
  

    
Thanks - interesting link.

      
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

      On 22/10/2014 15:50, Shelley wrote:

    

    

      

        
The simplest approach would be to require SCIM consumers to
          provide phone numbers in the RFC 3966 format, which at least
          helps to guarantee the validity of the format and
          canonicalizes it into a standard global format consumable by
          both external systems and users. This also accounts for some
          of the scenarios you mentioned, such as sip calls.

          

        

        
As far as validating whether the phone number is actually a
          potentially valid number (based on country, area code, etc.),
          this can be discussed further/separately as well. I agree that
          validating whether a phone number is actually in service is
          probably not feasible but there are some standards and
          libraries that could potentially be used to deter
          completely bogus numbers [1], but the value in this may be
          debatable.

          

        

        
The overall problem is just that without centralized data
          validation in the service, SCIM consumers cannot rely on the
          syntax/validity of the data and therefore the burden of
          validating and normalizing falls to them.

        

        


          [1] https://code.google.com/p/libphonenumber/

          


            

            
On Tue, Oct 21, 2014 at 2:53 PM,
              Alex Redston <aredston@switchresearch.com>
              wrote:

              

                

                  
Of course the challenge here comes down to the
                    extent to which that particular data can be
                    standardised and validated. Taking phone numbers as
                    the example you have sip calls, invalid numbers,
                    country specific shortcodes, this is potentially a
                    minefield.

                    

                    Well formed and valid values are two distinct
                    concepts and with multiple carrier technologies the
                    anatomy of simple +4412345678901 style numbers is no
                    longer fit for purpose. For this reason I do not
                    think that it is feasible for this particular data
                    type to be rejected as bad data because the only way
                    to know if a phone number is valid is to dial =
it.

                    

                    What do you think?

                    

                    Alex

                    
Alex Redston

CEO
Switch Identity Governance Ltd
07973 320 795
020 3434 3888

                    

                      
 On 21/10/2014 20:36, Shelley wrote:

                      

                    

                  

                  

                    

                      

                        

                          
The SCIM specification expects service
                            providers should be able to canonicalize
                            provided data into a common format (e.g. RFC
                            3966 for phoneNumbers), yet
                            it does not explicitly describe input
                            requirements or validation for attributes
                            such as these. Is it expected that values
                              that cannot accurately be canonicalized
                              are rejected by the SCIM service or that
                              the SCIM service accepts this invalid data
                              and merely persists and returns this bad
                              data to consumers?

                            

                            As a SCIM Service Provider, we are currently
                            performing validation on attributes such as
                            phoneNumbers and emails
                            to ensure that they contain
                            well-formed, valid values, and returning a
                            400 with a description of the error if
                            validation fails. One of the benefits of
                            SCIM is that data may come from multiple
                            sources and may be consumed by multiple
                            clients, and SCIM provides a repository of
                            structured and well-formed data so that
                            consumers can reliably derive meaning and
                            use from this data. Without attribute
                            validation and a guarantee of canonicalized
                            values, this goal does not seem feasible and
                            puts the burden on consumers to make sense
                            of potentially invalid data.

                            

                            The downside to attribute validation is that
                            it requires the SCIM consumers sending data
                            to ensure valid data as well. As these
                            consumers are closest to the source data,
                            though, this seems like the most reasonable
                            approach rather than putting the burden on
                            the service provider and/or other SCIM
                            consumers to make sense of the data. Aside
                            from just "bad data" (e.g. sending "not a
                            phone number" or "000-0000" for a phone
                            number), for example, if the SCIM consumer
                            sending source data sends phone numbers
                            without area codes or sends only internal
                            extensions, another SCIM consumer may not be
                            able to make sense of this data. It seems
                            reasonable to require the consumer sending
                            the data to ensure that this data is
                            well-formed and
                            canonicalized/canonicalizable.

                            

                            A good example in the SCIM
                            specification is the country
                            attribute, which clearly indicates
                            the attribute's requirements. A bad =
example
                            is the phoneNumbers
                            attribute, which doesn't describe the
                            expected format to be provided by consumers,
                            yet recommends that the service provider
                            canonicalize the value even though the input
                            may not be able to be canonicalized.

                            

                          

                          I'd be interested in hearing others' opinions
                          on this matter, and whether the SCIM
                          specification should clarify further
                          restrictions on attribute values.

                        

                      

                      

                      

                      

                    

                  

                  

                  

                    
                      

                        
                          
                             =
 
                        

                            This email is free from viruses and malware
                            because avast! Antivirus
                            protection is active. 

                        		
                      

                    
                  

                  

                

              

            

            

          

        

      

    

    

 =20







	

		
			
				
			
		
		

				This email is free from viruses and =
malware because avast!=
 Antivirus protection is active.
			

				
	











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



=




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

=

--Apple-Mail=_07284753-C484-42C3-BE7E-060332E8D8DE--


From nobody Thu Oct 23 00:40: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 E137F1A88EE for ; Thu, 23 Oct 2014 00:40:52 -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 HoMj_REJQ1Du for ; Thu, 23 Oct 2014 00:40:50 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BCE1A88F8 for ; Thu, 23 Oct 2014 00:40:49 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id r20so1154019wiv.11 for ; Thu, 23 Oct 2014 00:40: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=vIljgCmKLVsNwDCV+4okMl6NR9xqNFmqTvVSojxOOS0=; b=dsSw+LZcKz7qC6pVEvpIaZqFKcZv9eyUdORQGk91DQRpYEXmg3PoaFxO2LKFv3+L9n RF2w1V0j90nE56YK5Lgwarx0xHi62gd+JfCGt/1xTPCcDSUcW0TcRDHb9Pm82hjpA6Bg VQmpa34u1d0LkG/pAI/vJhVVwK3EOT9mkHSTBbjeeVq8FG7u/phMDCbq9ar1zqp2IV9E XA45Y/iSAse09DwhzXlK4YX81XJNY5JYs17VmtRy5ajVjfrsESC27XQ3NN+9uxp/EATu mCcpqUDOVhZUtoTiDyn8nR/rUggAhUioWcuAWm7JCuEze2v/YP4FL1+/QR6RKDzZps1C XdeA==
X-Gm-Message-State: ALoCoQnn9jHwJ2CeJg2+HutRD4ozO0/dEw4lm7oskVwbM+3djlSeV+p3O7UoT9MqIyuJmAYndUTE
X-Received: by 10.195.12.162 with SMTP id er2mr3553666wjd.42.1414050048686; Thu, 23 Oct 2014 00:40:48 -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 ee3sm1620547wic.4.2014.10.23.00.40.47 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2014 00:40:47 -0700 (PDT)
Message-ID: <5448B0FE.1000606@tarent.de>
Date: Thu, 23 Oct 2014 09:40:46 +0200
From: =?windows-1252?Q?David_M=F6bius?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: scim@ietf.org
References: <942468554.2155399.1413906790620.JavaMail.zimbra@psu.edu>   <1634174574.753815.1413993871859.JavaMail.zimbra@psu.edu>
In-Reply-To: <1634174574.753815.1413993871859.JavaMail.zimbra@psu.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/1ET-ZnCHCFuwZ1nxrAgpUt18a0c
Subject: Re: [scim] address.display versus address.formatted
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, 23 Oct 2014 07:40:53 -0000

In our system the address attribute has a formatted value but no 
display. If you send a address with a display value it will be ignored.

All other multi values have the display field, even if it contains just 
the normal value like the email address.

David

On 22.10.2014 18:04, Steve Moyer wrote:
> I should also have noted that we haven't implemented all the attributes
> (the ones we didn't need) yet.  We do however have 2.5m users with an
> LDAP back-end currently available via both our v1 API (completely
> non-standard) and through the SCIM interface.  We've got some additional
> restrictions (on userName and externalId) that are specific to our
> system but we're working towards being compliant with the specification
> when it's ratified.
>
> If address.formatted and address.display are essentially the same thing,
> I'd be happy to change my system to use display so that address is
> consistent with all the other multi-valued attributes.  Can we drop
> address.formatted altogether?
>
> Steve
>
> --
>
> “The 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.” - Wilhelm Stekel
>
> ------------------------------------------------------------------------
> *From: *"Shelley" 
> *To: *"Phil Hunt" 
> *Cc: *"Steve Moyer" , scim@ietf.org
> *Sent: *Tuesday, October 21, 2014 3:45:56 PM
> *Subject: *Re: [scim] address.display versus address.formatted
>
> Our implementation does the same thing, such that we ignore the address
> "display" sub-attribute. Likewise, we do not support the "display"
> attribute for several other multi-valued attributes since it seems to
> provide no additional value beyond the "value" attribute:
>
>   * addresses
>   * emails
>   * phoneNumbers
>   * photos
>   * roles
>
> (We also currently ignore the ims, entitlements, and x509Certificates
> attributes completely since we have no use cases for these, but would
> likely ignore the "display" attribute for these attributes as well
> should we add support for these attributes.)
>
> On Tue, Oct 21, 2014 at 11:16 AM, Phil Hunt  > wrote:
>
>     +1
>
>     Thanks Steve.  Curious to hear what others have implemented too.
>
>     Phil
>
>     @independentid
>     www.independentid.com 
>     phil.hunt@oracle.com 
>
>
>
>     On Oct 21, 2014, at 8:53 AM, Steve Moyer      > wrote:
>
>      > Are the address.display attribute (inherited from SCIM
>     Multi-Valued Attribute) and the address.formatted attribute (part of
>     the address definition) ambiguous?  Can anyone provide insight into
>     how they're being used?  Our current implementation sets
>     address.formatted and ignores address.display but I'm curious to
>     know how others are populating these fields.
>      >
>      > Thanks,
>      >
>      > Steve
>      >
>      > --
>      >
>      > “The 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.” - Wilhelm Stekel
>      >
>      > _______________________________________________
>      > 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
>


From nobody Fri Oct 24 08:20:43 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 21D221A1A47 for ; Fri, 24 Oct 2014 08:20:32 -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 I8QCgnCvobgM for ; Fri, 24 Oct 2014 08:20:24 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520621A0368 for ; Fri, 24 Oct 2014 08:20:24 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p9so2717876lbv.21 for ; Fri, 24 Oct 2014 08:20:22 -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:content-type:content-transfer-encoding; bh=IqzGcuaI8YTYm6iOgAsXpPTnAxhXAogxjTZuK6zP9CA=; b=hEiy1fTdMeaNavIiHq1/P4VewZZaIZ1OTPQGbZr/zYFhfBZlEqLHqeJKVcPAaHBrWr n4Wuazqb48hqPzxP3Wqxue7Rzu1mRnaSTx7GRaquBI6sHrLQDz2BFhBZ++72I9YxE5o4 VRRXVNhxJkY6RqqOnPRqYx0Sn8dhEWqNFYPQqRbgfNAsH7U1UOebPAYnL0AjjlhUUpMz JfPIEweYhlzaYnUAfYLozg1N8qxoURmgFl+ps2fukbtAhBpaXjMLLxut0Du/ZZGb2Fy1 DJFCSKc9GeMA9prjd4S94cpxgoL6qt+Q2VSdfSZWfBlQkv2MQ3iMYXPTR7mZCKodqtMG EUUw==
X-Gm-Message-State: ALoCoQmhYFJYcc+WeRT/zVrJ4gUAtOXcc3iQRMj1vnh8NUtWeGTZrMVMrXNGP4ljl1av892if43I
X-Received: by 10.112.42.114 with SMTP id n18mr5312767lbl.44.1414164022373; Fri, 24 Oct 2014 08:20:22 -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 w2sm1950657lad.30.2014.10.24.08.20.21 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 08:20:21 -0700 (PDT)
Message-ID: <544A6E35.5090701@mnt.se>
Date: Fri, 24 Oct 2014 17:20:21 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "scim@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ro9JEToMtL8jQLH_owHzsZeDfg8
Subject: [scim] api and schema WGLC ended
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, 24 Oct 2014 15:20:32 -0000

With time allowed for intentional timezone vagueness of the WGLC the
time for comments is now over. The chairs will proceed to writeup and
submit  draft-ietf-scim-api-12 and draft-ietf-scim-core-schema-12 to
the IESG.

The chairs wishes to express our gratitude to the working group and to
Phil and Kelly in particular for all the work you have all put in to
take the SCIM protocol to this stage.

	Leif & Morteza


From nobody Fri Oct 24 09:20: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 B97501A1BFF for ; Fri, 24 Oct 2014 09:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSamXKet1E8a for ; Fri, 24 Oct 2014 09:19: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 69E521A1AB3 for ; Fri, 24 Oct 2014 09:19:59 -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 s9OGJvIu028980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Oct 2014 16:19:58 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 s9OGJtgL021670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 16:19:55 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9OGJt9d019343; Fri, 24 Oct 2014 16:19:55 GMT
Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Oct 2014 09:19:54 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt 
In-Reply-To: <544A6E35.5090701@mnt.se>
Date: Fri, 24 Oct 2014 09:19:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <544A6E35.5090701@mnt.se>
To: Leif Johansson 
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/WI3CW5YxQU2bIKCFZl942BkRGpE
Cc: "scim@ietf.org" 
Subject: Re: [scim] api and schema WGLC ended
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, 24 Oct 2014 16:20:01 -0000

My thanks to Kelly, Erik, Bjorn, Morteza, and Chuck for getting the =
specification going in the first place and even more for their regular =
help and participation to get the specs to where we are.

Thanks to everyone who attended meetings, conference calls, and =
participated on the mailing list! There were many times when we had some =
seemingly arbitrary or difficult decisions to make. Your broad input =
always helped me to find what the salient points were and helped us =
reach good consensus on the issues.

Thanks to Leif and Morteza for chairing the work and for providing sound =
guidance.

Cheers,

Phil

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



On Oct 24, 2014, at 8:20 AM, Leif Johansson  wrote:

>=20
> With time allowed for intentional timezone vagueness of the WGLC the
> time for comments is now over. The chairs will proceed to writeup and
> submit  draft-ietf-scim-api-12 and draft-ietf-scim-core-schema-12 to
> the IESG.
>=20
> The chairs wishes to express our gratitude to the working group and to
> Phil and Kelly in particular for all the work you have all put in to
> take the SCIM protocol to this stage.
>=20
> 	Leif & Morteza
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From nobody Fri Oct 24 10:41: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 BC13F1A8952 for ; Fri, 24 Oct 2014 10:41:50 -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 5o4K9XqCRNou for ; Fri, 24 Oct 2014 10:41:49 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F821A00E2 for ; Fri, 24 Oct 2014 10:41:48 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id 10so3194852lbg.0 for ; Fri, 24 Oct 2014 10:41:47 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZmWGgHkuUnZ9Kya4VsdUKx/D8WbxyhuOA+iLG8ldJzw=; b=ZOPOKE1FVVvYiqmuC3SbDWYjQcFegCdPq1tzwHfnv74c4j38nB/4QxHvj1M7RqC5fJ 6JN9ZpX9cbDPneec8R8e3AY0sMyrHsxEDBaKDgwES9LYoutUv3lcDPSMn9XygrQW18m9 1N3udfnP5e7LZy4cB5KPbuzMM+31x8Gi+mCWy5Nt7wTVVburImymmCN1v2EQ/4bhlcf/ B4PE4UexkjBFncWsqsd8nCBoN9RFISC2Ea3+HumIQW3KKYucWSWLu4DK5HFmPAcetNnx bB5yg1etN5GqXt2Nvmf0eHCIatQQ1iKqz/uP5m9/fZMTghJVL4YQBbi3dvgOqRRX9DNk LsVQ==
X-Gm-Message-State: ALoCoQnpgOLzEgRb2zlYVBVn4nr4G6jWOEIs9IG3rvkqMtKFEcsXLtou4T6jZXZ4t7ty27Jx9u/H
X-Received: by 10.112.198.226 with SMTP id jf2mr4867321lbc.84.1414172506933; Fri, 24 Oct 2014 10:41:46 -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 k16sm2072748laa.10.2014.10.24.10.41.46 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 10:41:46 -0700 (PDT)
Message-ID: <544A8F5A.7010103@mnt.se>
Date: Fri, 24 Oct 2014 19:41:46 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Phil Hunt 
References: <544A6E35.5090701@mnt.se> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/VBMm-Vzp0enlkmi2QvjHeq_Nglk
Cc: "scim@ietf.org" 
Subject: Re: [scim] api and schema WGLC ended
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, 24 Oct 2014 17:41:50 -0000

On 2014-10-24 18:19, Phil Hunt wrote:
> 
> My thanks to Kelly, Erik, Bjorn, Morteza, and Chuck for getting the specification going in the first place and even more for their regular help and participation to get the specs to where we are.
> 
> Thanks to everyone who attended meetings, conference calls, and participated on the mailing list! There were many times when we had some seemingly arbitrary or difficult decisions to make. Your broad input always helped me to find what the salient points were and helped us reach good consensus on the issues.
> 
> Thanks to Leif and Morteza for chairing the work and for providing sound guidance.
> 

Ok thats enough congratulation - time for everyone to spin out all of
those extension drafts I know you've all got lying around  :-)

	Cheers Leif


From nobody Tue Oct 28 22:31:43 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 B4C9F1A008F for ; Tue, 28 Oct 2014 22:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.099
X-Spam-Level: **
X-Spam-Status: No, score=2.099 tagged_above=-999 required=5 tests=[BAYES_60=1.5, J_CHICKENPOX_37=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 VWi1VOLM_RIS for ; Tue, 28 Oct 2014 22:31:42 -0700 (PDT)
Received: from c15s9xb8.securesites.net (c15s9xb8.securesites.net [118.23.75.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EC01A001E for ; Tue, 28 Oct 2014 22:31:41 -0700 (PDT)
Received: from [192.168.2.236] (122x220x11x94.ap122.ftth.ucom.ne.jp [122.220.11.94]) (authenticated bits=0) by c15s9xb8.securesites.net (8.14.5/8.13.1) with ESMTP id s9T5Vbwm028641 for ; Wed, 29 Oct 2014 14:31:40 +0900
MIME-Version: 1.0
Date: Wed, 29 Oct 2014 14:31:37 +0900
Message-ID: 
From: ueda@exgen.co.jp
To: scim@ietf.org
X-Mailer: JsvMail 9.0 (Shuriken 2009)
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/dlhRcOgpIR-Ij0-a4ov7hfbAWPo
Subject: [scim] schemas,id,meta returnd always?
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, 29 Oct 2014 05:31:42 -0000

Hello

I have a question.

I thinks "schemas","id","meta" attribute are returnd "always".

In the example response at section 3.2.2(page 11) of api document,
there are no "schemas","id","meta" attribute.
but,example response at section 3.7(page 59) has "schemas","id","meta" attribute.

Which is right?

-
Takanori Ueda.