From matthew.a.randall@gmail.com Mon Sep 30 09:04:18 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA621F9BD0 for ; Mon, 30 Sep 2013 09:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OojGhHWm2Doi for ; Mon, 30 Sep 2013 09:04:17 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A589721F9BB1 for ; Mon, 30 Sep 2013 09:04:04 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so4182900veb.37 for ; Mon, 30 Sep 2013 09:04:04 -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=WXwqh09uSbsKYo4nFc5R+C/M2Si8BGjRCza2bu8qRz4=; b=LhJynxwUrzg3LguiY/epC+r4Ti9Q7VpTAhS4zgywPvflYUwwwtiSVAqfsBko4UbK8h dF4rNVtSrahJnpS+jkIMsNJtRppzeIG/Qpv9ntnCSOjyZpqv6q7O2wTvy9mG/2b499H0 40FOmEEQpGZ+BrOL22Mf3KkkC6Pi8FjupGk+7uMyaGRRvXCkFZ2KOBpOramvqo4xVSEA Qzow0Vs0eoaSNGVp1CSJSChcxidPEgPUoFOVFJ0EneYtfq+Z0iFR7Bmutvfr92aRuFJi +UiN9A5zBMVSwjTIVwlhGE5tRzX5v9YjBqKX+vzvtYaY4WaHUwkRX44cwvMf8/QwkCKI Y6ig== MIME-Version: 1.0 X-Received: by 10.52.243.138 with SMTP id wy10mr2453749vdc.2.1380557044128; Mon, 30 Sep 2013 09:04:04 -0700 (PDT) Received: by 10.220.162.136 with HTTP; Mon, 30 Sep 2013 09:04:04 -0700 (PDT) Date: Mon, 30 Sep 2013 11:04:04 -0500 Message-ID: From: Matt Randall To: scim@ietf.org Content-Type: multipart/alternative; boundary=001a11c1c4a635231f04e79bfc02 Subject: [scim] Group Schema and use cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:10:56 -0000 --001a11c1c4a635231f04e79bfc02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I=92ve observed that there aren=92t many use cases documented around the us= e of groups [1] within the SCIM specification. Is this something the working group needs contributions to from large cloud service providers? My team has found it difficult in practice to make use of this portion of the schema without extension, which we=92re concerned may increase the difficul= ty for ECS=92 to integrate with our service. Specifically, displayName per it= s name and documentation indicates that it must be a human-readable name for a group, and is not required to be unique. Without additional extension, consumers are forced either populate groups whose display names are used as a keying mechanism, or manually associate them via separate administrative tooling. For large numbers of groups, this can impart a significant administrative burden. A fictitious example of such a group: =93Applicati= on-A Region-1 Business-Administrators=94. The usage of displayName as a key wil= l potentially complicate integration with multilingual cloud subscribers as well. We=92d be delighted to have a dialogue on this topic with any interested parties. [1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00 Matt Randall --001a11c1c4a635231f04e79bfc02 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I=92ve observed that there aren=92t many use cases documented around the use of groups [1] within the SCIM specification.=A0 = Is this something the working group needs contributions to from large cloud service providers?=A0 = My team has found it difficult in practice to make use of this portion of the schema without extension, which we=92re con= cerned may increase the difficulty for ECS=92 to integrate with our service.=A0 Specifically, displayName per its name and documentation indicates that it must be a human-readable name for a group, = and is not required to be unique.=A0 Without additional extension, consumers are forced either populate groups whose dis= play names are used as a keying mechanism, or manually associate them via separa= te administrative tooling.=A0 For large numbers of groups, this can impart a significant administrative burden.=A0 = A fictitious example of such a group:=A0 =93Application-= A Region-1 Business-Administrators=94.=A0 The usage of d= isplayName as a key will potentially complicate integration with multilingual cloud subscribers as well.

=A0

We=92d be delighted to have a dialogue on this topic with any interested parties.

=A0

[1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00

<= p class=3D"">

Matt Randall

--001a11c1c4a635231f04e79bfc02-- From phil.hunt@oracle.com Tue Oct 1 10:11:01 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9111A11E81B4 for ; Tue, 1 Oct 2013 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N-fmZGXDgoC for ; Tue, 1 Oct 2013 10:10:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E16D611E8153 for ; Tue, 1 Oct 2013 10:10:47 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r91HAjLi004532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 17:10:45 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 r91HAiOh025180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 17:10:44 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r91HAh5B002879; Tue, 1 Oct 2013 17:10:43 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Oct 2013 10:10:43 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-FA0679D1-A7BB-47C2-A715-2E0FDB097354 Content-Transfer-Encoding: 7bit Message-Id: <171080FD-C4E3-4DA9-A47D-2EF09C3302C7@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Tue, 1 Oct 2013 10:10:42 -0700 To: Matt Randall X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" Subject: Re: [scim] Group Schema and use cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:11:01 -0000 --Apple-Mail-FA0679D1-A7BB-47C2-A715-2E0FDB097354 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not sure what the issue here is. DisplayName is informational only since it i= s member that must be unique within the group.=20 displayName is there to save look ups when displaying a group member in a UI= -this is why it is supposed to be human readable.=20 If you need another attribute like uid, that would be an extension.=20 Phil > On Sep 30, 2013, at 9:04, Matt Randall wrote= : >=20 > I=E2=80=99ve observed that there aren=E2=80=99t many use cases documented a= round the use of groups [1] within the SCIM specification. Is this somethin= g the working group needs contributions to from large cloud service provider= s? My team has found it difficult in practice to make use of this portion o= f the schema without extension, which we=E2=80=99re concerned may increase t= he difficulty for ECS=E2=80=99 to integrate with our service. Specifically,= displayName per its name and documentation indicates that it must be a huma= n-readable name for a group, and is not required to be unique. Without addi= tional extension, consumers are forced either populate groups whose display n= ames are used as a keying mechanism, or manually associate them via separate= administrative tooling. For large numbers of groups, this can impart a sig= nificant administrative burden. A fictitious example of such a group: =E2=80= =9CApplication-A Region-1 Business-Administrators=E2=80=9D. The usage of di= splayName as a key will potentially complicate integration with multilingual= cloud subscribers as well. >=20 > =20 >=20 > We=E2=80=99d be delighted to have a dialogue on this topic with any intere= sted parties. >=20 > =20 >=20 > [1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00 >=20 >=20 >=20 > Matt Randall >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-FA0679D1-A7BB-47C2-A715-2E0FDB097354 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not sure what the issue here is. Displ= ayName is informational only since it is member that must be unique within t= he group. 

displayName is there to save look u= ps when displaying a group member in a UI-this is why it is supposed to be h= uman readable. 

If you need another attribute l= ike uid, that would be an extension. 

Phil

= On Sep 30, 2013, at 9:04, Matt Randall <matthew.a.randall@gmail.com> wrote:

I=E2=80=99ve observed that there aren=E2=80=99t many use cases= documented around the use of groups [1] within the SCIM specification.=   Is this something the working group needs contributions to from large cloud service providers?  <= /span>My team has found it difficult in practice to make use of this portion of the schema without extension, which we=E2=80=99r= e concerned may increase the difficulty for ECS=E2=80=99 to integrate with our service.<= span style=3D"">  Specifically, displayName per its name and documentation indicates that it must be a human-readable name for a group, a= nd is not required to be unique.  Without additional extension, consumers are forced either populate groups whose disp= lay names are used as a keying mechanism, or manually associate them via separat= e administrative tooling.  For large numbers of groups, this can impart a significant administrative burden.  <= /span>A fictitious example of such a group:  =E2= =80=9CApplication-A Region-1 Business-Administrators=E2=80=9D.  The usage of displayName as a key will potentially complicate integration with multilingual cloud subscribers as well.

 

We=E2=80=99d be delighted to have a dialogue on this topic wit= h any interested parties.

 

[1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00


Matt Randall

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-FA0679D1-A7BB-47C2-A715-2E0FDB097354-- From matthew.a.randall@gmail.com Tue Oct 1 16:52:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953891F0D57 for ; Tue, 1 Oct 2013 16:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqWt7UAh-DQo for ; Tue, 1 Oct 2013 16:52:48 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB5E1F0D5E for ; Tue, 1 Oct 2013 16:52:38 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so43292veb.31 for ; Tue, 01 Oct 2013 16:52:36 -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=ACjTaTEFCmyfeYFHr1Ug71gqAGAyi7P2gBIGnq/RbQY=; b=DGBZH4I5xtlrMGJFHted8La+HsWR3gO6hHOoQicb0hqYWyoaJYx/v/KUZe2Bykkwu4 j+odFfMWmsluO6VozLFuvOfwmm1n4jmIaIUDk1aCq2g0u+A75FcFW0LU6B8Or9Oy78VP YWfq/dDUW8GmOAFuF+Mbm7IuG/YaKMNs/gY52uqWtCtf0PYF0u/Z6hvloTKcwqpi6cWQ EGweWKqiWCjLw5ShuqNKesxr8PAldiJFXRr/6Khbqfoy3DY5N97D8oSfmQnHu4cXZu9W LTCbZzaEWmEpTsxPC7b+to16JF1ESaRNpUxymIKv+haiaBhGP/nZB3jSmlH3TmR2/cXY ya7w== MIME-Version: 1.0 X-Received: by 10.52.120.78 with SMTP id la14mr25997116vdb.9.1380671556085; Tue, 01 Oct 2013 16:52:36 -0700 (PDT) Received: by 10.221.38.138 with HTTP; Tue, 1 Oct 2013 16:52:36 -0700 (PDT) In-Reply-To: <171080FD-C4E3-4DA9-A47D-2EF09C3302C7@oracle.com> References: <171080FD-C4E3-4DA9-A47D-2EF09C3302C7@oracle.com> Date: Tue, 1 Oct 2013 18:52:36 -0500 Message-ID: From: Matt Randall To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f234635a6ec1404e7b6a5ef Subject: Re: [scim] Group Schema and use cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 23:52:55 -0000 --e89a8f234635a6ec1404e7b6a5ef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As you've noted, to make use of groups in the majority of our use cases we've had to use an extension. I'm trying to understand the use cases where the current specification provides direct value without extension, as no documentation exists for them. Is it envisioned that groups can be used for making authorization decisions when supplemented with secondary out-of-band administrative user interfaces for performing mapping? Would a scenario exist where a cloud service provider would pre-populate a subscriber's scim repository with pre-defined groups that represent access control lists? The current specification has no mechanism that allows a cloud service provider to derive meaning from a group without either extension or one of the following: - A separate out-of-band mechanism - Deriving meaning from the displayName property - Pre-populating a subscriber's repository with predefined groups How are service providers here approaching the usage of groups? On Tue, Oct 1, 2013 at 12:10 PM, Phil Hunt wrote: > Not sure what the issue here is. DisplayName is informational only since > it is member that must be unique within the group. > > displayName is there to save look ups when displaying a group member in a > UI-this is why it is supposed to be human readable. > > If you need another attribute like uid, that would be an extension. > > Phil > > On Sep 30, 2013, at 9:04, Matt Randall > wrote: > > I=92ve observed that there aren=92t many use cases documented around the = use > of groups [1] within the SCIM specification. Is this something the > working group needs contributions to from large cloud service providers? = My > team has found it difficult in practice to make use of this portion of th= e > schema without extension, which we=92re concerned may increase the diffic= ulty > for ECS=92 to integrate with our service. Specifically, displayName per > its name and documentation indicates that it must be a human-readable nam= e > for a group, and is not required to be unique. Without additional > extension, consumers are forced either populate groups whose display name= s > are used as a keying mechanism, or manually associate them via separate > administrative tooling. For large numbers of groups, this can impart a > significant administrative burden. A fictitious example of such a group: > =93Application-A Region-1 Business-Administrators=94. The usage of > displayName as a key will potentially complicate integration with > multilingual cloud subscribers as well. > > > > We=92d be delighted to have a dialogue on this topic with any interested > parties. > > > > [1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00 > > > Matt Randall > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --e89a8f234635a6ec1404e7b6a5ef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
As you've noted, to make use of groups in th= e majority of our use cases we've had to use an extension.=A0 I'm t= rying to understand the use cases where the current specification provides = direct value without extension, as no documentation exists for them.=A0=A0 = Is it envisioned that groups can be used for making authorization decisions= when supplemented with secondary out-of-band administrative user interface= s for performing mapping?=A0 Would a scenario exist where a cloud service p= rovider would pre-populate a subscriber's scim repository with pre-defi= ned groups that represent access control lists?=A0

The current specification has no mechanism that allows a cloud se= rvice provider to derive meaning from a group without either extension or o= ne of the following:

- A separate out-of-band mechanism
- Derivin= g meaning from the displayName property
- Pre-populating a subscriber's repository with predefined groups
How are service providers here approaching the usage of groups?
=


On Tue,= Oct 1, 2013 at 12:10 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Not sure what the iss= ue here is. DisplayName is informational only since it is member that must = be unique within the group.=A0

displayName is there to save look ups when displaying a= group member in a UI-this is why it is supposed to be human readable.=A0

If you need another attribute like uid, that would = be an extension.=A0

Phil

On Sep 30, 2013, at 9:04= , Matt Randall <matthew.a.randall@gmail.com> wrote:

I=92ve observed that there aren=92t many use cases documented around the use of groups [1] within the SCIM specification.=A0 Is this something the working group needs contributions to from large cloud service providers?=A0 My tea= m has found it difficult in practice to make use of this portion of the schema without extension, which we=92re con= cerned may increase the difficulty for ECS=92 to integrate with our service.= =A0 Specifically, displayName per its name and documentation indicates that it must be a human-readable name for a group, = and is not required to be unique.=A0 Without additional extension, consumers are forced either populate groups whose dis= play names are used as a keying mechanism, or manually associate them via separa= te administrative tooling.=A0 For large numbers of groups, this can impart a significant administrative burden.=A0 A fict= itious example of such a group:=A0 =93Application-A Region-1 B= usiness-Administrators=94.=A0 The usage of displayName as a ke= y will potentially complicate integration with multilingual cloud subscribers as well.

=A0

We=92d be delighted to have a dialogue on this topic with any interested parties.

=A0

[1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00


Matt Randall


--e89a8f234635a6ec1404e7b6a5ef-- From nguydthuan@hotmail.com Tue Oct 1 20:28:37 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED75021E8268 for ; Tue, 1 Oct 2013 20:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmrmeuomV+lV for ; Tue, 1 Oct 2013 20:28:26 -0700 (PDT) Received: from bay0-omc2-s10.bay0.hotmail.com (bay0-omc2-s10.bay0.hotmail.com [65.54.190.85]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF421E826C for ; Tue, 1 Oct 2013 20:28:17 -0700 (PDT) Received: from BAY168-W67 ([65.54.190.124]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Oct 2013 20:28:17 -0700 X-TMN: [E9owuIAC2Y+T2eHOc3deIxDrwdCU1lfn] X-Originating-Email: [nguydthuan@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_228820ee-d6bc-4d95-a66b-b1b2cb3c0115_" From: Duc Thuan Nguy To: "scim@ietf.org" Date: Wed, 2 Oct 2013 10:28:17 +0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2013 03:28:17.0428 (UTC) FILETIME=[6F67AD40:01CEBF1F] Subject: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 03:28:38 -0000 --_228820ee-d6bc-4d95-a66b-b1b2cb3c0115_ Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: base64 CgpIaSBTQ0lNIGdyb3VwcywKCihJIHJlc2VuZCB0aGlzIGVtYWlsIGJlY2F1c2UgaXQgc2VlbXMg dGhlIGZpcnN0IG9uZSBnb3QgbG9zdApzb21ld2hlcmUuIFBlcmhhcHMgaXQgaXMgYmVjYXVzZSBJ IHNlbnQgaXQgZnJvbSBhbm90aGVyIGVtYWlsIGFjY291bnQgd2hpY2ggd2Fzbid0IHN1YnNjcmli ZWQgdG8gdGhlIFNDSU0gZ3JvdXAuIFRoaXMgZW1haWwgYWltcyB0byBjb3JyZWN0IHRoYXQgbWlz dGFrZSkgCgpPdXIgY29tcGFueSB3YW50cyB0byBpbXBsZW1lbnQgU0NJTSAxLjEgZm9yIG91ciBp ZGVudGl0eQptYW5hZ2VtZW50IHByb2R1Y3QuIEkgdGhpbmsgU0NJTSBpcyBncmVhdCB5ZXQgc2lt cGxlIGZyYW1ld29yayBhbmQgaXMgdmVyeQplYWdlciB0byBpbXBsZW1lbnQgaXQuIEhvd2V2ZXIs IEkgZmluZCBvbmUgcHJvYmxlbSB3aGVuIEkgdHJ5IHRvIGFkb3B0IFNDSU0gZm9yCm91ciBzeXN0 ZW06IHNpbXBseSBzcGVha2luZywgb3VyIHN5c3RlbSBzdXBwb3J0cyBtdWx0aXBsZSB1c2VybmFt ZXMuIEluIG90aGVyCndvcmRzLCBvbmUgdXNlciBjYW4gaGF2ZSBtb3JlIHRoYW4gb25lIHVzZXJu YW1lcywgZm9yIGV4YW1wbGU6CgotICAgICAgICAgClVzZXJuYW1lX2FzX3VzZXJuYW1lOiBiamVu c2VuLgoKLSAgICAgICAgIApFbWFpbF9hc191c2VybmFtZTogYmplbnNlbkBleGFtcGxlLmNvbQoK QSB1c2VyIGNhbiB1c2UgYW55IG9mIHRoZSCTdXNlcm5hbWWUIHRvIGxvZ2luLgoKIAoKQXMgYSBj b25zZXF1ZW50LCB3aGVuIGEgY3JlYXRlIHVzZXIgcmVxdWVzdCBuZWVkcyB0byBzcGVjaWZ5Cm5v dCBvbmx5IGEgdXNlcm5hbWUgYnV0IGFsc28gdGhlIHR5cGUgb2YgdGhhdCB1c2VybmFtZS4gVW5m b3J0dW5hdGVseSwgSQpjb3VsZG6SdCBmaW5kIGFueSBwcmVkZWZpbmVkIFNDSU0gYXR0cmlidXRl IHdoaWNoIGNhbiBiZSB1c2VkIGZvciB0aGF0IJN0eXBlIG9mCnVzZXJuYW1llC4KCiAKCkkgY2Fu IHRoaW5rIG9mIGEgZmV3IG9wdGlvbnM6CgogCgpBIHN0YW5kYXJkIFNDSU0gY3JlYXRlIHVzZXIg cmVxdWVzdDoKCiAgCnsKCiAgICAKInNjaGVtYXMiOlsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEu MCJdLAoKICAgIAoidXNlck5hbWUiOiJiamVuc2VuIiwKCiAgICAKImV4dGVybmFsSWQiOiJiamVu c2VuIiwKCiAgICAKIm5hbWUiOnsKCiAgICAgIAoiZm9ybWF0dGVkIjoiTXMuIEJhcmJhcmEgSiBK ZW5zZW4gSUlJIiwKCiAgICAgIAoiZmFtaWx5TmFtZSI6IkplbnNlbiIsCgogICAgICAKImdpdmVu TmFtZSI6IkJhcmJhcmEiCgogICAgCn0KCiAgCn0KCiAKCkFwcHJvYWNoIDE6IGV4dGVuZGVkIFND SU0gY3JlYXRlIHVzZXIgcmVxdWVzdDoKCiAgCnsKCiAgICAKInNjaGVtYXMiOlsidXJuOnNjaW06 c2NoZW1hczpjb3JlOjEuMCJdLAoKICAgIAoidXNlck5hbWUiOiJiamVuc2VuIiwKCiAgICAKImV4 dGVybmFsSWQiOiJiamVuc2VuIiwKCiAgICAKIm5hbWUiOnsKCiAgICAgIAoiZm9ybWF0dGVkIjoi TXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwKCiAgICAgIAoiZmFtaWx5TmFtZSI6IkplbnNlbiIs CgogICAgICAKImdpdmVuTmFtZSI6IkJhcmJhcmEiCgogICAgCn0KCiAgICAKInVybjpzY2ltOnNj aGVtYXM6ZXh0ZW5zaW9uOm91cnByb2R1Y3RuYW1lOjEuMCI6ewoKICAgICAgICAgICAgICAgCiJ1 c2VyTmFtZVR5cGUiOiJlbWFpbF9hc191c2VybmFtZSIsCgogIAogIH0KCiAgCn0KCiAKCkFwcHJv YWNoIDI6IGRlZmluZSBzZXBhcmF0ZSBlbmRwb2ludCBmb3IgZWFjaCB1c2VybmFtZSB0eXBlOgph biBlbmRwb2ludCB0byBjcmVhdGUgYSB1c2VyIHdpbGwgbG9vayBsaWtlOiBodHRwczovL2V4YW1w bGUuY29tL2VtYWlsX2FzX3VzZXJuYW1lL3YxL1VzZXJzCgogCgpBcHByb2FjaCAzOiBBc2sgdGhl IGNsaWVudCBkZXZlbG9wZXIgdG8gYXBwZW5kIGEKk3VzZXJOYW1lVHlwZT2FlCBwYXJhbWV0ZXIg dG8gdGhlIGVuZCBvZiB0aGUgcmVxdWVzdC4KCiAKCkNvdWxkIHlvdSBwbGVhc2UgdGVsbCBtZSBp ZiBhbnkgb2YgdGhlIGFwcHJvYWNoZXMgYWJvdmUgYXJlClNDSU0gY29tcGxpYW50IGFuZCB1c2Fi bGU/IFdoYXQgYWx0ZXJuYXRpdmVzIGRvIEkgaGF2ZT8KCiAKClRoYW5rIHlvdSBpbiBhZHZhbmNl LAoKTmd1eSBEdWMgVGh1YW4uCgogCQkgCSAgIAkJICA= --_228820ee-d6bc-4d95-a66b-b1b2cb3c0115_ Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwv Zm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPkhp IFNDSU0gZ3JvdXBzLDxvOnA+PC9vOnA+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7 Ij4oSSByZXNlbmQgdGhpcyBlbWFpbCBiZWNhdXNlIGl0IHNlZW1zIHRoZSBmaXJzdCBvbmUgZ290 IGxvc3QKc29tZXdoZXJlLiBQZXJoYXBzIGl0IGlzIGJlY2F1c2UgSSBzZW50IGl0IGZyb20gYW5v dGhlciBlbWFpbCBhY2NvdW50IHdoaWNoIHdhc24ndCBzdWJzY3JpYmVkIHRvIHRoZSBTQ0lNIGdy b3VwLiBUaGlzIGVtYWlsIGFpbXMgdG8gY29ycmVjdCB0aGF0IG1pc3Rha2UpPC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+PG86cD48L286cD4mbmJz cDs8L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPk91ciBjb21wYW55IHdhbnRzIHRv IGltcGxlbWVudCBTQ0lNIDEuMSBmb3Igb3VyIGlkZW50aXR5Cm1hbmFnZW1lbnQgcHJvZHVjdC4g SSB0aGluayBTQ0lNIGlzIGdyZWF0IHlldCBzaW1wbGUgZnJhbWV3b3JrIGFuZCBpcyB2ZXJ5CmVh Z2VyIHRvIGltcGxlbWVudCBpdC4gSG93ZXZlciwgSSBmaW5kIG9uZSBwcm9ibGVtIHdoZW4gSSB0 cnkgdG8gYWRvcHQgU0NJTSBmb3IKb3VyIHN5c3RlbTogc2ltcGx5IHNwZWFraW5nLCBvdXIgc3lz dGVtIHN1cHBvcnRzIG11bHRpcGxlIHVzZXJuYW1lcy4gSW4gb3RoZXIKd29yZHMsIG9uZSB1c2Vy IGNhbiBoYXZlIG1vcmUgdGhhbiBvbmUgdXNlcm5hbWVzLCBmb3IgZXhhbXBsZTo8bzpwPjwvbzpw PjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdCAwLjc1aW47IHRleHQtaW5k ZW50OiAtMC4yNWluOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7Ij48IS0tW2lmICFzdXBwb3J0 TGlzdHNdLS0+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt c28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDogSWdu b3JlOyI+LTxzcGFuIHN0eWxlPSdmb250OiA3cHQvbm9ybWFsICJUaW1lcyBOZXcgUm9tYW4iOyBm b250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IS0tW2VuZGlmXS0tPlVzZXJuYW1lX2FzX3VzZXJuYW1lOiBiamVuc2VuLjxvOnA+ PC9vOnA+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0IDAuNzVpbjsgdGV4 dC1pbmRlbnQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IENhbGli cmk7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 OiBJZ25vcmU7Ij4tPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3JtYWwgIlRpbWVzIE5ldyBSb21h biI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyc+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+RW1haWxfYXNfdXNlcm5hbWU6IDxhIGhyZWY9Im1h aWx0bzpiamVuc2VuQGV4YW1wbGUuY29tIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+YmplbnNlbkBl eGFtcGxlLmNvbTwvZm9udD48L2E+PG86cD48L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDBwdDsiPkEgdXNlciBjYW4gdXNlIGFueSBvZiB0aGUgk3VzZXJuYW1llCB0byBsb2dpbi48 bzpwPjwvbzpwPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+PG86cD4mbmJzcDs8 L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPkFzIGEgY29uc2VxdWVudCwg d2hlbiBhIGNyZWF0ZSB1c2VyIHJlcXVlc3QgbmVlZHMgdG8gc3BlY2lmeQpub3Qgb25seSBhIHVz ZXJuYW1lIGJ1dCBhbHNvIHRoZSB0eXBlIG9mIHRoYXQgdXNlcm5hbWUuIFVuZm9ydHVuYXRlbHks IEkKY291bGRuknQgZmluZCBhbnkgcHJlZGVmaW5lZCBTQ0lNIGF0dHJpYnV0ZSB3aGljaCBjYW4g YmUgdXNlZCBmb3IgdGhhdCCTdHlwZSBvZgp1c2VybmFtZZQuPG86cD48L286cD48L3A+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwcHQ7Ij5JIGNhbiB0aGluayBvZiBhIGZldyBvcHRpb25zOjxvOnA+PC9v OnA+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+QSBzdGFuZGFyZCBTQ0lNIGNyZWF0ZSB1 c2VyIHJlcXVlc3Q6PG86cD48L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4K CjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsg cGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1m YW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOOyc+Jm5ic3A7Jm5ic3A7Cns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDBwdDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNv LWFuc2ktbGFuZ3VhZ2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJzY2hlbWFzIjpb InVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTog MTJwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJ1 c2VyTmFtZSI6ImJqZW5zZW4iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0OyBtc28t YW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKImV4dGVybmFsSWQi OiJiamVuc2VuIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDBwdDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0n Zm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJuYW1lIjp7PG86cD48L286cD48 L3NwYW4+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IHBhZ2UtYnJlYWstYmVmb3Jl OiBhbHdheXM7Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBO ZXciOyBmb250LXNpemU6IDEycHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTjsnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwoiZm9ybWF0dGVkIjoiTXMuIEJhcmJhcmEgSiBKZW5z ZW4gSUlJIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBw dDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9u dC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNvLWFuc2ktbGFuZ3Vh Z2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJmYW1pbHlOYW1l IjoiSmVuc2VuIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDBwdDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0n Zm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJnaXZlbk5h bWUiOiJCYXJiYXJhIjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKfTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3 YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Ijsg Zm9udC1zaXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsKfTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+PG86cD4m bmJzcDs8L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPkFwcHJvYWNoIDE6 IGV4dGVuZGVkIFNDSU0gY3JlYXRlIHVzZXIgcmVxdWVzdDo8bzpwPjwvbzpwPjwvcD48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAx MnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsKezxvOnA+PC9vOnA+PC9z cGFuPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTog YWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3 IjsgZm9udC1zaXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKInNjaGVtYXMiOlsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFr LWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNv dXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsKInVzZXJOYW1lIjoiYmplbnNlbiIsPG86cD48L286cD48L3Nw YW4+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IHBhZ2UtYnJlYWstYmVmb3JlOiBh bHdheXM7Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXci OyBmb250LXNpemU6IDEycHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTjsnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOwoiZXh0ZXJuYWxJZCI6ImJqZW5zZW4iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1z aXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKIm5hbWUiOns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDBwdDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0n Zm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiJmb3JtYXR0 ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXpl OiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKImZhbWlseU5hbWUiOiJKZW5zZW4iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1z aXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsKImdpdmVuTmFtZSI6IkJhcmJhcmEiPG86cD48L286cD48L3NwYW4+PC9w Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7 Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250 LXNpemU6IDEycHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTjsnPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwp9PG86cD48L286cD48L3NwYW4+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7 IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQt ZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7IG1zby1hbnNpLWxhbmd1YWdl OiBFTjsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwoidXJuOnNjaW06c2NoZW1hczpleHRlbnNp b246b3VycHJvZHVjdG5hbWU6MS4wIjp7PG86cD48L286cD48L3NwYW4+PC9wPjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwcHQ7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48c3BhbiBsYW5n PSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTjsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OwoidXNlck5hbWVUeXBlIjoiZW1haWxfYXNfdXNlcm5hbWUiLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9u dC1zaXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU47Jz4mbmJzcDsmbmJzcDsKJm5ic3A7 Jm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0 OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250 LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0OyBtc28tYW5zaS1sYW5ndWFn ZTogRU47Jz4mbmJzcDsmbmJzcDsKfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMHB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDBwdDsiPkFwcHJvYWNoIDI6IGRlZmluZSBzZXBhcmF0ZSBlbmRwb2ludCBmb3IgZWFj aCB1c2VybmFtZSB0eXBlOgphbiBlbmRwb2ludCB0byBjcmVhdGUgYSB1c2VyIHdpbGwgbG9vayBs aWtlOiA8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL2VtYWlsX2FzX3VzZXJuYW1lL3YxL1Vz ZXJzIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+aHR0cHM6Ly9leGFtcGxlLmNvbS9lbWFpbF9hc191 c2VybmFtZS92MS9Vc2VyczwvZm9udD48L2E+PG86cD48L286cD48L3A+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDBwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwcHQ7Ij5BcHByb2FjaCAzOiBBc2sgdGhlIGNsaWVudCBkZXZlbG9wZXIgdG8gYXBwZW5k IGEKk3VzZXJOYW1lVHlwZT2FlCBwYXJhbWV0ZXIgdG8gdGhlIGVuZCBvZiB0aGUgcmVxdWVzdC48 bzpwPjwvbzpwPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+PG86cD4mbmJzcDs8 L286cD48L3A+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPkNvdWxkIHlvdSBwbGVhc2Ug dGVsbCBtZSBpZiBhbnkgb2YgdGhlIGFwcHJvYWNoZXMgYWJvdmUgYXJlClNDSU0gY29tcGxpYW50 IGFuZCB1c2FibGU/IFdoYXQgYWx0ZXJuYXRpdmVzIGRvIEkgaGF2ZT88bzpwPjwvbzpwPjwvcD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsiPlRoYW5rIHlvdSBpbiBhZHZhbmNlLDxvOnA+PC9vOnA+ PC9wPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7Ij5OZ3V5IER1YyBUaHVhbi48bzpwPjwv bzpwPjwvcD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PiAJCSAJICAgCQkg IDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_228820ee-d6bc-4d95-a66b-b1b2cb3c0115_-- From prvs=3987E2B147=erik.wahlstrom@nexusgroup.com Wed Oct 2 00:47:21 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F261911E814D for ; Wed, 2 Oct 2013 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ormd9kBmkMJ for ; Wed, 2 Oct 2013 00:47:09 -0700 (PDT) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 83ED921F99F4 for ; Wed, 2 Oct 2013 00:46:07 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 2 Oct 2013 09:46:06 +0200 Received: from MARVMAILDB.technxs.com ([fe80::c45a:7e27:c6bf:5de]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 09:46:05 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: "" Thread-Topic: Some minor comments after a review of the 02 specs Thread-Index: AQHOv0NyGkW7buKKoU6DhbflOr/45g== Date: Wed, 2 Oct 2013 07:46:05 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.170] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2802E347410A684DA51D1DC50235A366@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [scim] Some minor comments after a review of the 02 specs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 07:47:21 -0000 After a review of the -02 specs I found a couple of issues in the spec. It'= s manly language based issues. Here is a list of some minor issues. I propose that we create one ticket wi= th the minor changes. As far as I can see it's mainly language issues and d= oes not effect the spec otherwise. If someone objects and see something tha= t I can't see we can discuss them more in detail and add more tickets.=20 ---------------------- Missing period after Group.=20 Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group =20 Should be changed to. Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group. ---------------------- Schema ID is wrong. Schema: A collection of Attribute Definitions that describe the contents of an entire or partial Resource; e.g., urn:scim:schemas:core:User:2.0. Should be: Schema: A collection of Attribute Definitions that describe the contents of an entire or partial Resource; e.g., urn:scim:schemas:core:2.0:User. ---------------------- We removed XML, but this section still reflects that there could be other t= ypes of representations. When a representation does not explicitly provide support for indicating a schema, such as JSON, a schemas attribute is used to indicate the version of SCIM schema as well as any schema extensions. Should be changed to: A schemas attribute is used to indicate the version of SCIM schema as well= as any schema extensions. Or: JSON does not explicitly provide support for indicating a schema so a sch= emas attribute is used to indicate the version of SCIM schema as well as any schema extensions us= ed. =20 ---------------------- Since we added the Resource Type schema we should change how the Service Pr= ovider Configuration Resources talks about the ID attribute. The Service Provider Configuration Resource says: =20 "Unlike other core Resources, the "id" attribute is not required for the S= ervice Provider Configuration Resource." The Resource Type Resource says: "Unlike other core Resources, all Attributes are REQUIRED unless otherwise specified, and the "id" attribute is not required for the Resource Type Resource." We should write something like this for both of them. "Unlike other core Resources like User and Group, all Attributes are REQUI= RED unless otherwise specified, and the "id" attribute is not required for the Resource Type Resource." ---------------------- The Schemas Schema have a reference to the URI "urn:scim:core:2.0:User".=20 Should be changed to "urn:scim:schemas:core:2.0:User" instead. ---------------------- Strange layout issue on the following section. Deindent section. The following multi-valued attributes are defined. There are no canonical type values defined and the primary value serves no useful purpose. subAttributes A list specifying the contained attributes. OPTIONAL. ---------------------- Both the examples Service Provider Configuration resource and the Resource = Type is missing the meta->location attribute.=20 12.5. Service Provider Configuration Representation ], "meta": { "resourceType": "ServiceProviderConfig" "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"3694e05e9dff594\"" } } Should be: ], "meta": { "resourceType": "ServiceProviderConfig" "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"3694e05e9dff594\"", "location": "https://example.com/v1/ServiceProviderConfigs" } } And same for Resource Type Resource. / Erik From prvs=4987DF40C9=erik.wahlstrom@nexusgroup.com Wed Oct 2 00:47:30 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE2121F99F8 for ; Wed, 2 Oct 2013 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSiGCBisd0Tx for ; Wed, 2 Oct 2013 00:47:21 -0700 (PDT) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4261B21E80F1 for ; Wed, 2 Oct 2013 00:46:18 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 2 Oct 2013 09:46:18 +0200 Received: from MARVMAILDB.technxs.com ([fe80::c45a:7e27:c6bf:5de]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 09:46:17 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: "" Thread-Topic: Some comments after a review of the 02 specs Thread-Index: AQHOv0N57+jTwpU2dkakYMmynuEiCg== Date: Wed, 2 Oct 2013 07:46:16 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.170] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <52DC5487CD7ABB4D9AFF2EE2164AEE1D@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [scim] Some comments after a review of the 02 specs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 07:47:31 -0000 After a review of the -02 specs I found a couple of issues that I guess we = need to discuss. I propose adding them all as new issues in the issue track= er of no one objects. ---------------------- In general I think we should add a couple of more examples in our definitio= ns when we talk about example Resources. We always mention User and Group. = That's fine but when we start talking about ServiceProviderConifig and Reso= urceType they come as a surprise and you wonder if they are treated as any = Resource or not. Example: Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group Resource: The Service Provider managed artifact containing one or more attributes; e.g., User, Group, ServiceProviderConfig or Resource= Type. ---------------------- In the API documentation we never mension the new URIs like urn:scim:schema= s:core:2.0:ListResponse, SearchRequest, Error, BulkRequest, BulkResponse. W= e also mention urn:scim:schemas:core:2.0:name.givenName and that's real att= ributes defined in the core schema for a specific User.=20 ---------------------- In the "3.8 Attribute Notation" section shouln't we also define the core re= source type like User and Group when we refrence name.givenName. Instead of: urn:scim:schemas:core:2.0:name.givenName Have: urn:scim:schemas:core:2.0:User:name.givenName ---------------------- We have some language confusion on a lot of places in the specification. In= our defintions we define that there exists Consumers and Service Providers= . But most of the specification talks about clients and servers. I personal= ly use client and server when I talk about SCIM. Here is a list of where we= say client instead of Consumer. The server equivalent is longer. From: "It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication" To: "It is RECOMMENDED that Service Providers and Consumers is implemented in such a way that new au= thentication schemes can be deployed. Implementers SHOULD support existing authentication" -- =20 From: "To create new Resources, clients send POST requests to the Resource endpoint; i.e., /Users or /Groups." =20 To: "To create new Resources, Consumers send POST requests to the Resource endpoint; i.e., /Users or /Groups." -- =20 From: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the client, enabling it to correlate the client and server views of the new Resource. When a Resource is created, its URI must be returned in the response Location header." To: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the Consumer, enabling it to correlate the Consumer and Service Provider views of the new Resource. When a Resource is created,= its URI must be returned in the response Location header." -- From: "Below, the client sends a POST request containing a User" To: "Below, the Consumer sends a POST request containing a User." =20 -- From: "To retrieve a known Resource, clients send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." To: =20 "To retrieve a known Resource, Consumers send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." -- From: "Clients MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the '/.search' path extension." To: "Consumers MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the '/.search' path extension." --=20 From: "To create a new search result set, a SCIM client sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." To: "To create a new search result set, a SCIM Consumer sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." --=20 From: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations." To: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response containing the error response and, per the HTTP specificati= on, human-readable explanations." -- From: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a client MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." To: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a Consumer MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." ---------------------- And finaly I agree with Steves earlier comment on the mail list, at least t= he first two suggestions :), regarding section 3.1.5 not beeing up to date.= Steve stated: "Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to section = 3.2.7 which no longer exists and to the (XML Schema Datatypes Specification= ) which is no longer supported. I'd suggest we refer to the relevant stand= ards in this paragraph and link to RFC3339 - section 5.6 (http://tools.ietf= .org/html/rfc3339#section-5.6), ISO-8601 (http://www.iso.org/iso/catalogue_= detail?csnumber=3D40874) and if humor is tolerated, to Randall Munroe's opi= nion (https://xkcd.com/1179/)." / Erik= From bjorn.aannestad@unboundid.com Wed Oct 2 10:38:34 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83921F8531 for ; Wed, 2 Oct 2013 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUsCd08V6Ker for ; Wed, 2 Oct 2013 10:38:22 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2309E21F92E7 for ; Wed, 2 Oct 2013 10:34:54 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id s14so809195qeb.22 for ; Wed, 02 Oct 2013 10:34: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:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type; bh=V9HBLvNEyBTDoLqkcHXQQWpABOvHGCh+fmVUa222fWE=; b=EcyR4fKyb/tI8N8ytp5ZY+Ly1p+iNGkHNKGxKIRCUmYWlWRT2xVQtJ82K7/0UzrwZZ 3ykD4VPRLGgkPUIx5DEqo4CPL0Dxch7hodx9wxXp1TPwvCzNfisL2vf+dbPWGkohRKX/ QRiku4OU5zxnUZ2FPFptmL6dpwSch354E/BswMDpjZ5GFkWyC3wju9o6LHkP2buFnQgX Tx8oUhWjByAFcPA+nXs9tvSF3sjjoQgUGK7U7c4R4BH24a0hWPc+2s36BxySOdcArAEk EMu2tzSusvYi04Q++lQVYfUa8ZXLQMS1BX5TDp3N3icxXu/DrdmS8TnT4yWP9ORWjRTm EcxQ== X-Gm-Message-State: ALoCoQm2N8MvDXwdrUPga94pzJC5Z7AtHKjmq7DvKfgRdS7OQ8RlCQXJ+HHUKMFfekOQE2jWsep/ X-Received: by 10.229.48.137 with SMTP id r9mr4451447qcf.6.1380735294432; Wed, 02 Oct 2013 10:34:54 -0700 (PDT) Received: from ip-10-46-217-43.ec2.internal ([174.129.10.251]) by mx.google.com with ESMTPSA id 5sm7285738qao.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 02 Oct 2013 10:34:53 -0700 (PDT) Date: Wed, 2 Oct 2013 17:34:51 +0000 (UTC) From: Bjorn Aannestad To: Duc Thuan Nguy , scim@ietf.org Message-ID: <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4473_1607831016.1380735291222" Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:38:34 -0000 ------=_Part_4473_1607831016.1380735291222 Content-Type: multipart/alternative; boundary="----=_Part_4474_1186741839.1380735291223" ------=_Part_4474_1186741839.1380735291223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You could add a custom attribute for the user name type - those kinds of ex= tensions are supported by the specification. =C2=A0However, I'm do not thin= k mixing the two attribute types is the right solution. Are both email and = a user name required by your system when creating a user? =C2=A0 If so, I w= ould recommend storing each in their respective predefined attributes. =C2= =A0=C2=A0 If only an email address is required when creating a user, when t= hat is all you have, I would recommend storing the email in both attributes= . If only a user name is required, and the email is optional, then of cours= e store the user name and leave the email blank. In all cases, allowing the= user to log in with either name should be done in the authentication logic= , not in the provisioning data when the user is created. -Bjorn Aannestad F= rom: Duc Thuan Nguy (nguydthuan@hotmail.com) Sent: Tuesday, October 1, 2013= 10:28 PM To: scim@ietf.org Subject: [scim] Resend: How to use SCIM against= a multi-username system =C2=A0 Hi SCIM groups, (I resend this email becaus= e it seems the first one got lost somewhere. Perhaps it is because I sent i= t from another email account which wasn't subscribed to the SCIM group. Thi= s email aims to correct that mistake) Our company wants to implement SCIM 1= .1 for our identity management product. I think SCIM is great yet simple fr= amework and is very eager to implement it. However, I find one problem when= I try to adopt SCIM for our system: simply speaking, our system supports m= ultiple usernames. In other words, one user can have more than one username= s, for example: -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Use= rname_as_username: bjensen. -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Email_as_username: bjensen@example.com A user can use any of the = =E2=80=9Cusername=E2=80=9D to login. =C2=A0 As a consequent, when a create = user request needs to specify not only a username but also the type of that= username. Unfortunately, I couldn=E2=80=99t find any predefined SCIM attri= bute which can be used for that =E2=80=9Ctype of username=E2=80=9D. =C2=A0 = I can think of a few options: =C2=A0 A standard SCIM create user request: = =C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0 "schemas":["urn:scim:schemas:core:1= .0"], =C2=A0=C2=A0=C2=A0=C2=A0 "userName":"bjensen", =C2=A0=C2=A0=C2=A0=C2= =A0 "externalId":"bjensen", =C2=A0=C2=A0=C2=A0=C2=A0 "name":{ =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "formatted":"Ms. Barbara J Jensen III", =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "familyName":"Jensen", =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "givenName":"Barbara" =C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0 = } =C2=A0 Approach 1: extended SCIM create user request: =C2=A0=C2=A0 { =C2= =A0=C2=A0=C2=A0=C2=A0 "schemas":["urn:scim:schemas:core:1.0"], =C2=A0=C2=A0= =C2=A0=C2=A0 "userName":"bjensen", =C2=A0=C2=A0=C2=A0=C2=A0 "externalId":"b= jensen", =C2=A0=C2=A0=C2=A0=C2=A0 "name":{ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "formatted":"Ms. Barbara J Jensen III", =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "familyName":"Jensen", =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "give= nName":"Barbara" =C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0 "urn:s= cim:schemas:extension:ourproductname:1.0":{ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "userNameType"= :"email_as_username", =C2=A0=C2=A0 =C2=A0=C2=A0} =C2=A0=C2=A0 } =C2=A0 Appr= oach 2: define separate endpoint for each username type: an endpoint to cre= ate a user will look like: https://example.com/email_as_username/v1/Users = =C2=A0 Approach 3: Ask the client developer to append a =E2=80=9CuserNameTy= pe=3D=E2=80=A6=E2=80=9D parameter to the end of the request. =C2=A0 Could y= ou please tell me if any of the approaches above are SCIM compliant and usa= ble? What alternatives do I have? =C2=A0 Thank you in advance, Nguy Duc Thu= an. ------=_Part_4474_1186741839.1380735291223 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable You could add a custom attribute for the user name type - those kinds of = extensions are supported by the specification.  However, I'm do not th= ink mixing the two attribute types is the right solution.
=20
Are both email and a user name required by your system when creati= ng a user?  
If so, I would recommend storing each in their respective predefin= ed attributes.   
=20
If only an email address is required when creating a user, when th= at is all you have, I would recommend storing the email in both attributes.
=20
If only a user name is required, and the email is optional, then o= f course store the user name and leave the email blank.
=20
In all cases, allowing the user to log in with either name should = be done in the authentication logic, not in the provisioning data when the = user is created.
=20
-Bjorn Aannestad
=20
=20
=20
=20
=20
=20 From:=20 Duc Thuan Nguy (nguydthuan@hotmail.com)
=20 Sent: Tuesday, October 1, 2013 10:28 PM
=20 To:=20 scim@ietf.org
=20 Subject: [scim] Resend: How to use SCIM against a multi-username s= ystem=20
 
=20 =20
=20

Hi SCIM groups,= =20

=20

(I resend this em= ail because it seems the first one got lost somewhere. Perhaps it is becaus= e I sent it from another email account which wasn't subscribed to the SCIM = group. This email aims to correct that mistake)

=20

=20

=20

Our company wants= to implement SCIM 1.1 for our identity management product. I think SCIM is= great yet simple framework and is very eager to implement it. However, I f= ind one problem when I try to adopt SCIM for our system: simply speaking, o= ur system supports multiple usernames. In other words, one user can have mo= re than one usernames, for example:=20

=20

=20 -        = ;  =20 Username_as_username: bjensen.=20

=20

=20 -        = ;  =20 Email_as_username: bjensen@example.com=20

=20

A user can use an= y of the =E2=80=9Cusername=E2=80=9D to login.=20

=20

=20  =20

=20

As a consequent, = when a create user request needs to specify not only a username but also th= e type of that username. Unfortunately, I couldn=E2=80=99t find any predefi= ned SCIM attribute which can be used for that =E2=80=9Ctype of username=E2= =80=9D.=20

=20

=20  =20

=20

I can think of a = few options:=20

=20

=20  =20

=20

A standard SCIM c= reate user request:=20

=20

   {=20

=20

     "sch= emas":["urn:scim:schemas:core:1.0"],=20

=20

     "use= rName":"bjensen",=20

=20

     "ext= ernalId":"bjensen",=20

=20

     "nam= e":{=20

=20

     &nbs= p; "formatted":"Ms. Barbara J Jensen III",=20

=20

     &nbs= p; "familyName":"Jensen",=20

=20

     &nbs= p; "givenName":"Barbara"=20

=20

     }=20

=20

   }=20

=20

=20  =20

=20

Approach 1: exten= ded SCIM create user request:=20

=20

   {=20

=20

     "sch= emas":["urn:scim:schemas:core:1.0"],=20

=20

     "use= rName":"bjensen",=20

=20

     "ext= ernalId":"bjensen",=20

=20

     "nam= e":{=20

=20

     &nbs= p; "formatted":"Ms. Barbara J Jensen III",=20

=20

     &nbs= p; "familyName":"Jensen",=20

=20

     &nbs= p; "givenName":"Barbara"=20

=20

     }=20

=20

     "urn= :scim:schemas:extension:ourproductname:1.0":{=20

=20

     &nbs= p;          "userNameType= ":"email_as_username",=20

=20

     }=20

=20

   }=20

=20

=20  =20

=20

Approach 2: defin= e separate endpoint for each username type: an endpoint to create a user wi= ll look like: https://example.com/email_as_userna= me/v1/Users=20

=20

=20  =20

=20

Approach 3: Ask t= he client developer to append a =E2=80=9CuserNameType=3D=E2=80=A6=E2=80=9D = parameter to the end of the request.=20

=20

=20  =20

=20

Could you please = tell me if any of the approaches above are SCIM compliant and usable? What = alternatives do I have?=20

=20

=20  =20

=20

Thank you in adva= nce,=20

=20

Nguy Duc Thuan.= =20

=20
=20
=20 ------=_Part_4474_1186741839.1380735291223-- ------=_Part_4473_1607831016.1380735291222-- From moransar@cisco.com Wed Oct 2 14:30:37 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D1821F8B04; Wed, 2 Oct 2013 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN6UpF5XhgAg; Wed, 2 Oct 2013 14:30:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5021F8FE5; Wed, 2 Oct 2013 14:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10640; q=dns/txt; s=iport; t=1380749427; x=1381959027; h=from:to:subject:date:message-id:mime-version; bh=3OjedOF4y0P98Dzz0w36Knb7N8SgTtQPJqqfi0JNWS0=; b=C9/nZxUoP2oCO4FmvcIAZCGBffaI6e6tRgA/Z4tKySBcvGQ1s6YhyiJf Ak1d+ZBLQSRLWmlguAaTM4xfITWTHnvl6jsUQZf8gu6ifxPxIPoK5iIsi kCzziiHlqcHRA1wVSu7emSyeQ0tJsipCHV47ItYcjCaWTQaBe7AboRadc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAAGPTFKtJV2Y/2dsb2JhbAA/GoJDRDhSwTWBGhZ0gicBBB5QHQEqVicEARqHfgw2vUIEjiJ+LYMqgQQDqgCDJIIq X-IronPort-AV: E=Sophos;i="4.90,1021,1371081600"; d="scan'208,217";a="264346647" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 02 Oct 2013 21:30:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r92LUIwq015167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 21:30:18 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 16:30:18 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" , "proceedings@ietf.org" Thread-Topic: Meeting notes from SCIM WG confcal 2013-10-02 Thread-Index: AQHOv7aWIt8bJCaI9EmITqXIy9iYiQ== Date: Wed, 2 Oct 2013 21:30:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.75.11] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32AC81923xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Meeting notes from SCIM WG confcal 2013-10-02 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 21:30:37 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E32AC81923xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: - Kelly Grizzle - Morteza Ansari - Barry Leiba - Bjorn Aannestad - Erik Wahlstrom - Phil Hunt - Sal D'Agostino Issue #34: - Kelly will fix by marking this as non-normative and will check the rest = of the examples in the drafts for similar problems. Issue #35: - Phil: New schema attribute regarding read-only, read-write, write-only, i= mmutable. Phil will work on this. Issue #37: - Two parts to this o Define error responses o Allow servers to publish restrictions - What sort of response should be given if the client tries to query on an = attribute that is not indexed? Error or no results? - Phil updated ticket with some ideas, will send questions to list. Issue #39: - Unclear what the use case is here - will send note to Alex Santos regardi= ng the need for this. - Could return a 204 with no content. - Phil brought up somewhat related issue around slow REST ... should poll t= he mailing list. Already described in ticket #32. - Erik will take this one. Issue #42: - Making this optional will ease migration from 1.1 to 2.0. - Publish a config option in ServiceProviderConfig regarding this. - Phil will take this one. Issue #46: - Is there a reason for an array of errors? Morteza believes there was dis= cussion around this a long time ago. Should search the google group and lo= ok for precedence in other REST APIs. - Are there existing mechanisms for extending REST error codes? - Kelly will take this one. Two more calls until IETF meeting - would like to wrap up many open tickets= and produce another revision of the drafts. Morteza will open another issue about filtering complex mutli-valued attrib= utes (eg - find users whose primary address is in Austin). Will discuss on= next concall. Bjorn will brainstorm ahead of time. --- Meeting recording link: https://go.webex.com/go/lsr.php?AT=3Dpb&SP=3DMC&rID=3D6158527&rKey=3D514646= 158d73cbd2 SCIM WG bi-weekly call-20131002 1807-1 Wednesday, October 2, 2013 11:07 am San Francisco Time 53 Minutes --_000_CA3B67220D628A4780D6FEB31F18A3E32AC81923xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0F69069C50A87040A5D1EF101F7E2FF5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Attendees:

- Kelly Grizzle

- Morteza Ansari

- Barry Leiba

- Bjorn Aannestad

- Erik Wahlstrom

- Phil Hunt

- Sal D'Agostino

 

Issue #34:

 - Kelly will fix by marking this as non-normative a= nd will check the rest of the examples in the drafts for similar problems.<= o:p>

 

Issue #35:

- Phil: New schema attribute regarding read-only, read-wr= ite, write-only, immutable.  Phil will work on this.=

 

Issue #37:

- Two parts to this

    o Define error responses

    o Allow servers to publish restriction= s

- What sort of response should be given if the client tri= es to query on an attribute that is not indexed?  Error or no results?=

- Phil updated ticket with some ideas, will send question= s to list.

 

Issue #39:

- Unclear what the use case is here - will send note to A= lex Santos regarding the need for this.

- Could return a 204 with no content.

- Phil brought up somewhat related issue around slow REST= ... should poll the mailing list. Already described in ticket #32.

- Erik will take this one.

 

Issue #42:

- Making this optional will ease migration from 1.1 to 2.= 0.

- Publish a config option in ServiceProviderConfig regard= ing this.

- Phil will take this one.

 

Issue #46:

- Is there a reason for an array of errors?  Morteza= believes there was discussion around this a long time ago.  Should se= arch the google group and look for precedence in other REST APIs.

- Are there existing mechanisms for extending REST error = codes?

- Kelly will take this one.

 

Two more calls until IETF meeting - would like to wrap up= many open tickets and produce another revision of the drafts.

 

Morteza will open another issue about filtering complex m= utli-valued attributes (eg - find users whose primary address is in Austin)= .  Will discuss on next concall.  Bjorn will brainstorm ahead of time.


---


Meeting recording link:


http= s://go.webex.com/go/lsr.php?AT=3Dpb&SP=3DMC&rID=3D6158527&rKey= =3D514646158d73cbd2 

SCIM WG bi-weekly call-20131002 1807-1 
Wednesday, October 2, 2013 11:07 am San Francisco Time 
53 Minutes 

--_000_CA3B67220D628A4780D6FEB31F18A3E32AC81923xmbrcdx08ciscoc_-- From phil.hunt@oracle.com Wed Oct 2 17:08:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEC121F9E4D for ; Wed, 2 Oct 2013 17:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbK3nXrZaJwq for ; Wed, 2 Oct 2013 17:08:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55021F9D87 for ; Wed, 2 Oct 2013 17:08:02 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r93080hL016984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Oct 2013 00:08:01 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 r9307xQQ021424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Oct 2013 00:07:59 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9307xsQ007805 for ; Thu, 3 Oct 2013 00:07:59 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Oct 2013 17:07:58 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_45458781-28B5-4279-9525-72E23DB3F1EA" Message-Id: Date: Wed, 2 Oct 2013 17:07:52 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] Proposed changes for attribute schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 00:08:27 -0000 --Apple-Mail=_45458781-28B5-4279-9525-72E23DB3F1EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tickets 10 (attribute sensitivity), 35 (mutability), and 47 (indexing) = all specify qualities that attributes may have in a SCIM service = provider. The following is proposed changes to section 3. Original text > A resource is a collection of attributes identified by one or more > schemas. Minimally, an attribute consists of the attribute name = and > at least one Simple or Complex value either of which may be Multi- > valued. SCIM schema defines the data type, plurality and other > distinguishing features of an attribute. Unless otherwise = specified > all attributes are modifiable by Consumers. Immutable (read-only) > attributes SHALL be specified as 'READ-ONLY' within the attribute > definition. Additionally, Service Providers MAY choose to make = some > or all Resource attributes immutable and SHOULD identify those > attributes via the associated Resource's schema endpoint > (Section 5.2). Proposed text: A resource is a collection of attributes identified by one or more = schemas.=20 Minimally, an attribute consists of the attribute name and at least one=20= Simple or Complex value either of which may be Multi-valued. =20 Attribute Meta-Data Schema SCIM schema=20 defines the data type, plurality and other distinguishing features of an=20= attribute. =20 multiValued is a BOOLEAN that expresses whether the attribute MAY = have multiple values. mutability is a keyword that MAY be ONE of the following values:=20 "readWrite" means that the attribute MAY be returned or = updated. "readOnly" means that the attribute MAY be returned in = response to a SCIM request. A readOnly attribute MAY be used in a SCIM = GET request. A readOnly attribute MAY NOT be used in the request portion = of a POST, PUT, or PATCH operation. "writeOnly" means that an attribute MAY NOT be returned in any = response to a SCIM request. The attribute MAY be included in a POST, = PUT, or PATCH request. The attribute MAY NOT be used in a GET request. "immutable" means that an attribute MAY only be set once at = record creation during a POST or PUT operation. [[should we allow PUT on = a replace operation?]] returned is a keyword that indicates when attribute values are = returned on a query or SCIM response. The keyword MAY be ONE of the = following values:=20 "always" is used for attributes that must always be returned = such as "id" "never" is used for write-only attributes or other internal = data.=20 "default" means the specified attribute is returned when the = attribute parameter of a GET query is omitted.=20 "request" means that the attribute will only be returned if = requested. index is a keyword that indicates what type of search filter = MAY be used with the attribute. Note that if the server does not support = unindexed searches, specifying a filter type not supported by the index = returns a no match for the purposes of filter processing. The index MAY = be one or more of the following: "substring" the specified filter string MUST be contained = within the attribute value. "startsWith" the specified filter string MUST occur at the start = of the attribute value. "endsWith" the specified filter string MUST occur at the end = of the attribute value. "exact" the specified filter string MUST exactly match the = attribute value. In section 12.7, the schema representation for all attributes needs to = be updated to reflect the new attribute meta values. Note "readOnly" is = replaced by "mutability". Since individual servers can choose their own values for mutability, = index, multiValued, etc, the JSON structure would have to be = non-normative. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_45458781-28B5-4279-9525-72E23DB3F1EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
   A =
resource is a collection of attributes identified by one or more
   schemas.  Minimally, an attribute consists of the attribute name and
   at least one Simple or Complex value either of which may be Multi-
   valued.  SCIM schema defines the data type, plurality and other
   distinguishing features of an attribute.  Unless otherwise specified
   all attributes are modifiable by Consumers.  Immutable (read-only)
   attributes SHALL be specified as 'READ-ONLY' within the attribute
   definition.  Additionally, Service =
Providers MAY choose to make some
   or all Resource attributes immutable and =
SHOULD identify those
   attributes via the associated Resource's schema endpoint
   (Section =
5.2).


Propo= sed text:
A resource is a collection of attributes identified by one or more =
schemas. 
Minimally, an attribute consists of the attribute =
name and at least one 
Simple or Complex value =
either of which may be Multi-valued.  

SCIM =
schema 
defines the data type, plurality =
and other attribute. =
 

multiValued	is a BOOLEAN that expresses =
whether the attribute MAY have multiple values.

mutability	=
is a keyword that MAY be ONE of the following values: =

	=
"readWrite"  means that the attribute MAY be returned or =
updated.
        "readOnly"   means that the attribute MAY be returned in =
response to a SCIM request. A readOnly attribute MAY be used in a SCIM =
GET request. A readOnly attribute MAY NOT be used in the request portion =
of a POST, PUT, or PATCH operation.
	"writeOnly"  means that an =
attribute MAY NOT be returned in any response to a SCIM request. The =
attribute MAY be included in a POST, PUT, or PATCH request. The =
attribute MAY NOT be used in a GET request.
	=
"immutable"  means that an attribute MAY only be set once at =
record creation during a POST or PUT operation. [[should we allow PUT on =
a replace operation?]]

returned	is a keyword that indicates when =
attribute values are returned on a query or SCIM response. The keyword =
MAY be ONE of the following values: 
 	"always"     is used for =
attributes that must always be returned such as "id"
 	"never"   =
   is used for write-only attributes or other internal data. 
	"default" =
   means the specified attribute is returned when the attribute =
parameter of a GET query is omitted. 
	"request"    means that the =
attribute will only be returned if requested.
index		=
is a keyword that indicates what type of search filter MAY be =
used with the attribute. Note that if the server does not support =
unindexed searches, specifying a filter type not supported by the index =
returns a no match for the purposes of filter processing. The index MAY =
be one or more of the following:
	"substring"  the specified filter =
string MUST be contained within the attribute value.
	"startsWith" the specified filter =
string MUST occur at the start of the attribute value.
	"endsWith"   the specified filter =
string MUST occur at the end of the attribute value.
        "exact"	     the specified filter string =
MUST exactly match the attribute value.

In section 12.7, the schema representation for = all attributes needs to be updated to reflect the new attribute meta = values.  Note "readOnly" is replaced by = "mutability".

Since individual servers can = choose their own values for mutability, index, multiValued, etc, the = JSON structure would have to be = non-normative.

Phil

@ind= ependentid
phil.hunt@oracle.com
=

= --Apple-Mail=_45458781-28B5-4279-9525-72E23DB3F1EA-- From nguydthuan@hotmail.com Thu Oct 3 00:47:58 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA721F9B07 for ; Thu, 3 Oct 2013 00:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOp8GGfKnfoO for ; Thu, 3 Oct 2013 00:47:47 -0700 (PDT) Received: from bay0-omc2-s21.bay0.hotmail.com (bay0-omc2-s21.bay0.hotmail.com [65.54.190.96]) by ietfa.amsl.com (Postfix) with ESMTP id EEA5721F9BA4 for ; Thu, 3 Oct 2013 00:46:42 -0700 (PDT) Received: from BAY168-W49 ([65.54.190.123]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Oct 2013 00:46:42 -0700 X-TMN: [k/htXIi9jhC3k0nQcrHbwE/UeMk9YvQn] X-Originating-Email: [nguydthuan@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b5f068c4-5716-47d9-8230-f7a176ab2275_" From: Duc Thuan Nguy To: "scim@ietf.org" Date: Thu, 3 Oct 2013 14:46:42 +0700 Importance: Normal In-Reply-To: <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> References: , <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Oct 2013 07:46:42.0964 (UTC) FILETIME=[B3D67540:01CEC00C] Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 07:47:58 -0000 --_b5f068c4-5716-47d9-8230-f7a176ab2275_ Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: base64 SGkgQmpvcm4sVGhhbmsgeW91IHRha2luZyB0aW1lIHRvIHJlcGx5IG15IHF1ZXN0aW9uLiBQbGVh c2UgbGV0IG1lIGV4cGxhaW4gYSBsaXR0bGUgYml0IGFib3V0IG91ciB1c2VybmFtZSBzeXN0ZW0u IEluIGZhY3QsIG5vcm1hbCB1c2VybmFtZSBhbmQgZW1haWwgYXJlIG9ubHkgdHdvIGV4YW1wbGVz LiBPdGhlciBwb3NzaWJpbGl0aWVzIGluY2x1ZGUgc29jaWFsIHNlY3VyaXR5IG51bWJlciwgb3Ig YW55IHVzZXItZGVmaW5lZCB0eXBlcy4gVGhlcmUgaXMgbm8gbGltaXRhdGlvbiB3aXRoIHJlZ2Fy ZCB0byB1c2VybmFtZSB0eXBlcy4gTG9va2luZyBhdCB0aGUgcHJvYmxlbSBmcm9tIHRoZSBkYXRh YmFzZSBwb2ludCBvZiB2aWV3LCB3ZSBkb24ndCBoYXZlIGEgc2luZ2xlIGNvbHVtbiB0byBzdG9y ZSB1c2VybmFtZS4gSW5zdGVhZCwgYSB1c2VyIGhhcyBhIGxpc3Qgb2YgY2xhaW1zLCBlLmcuOiAt IGh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL25h bWUgLSBodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWlt cy9lbWFpbGFkZHJlc3MgLSBnb3Y6c2FtbDphdHRyaWJ1dGU6U29jaWFsU2VjdXJpdHlOdW1iZXIt IC4uLkFueSBvZiB0aGVtIGNhbiBiZSB1c2VkIGFzIHVzZXJuYW1lLiBPdXIgY2xpZW50cyBjYW4g c2V0IHVwIGEgbG9naW4gcGFnZSBmb3IgcHVibGljIHVzZXJzIHRvIHVzZSBOYW1lIGZvciB1c2Vy bmFtZSwgYW5kIGEgbG9naW4gcGFnZSBmb3IgY29ycG9yYXRlIHVzZXJzIHRvIHVzZSBlbWFpbCBh ZGRyZXNzIGFzIHVzZXJuYW1lLiBIb3dldmVyLCB3aGVuIGNyZWF0aW5nIGEgbmV3IHVzZXIsICpv bmUgYW5kIG9ubHkgb25lKiB1c2VybmFtZSB0eXBlIGlzIHJlcXVpcmVkLiBTbzpROiBBcmUgYm90 aCBlbWFpbCBhbmQgYSB1c2VyIG5hbWUgcmVxdWlyZWQgYnkgeW91ciBzeXN0ZW0gd2hlbiBjcmVh dGluZyBhIHVzZXI/ICAgICANCiBBOiBObywgb25seSBvbmUgaXMgcmVxdWlyZWQuIEFueSBvZiB0 aGUgdXNlcm5hbWUgdHlwZSBpcyBmaW5lLg0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0ICJJbiBh bGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3aXRoIGVpdGhlciBuYW1lIHNo b3VsZCBiZSBkb25lIGluIHRoZSBhdXRoZW50aWNhdGlvbiBsb2dpYywgbm90IGluIHRoZSBwcm92 aXNpb25pbmcgZGF0YSB3aGVuIHRoZSB1c2VyIGlzIGNyZWF0ZWQuIiBUaGUgcG9pbnQgaGVyZSBp cyB0aGF0IHdoZW4gYSB1c2VyIGlzIGNyZWF0ZWQsIEkgbmVlZCB0byBrbm93IHdoYXQgdXNlcm5h bWUgdHlwZSB0byBtYXAgdGhlICJ1c2VybmFtZSIgc3BlY2lmaWVkIGluIGFuIFNDSU0gcmVxdWVz dCB0by4NCg0KQW0gSSByaWdodCB0aGF0IHlvdXIgcmVwbHkgbWVhbnMgdXNpbmcgYSBjdXN0b20g YXR0cmlidXRlIGxpa2VzIHRoZSBmb2xsb3dpbmcgaXMgdGhlIGJlc3Qgd2F5IEkgc2hvdWxkIGRv Pw0KICAgICAidXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246b3VycHJvZHVjdG5hbWU6MS4wIjp7 ICAgICAgIA0KICAgICAgICAgICAgICAgICJ1c2VyTmFtZVR5cGUiOiJlbWFpbF9hc191c2VybmFt ZSIsICAgICAgICAgICAgfSAgDQoNCiANCkJlc3QgUmVnYXJkcywKVGh1YW4uCiANCkRhdGU6IFdl ZCwgMiBPY3QgMjAxMyAxNzozNDo1MSArMDAwMA0KRnJvbTogYmpvcm4uYWFubmVzdGFkQHVuYm91 bmRpZC5jb20NClRvOiBuZ3V5ZHRodWFuQGhvdG1haWwuY29tOyBzY2ltQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW3NjaW1dIFJlc2VuZDogSG93IHRvIHVzZSBTQ0lNIGFnYWluc3QgYSBtdWx0aS11 c2VybmFtZSBzeXN0ZW0NCg0KCiAKIAogIFlvdSBjb3VsZCBhZGQgYSBjdXN0b20gYXR0cmlidXRl IGZvciB0aGUgdXNlciBuYW1lIHR5cGUgLSB0aG9zZSBraW5kcyBvZiBleHRlbnNpb25zIGFyZSBz dXBwb3J0ZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uICBIb3dldmVyLCBJJ20gZG8gbm90IHRoaW5r IG1peGluZyB0aGUgdHdvIGF0dHJpYnV0ZSB0eXBlcyBpcyB0aGUgcmlnaHQgc29sdXRpb24uCiAg DQogCiAgDQogQXJlIGJvdGggZW1haWwgYW5kIGEgdXNlciBuYW1lIHJlcXVpcmVkIGJ5IHlvdXIg c3lzdGVtIHdoZW4gY3JlYXRpbmcgYSB1c2VyPyAgCiAgDQogSWYgc28sIEkgd291bGQgcmVjb21t ZW5kIHN0b3JpbmcgZWFjaCBpbiB0aGVpciByZXNwZWN0aXZlIHByZWRlZmluZWQgYXR0cmlidXRl cy4gICAKICANCiAKICANCiBJZiBvbmx5IGFuIGVtYWlsIGFkZHJlc3MgaXMgcmVxdWlyZWQgd2hl biBjcmVhdGluZyBhIHVzZXIsIHdoZW4gdGhhdCBpcyBhbGwgeW91IGhhdmUsIEkgd291bGQgcmVj b21tZW5kIHN0b3JpbmcgdGhlIGVtYWlsIGluIGJvdGggYXR0cmlidXRlcy4KICANCiAKICANCiBJ ZiBvbmx5IGEgdXNlciBuYW1lIGlzIHJlcXVpcmVkLCBhbmQgdGhlIGVtYWlsIGlzIG9wdGlvbmFs LCB0aGVuIG9mIGNvdXJzZSBzdG9yZSB0aGUgdXNlciBuYW1lIGFuZCBsZWF2ZSB0aGUgZW1haWwg YmxhbmsuCiAgDQogCiAgDQogSW4gYWxsIGNhc2VzLCBhbGxvd2luZyB0aGUgdXNlciB0byBsb2cg aW4gd2l0aCBlaXRoZXIgbmFtZSBzaG91bGQgYmUgZG9uZSBpbiB0aGUgYXV0aGVudGljYXRpb24g bG9naWMsIG5vdCBpbiB0aGUgcHJvdmlzaW9uaW5nIGRhdGEgd2hlbiB0aGUgdXNlciBpcyBjcmVh dGVkLgogIA0KIAogIA0KIC1Cam9ybiBBYW5uZXN0YWQKICANCiAKICANCiAKICANCiAKICANCiAK ICANCiAKICAgCiAgRnJvbTogCiAgRHVjIFRodWFuIE5ndXkgKG5ndXlkdGh1YW5AaG90bWFpbC5j b20pCiAgDQogCiAgU2VudDogVHVlc2RheSwgT2N0b2JlciAxLCAyMDEzIDEwOjI4IFBNCiAgDQog CiAgVG86IAogIHNjaW1AaWV0Zi5vcmcKICANCiAKICBTdWJqZWN0OiBbc2NpbV0gUmVzZW5kOiBI b3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhIG11bHRpLXVzZXJuYW1lIHN5c3RlbSAKICAKICAgICAK ICAgCiAgIAogICAKICAgIEhpIFNDSU0gZ3JvdXBzLCAKICAgICAKICAgIChJIHJlc2VuZCB0aGlz IGVtYWlsIGJlY2F1c2UgaXQgc2VlbXMgdGhlIGZpcnN0IG9uZSBnb3QgbG9zdCBzb21ld2hlcmUu IFBlcmhhcHMgaXQgaXMgYmVjYXVzZSBJIHNlbnQgaXQgZnJvbSBhbm90aGVyIGVtYWlsIGFjY291 bnQgd2hpY2ggd2Fzbid0IHN1YnNjcmliZWQgdG8gdGhlIFNDSU0gZ3JvdXAuIFRoaXMgZW1haWwg YWltcyB0byBjb3JyZWN0IHRoYXQgbWlzdGFrZSkgCiAgICAKICAgICAKICAgIE91ciBjb21wYW55 IHdhbnRzIHRvIGltcGxlbWVudCBTQ0lNIDEuMSBmb3Igb3VyIGlkZW50aXR5IG1hbmFnZW1lbnQg cHJvZHVjdC4gSSB0aGluayBTQ0lNIGlzIGdyZWF0IHlldCBzaW1wbGUgZnJhbWV3b3JrIGFuZCBp cyB2ZXJ5IGVhZ2VyIHRvIGltcGxlbWVudCBpdC4gSG93ZXZlciwgSSBmaW5kIG9uZSBwcm9ibGVt IHdoZW4gSSB0cnkgdG8gYWRvcHQgU0NJTSBmb3Igb3VyIHN5c3RlbTogc2ltcGx5IHNwZWFraW5n LCBvdXIgc3lzdGVtIHN1cHBvcnRzIG11bHRpcGxlIHVzZXJuYW1lcy4gSW4gb3RoZXIgd29yZHMs IG9uZSB1c2VyIGNhbiBoYXZlIG1vcmUgdGhhbiBvbmUgdXNlcm5hbWVzLCBmb3IgZXhhbXBsZTog CiAgICAgCiAgICAKICAgIC0gICAgICAgICAgIAogICAgVXNlcm5hbWVfYXNfdXNlcm5hbWU6IGJq ZW5zZW4uIAogICAgIAogICAgCiAgICAtICAgICAgICAgICAKICAgIEVtYWlsX2FzX3VzZXJuYW1l OiBiamVuc2VuQGV4YW1wbGUuY29tIAogICAgIAogICAgQSB1c2VyIGNhbiB1c2UgYW55IG9mIHRo ZSCTdXNlcm5hbWWUIHRvIGxvZ2luLiAKICAgICAKICAgIAogICAgCiAgICAgICAgCiAgICAgCiAg ICBBcyBhIGNvbnNlcXVlbnQsIHdoZW4gYSBjcmVhdGUgdXNlciByZXF1ZXN0IG5lZWRzIHRvIHNw ZWNpZnkgbm90IG9ubHkgYSB1c2VybmFtZSBidXQgYWxzbyB0aGUgdHlwZSBvZiB0aGF0IHVzZXJu YW1lLiBVbmZvcnR1bmF0ZWx5LCBJIGNvdWxkbpJ0IGZpbmQgYW55IHByZWRlZmluZWQgU0NJTSBh dHRyaWJ1dGUgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIHRoYXQgk3R5cGUgb2YgdXNlcm5hbWWULiAK ICAgICAKICAgIAogICAgCiAgICAgICAgCiAgICAgCiAgICBJIGNhbiB0aGluayBvZiBhIGZldyBv cHRpb25zOiAKICAgICAKICAgIAogICAgCiAgICAgICAgCiAgICAgCiAgICBBIHN0YW5kYXJkIFND SU0gY3JlYXRlIHVzZXIgcmVxdWVzdDogCiAgICAgCiAgICAgICB7IAogICAgICAKICAgICAgICAg InNjaGVtYXMiOlsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLCAKICAgICAgCiAgICAgICAg ICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICAgCiAgICAgICAgICJleHRlcm5hbElkIjoiYmpl bnNlbiIsIAogICAgICAKICAgICAgICAgIm5hbWUiOnsgCiAgICAgIAogICAgICAgICAgICJmb3Jt YXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLCAKICAgICAgCiAgICAgICAgICAgImZh bWlseU5hbWUiOiJKZW5zZW4iLCAKICAgICAgCiAgICAgICAgICAgImdpdmVuTmFtZSI6IkJhcmJh cmEiIAogICAgICAKICAgICAgICAgfSAKICAgICAgCiAgICAgICB9IAogICAgICAKICAgIAogICAg CiAgICAgICAgCiAgICAgCiAgICBBcHByb2FjaCAxOiBleHRlbmRlZCBTQ0lNIGNyZWF0ZSB1c2Vy IHJlcXVlc3Q6IAogICAgIAogICAgICAgeyAKICAgICAgCiAgICAgICAgICJzY2hlbWFzIjpbInVy bjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwgCiAgICAgIAogICAgICAgICAidXNlck5hbWUiOiJi amVuc2VuIiwgCiAgICAgIAogICAgICAgICAiZXh0ZXJuYWxJZCI6ImJqZW5zZW4iLCAKICAgICAg CiAgICAgICAgICJuYW1lIjp7IAogICAgICAKICAgICAgICAgICAiZm9ybWF0dGVkIjoiTXMuIEJh cmJhcmEgSiBKZW5zZW4gSUlJIiwgCiAgICAgIAogICAgICAgICAgICJmYW1pbHlOYW1lIjoiSmVu c2VuIiwgCiAgICAgIAogICAgICAgICAgICJnaXZlbk5hbWUiOiJCYXJiYXJhIiAKICAgICAgCiAg ICAgICAgIH0gCiAgICAgIAogICAgICAgICAidXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246b3Vy cHJvZHVjdG5hbWU6MS4wIjp7IAogICAgICAKICAgICAgICAgICAgICAgICAgICAidXNlck5hbWVU eXBlIjoiZW1haWxfYXNfdXNlcm5hbWUiLCAKICAgICAgCiAgICAgICAgIH0gCiAgICAgIAogICAg ICAgfSAKICAgICAgCiAgICAKICAgIAogICAgICAgIAogICAgIAogICAgQXBwcm9hY2ggMjogZGVm aW5lIHNlcGFyYXRlIGVuZHBvaW50IGZvciBlYWNoIHVzZXJuYW1lIHR5cGU6IGFuIGVuZHBvaW50 IHRvIGNyZWF0ZSBhIHVzZXIgd2lsbCBsb29rIGxpa2U6IGh0dHBzOi8vZXhhbXBsZS5jb20vZW1h aWxfYXNfdXNlcm5hbWUvdjEvVXNlcnMgCiAgICAgCiAgICAKICAgIAogICAgICAgIAogICAgIAog ICAgQXBwcm9hY2ggMzogQXNrIHRoZSBjbGllbnQgZGV2ZWxvcGVyIHRvIGFwcGVuZCBhIJN1c2Vy TmFtZVR5cGU9hZQgcGFyYW1ldGVyIHRvIHRoZSBlbmQgb2YgdGhlIHJlcXVlc3QuIAogICAgIAog ICAgCiAgICAKICAgICAgICAKICAgICAKICAgIENvdWxkIHlvdSBwbGVhc2UgdGVsbCBtZSBpZiBh bnkgb2YgdGhlIGFwcHJvYWNoZXMgYWJvdmUgYXJlIFNDSU0gY29tcGxpYW50IGFuZCB1c2FibGU/ IFdoYXQgYWx0ZXJuYXRpdmVzIGRvIEkgaGF2ZT8gCiAgICAgCiAgICAKICAgIAogICAgICAgIAog ICAgIAogICAgVGhhbmsgeW91IGluIGFkdmFuY2UsIAogICAgIAogICAgTmd1eSBEdWMgVGh1YW4u IAogICAgIAogICAKICANCiAJCSAJICAgCQkgIA== --_b5f068c4-5716-47d9-8230-f7a176ab2275_ Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGkgQmpvcm4sPHA+VGhhbmsgeW91IHRha2luZyB0aW1l IHRvIHJlcGx5IG15IHF1ZXN0aW9uLiBQbGVhc2UgbGV0IG1lIGV4cGxhaW4gYSBsaXR0bGUgYml0 IGFib3V0IG91ciB1c2VybmFtZSBzeXN0ZW0uIEluIGZhY3QsIG5vcm1hbCB1c2VybmFtZSBhbmQg ZW1haWwgYXJlIG9ubHkgdHdvIGV4YW1wbGVzLiZuYnNwO090aGVyIHBvc3NpYmlsaXRpZXMgaW5j bHVkZSZuYnNwO3NvY2lhbCBzZWN1cml0eSBudW1iZXIsIG9yIGFueSB1c2VyLWRlZmluZWQgdHlw ZXMuIFRoZXJlIGlzIG5vIGxpbWl0YXRpb24gd2l0aCByZWdhcmQgdG8gdXNlcm5hbWUgdHlwZXMu PHA+Jm5ic3A7PHA+TG9va2luZyBhdCB0aGUgcHJvYmxlbSBmcm9tIHRoZSBkYXRhYmFzZSBwb2lu dCBvZiB2aWV3LCB3ZSBkb24ndCBoYXZlIGEgc2luZ2xlIGNvbHVtbiB0byBzdG9yZSB1c2VybmFt ZS4gSW5zdGVhZCwgYSB1c2VyIGhhcyBhIGxpc3Qgb2YmbmJzcDtjbGFpbXMsJm5ic3A7ZS5nLjo8 cD4mbmJzcDstIDxhIGhyZWY9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUv aWRlbnRpdHkvY2xhaW1zL25hbWUiPmh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUv MDUvaWRlbnRpdHkvY2xhaW1zL25hbWU8L2E+PHA+Jm5ic3A7LSA8YSBocmVmPSJodHRwOi8vc2No ZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3Mi Pmh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL2Vt YWlsYWRkcmVzczwvYT48cD4mbmJzcDstIGdvdjpzYW1sOmF0dHJpYnV0ZTpTb2NpYWxTZWN1cml0 eU51bWJlcjxwPi0gLi4uPHA+QW55Jm5ic3A7b2YgdGhlbSBjYW4gYmUgdXNlZCBhcyB1c2VybmFt ZS4gT3VyIGNsaWVudHMgY2FuIHNldCB1cCBhIGxvZ2luIHBhZ2UgZm9yIHB1YmxpYyB1c2VycyB0 byB1c2UgTmFtZSBmb3IgdXNlcm5hbWUsIGFuZCBhIGxvZ2luIHBhZ2UgZm9yIGNvcnBvcmF0ZSB1 c2VycyB0byB1c2UgZW1haWwgYWRkcmVzcyBhcyB1c2VybmFtZS4mbmJzcDtIb3dldmVyLCB3aGVu IGNyZWF0aW5nIGEgbmV3IHVzZXIsICpvbmUgYW5kIG9ubHkgb25lKiB1c2VybmFtZSB0eXBlIGlz IHJlcXVpcmVkLjxwPiZuYnNwOzxwPlNvOjxwPlE6IEFyZSBib3RoIGVtYWlsIGFuZCBhIHVzZXIg bmFtZSByZXF1aXJlZCBieSB5b3VyIHN5c3RlbSB3aGVuIGNyZWF0aW5nIGEgdXNlcj8gJm5ic3A7 ICAgPGJyPiBBOiZuYnNwO05vLCBvbmx5IG9uZSBpcyByZXF1aXJlZC4gQW55IG9mIHRoZSB1c2Vy bmFtZSB0eXBlIGlzIGZpbmUuPGJyPjxicj5JIGFncmVlIHdpdGggeW91IGFib3V0ICJJbiBhbGwg Y2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3aXRoIGVpdGhlciBuYW1lIHNob3Vs ZCBiZSBkb25lIGluIHRoZSBhdXRoZW50aWNhdGlvbiBsb2dpYywgbm90IGluIHRoZSBwcm92aXNp b25pbmcgZGF0YSB3aGVuIHRoZSB1c2VyIGlzIGNyZWF0ZWQuIiBUaGUgcG9pbnQgaGVyZSBpcyB0 aGF0IHdoZW4gYSB1c2VyIGlzIGNyZWF0ZWQsIEkgbmVlZCB0byBrbm93IHdoYXQgdXNlcm5hbWUg dHlwZSB0byBtYXAgdGhlICJ1c2VybmFtZSIgc3BlY2lmaWVkIGluIGFuIFNDSU0gcmVxdWVzdCB0 by48YnI+PEJSPkFtIEkgcmlnaHQgdGhhdCB5b3VyIHJlcGx5IG1lYW5zIHVzaW5nIGEgY3VzdG9t IGF0dHJpYnV0ZSBsaWtlcyB0aGUgZm9sbG93aW5nIGlzIHRoZSBiZXN0IHdheSBJIHNob3VsZCBk bz88QlI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Ijsg Zm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJ1cm46c2NpbTpzY2hl bWFzOmV4dGVuc2lvbjpvdXJwcm9kdWN0bmFtZToxLjAiOnsgICAgICAgPC9zcGFuPjxCUj48cCBj bGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6 ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAidXNlck5hbWVUeXBl IjoiZW1haWxfYXNfdXNlcm5hbWUiLCAgICAgICA8L3NwYW4+PC9wPjxwIGNsYXNzPSJlY3hNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwO30gPC9zcGFuPjwvcD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz48L3NwYW4+Jm5i c3A7PEJSPjxicj4mbmJzcDs8QlI+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBjYW1icmlhOyI+QmVz dCBSZWdhcmRzLDwvcD4KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBjYW1icmlhOyI+VGh1YW4uPC9w PgombmJzcDs8QlI+PGRpdj48aHIgaWQ9InN0b3BTcGVsbGluZyI+RGF0ZTogV2VkLCAyIE9jdCAy MDEzIDE3OjM0OjUxICswMDAwPGJyPkZyb206IGJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29t PGJyPlRvOiBuZ3V5ZHRodWFuQGhvdG1haWwuY29tOyBzY2ltQGlldGYub3JnPGJyPlN1YmplY3Q6 IFJFOiBbc2NpbV0gUmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhIG11bHRpLXVzZXJu YW1lIHN5c3RlbTxicj48YnI+CiAKIAogIFlvdSBjb3VsZCBhZGQgYSBjdXN0b20gYXR0cmlidXRl IGZvciB0aGUgdXNlciBuYW1lIHR5cGUgLSB0aG9zZSBraW5kcyBvZiBleHRlbnNpb25zIGFyZSBz dXBwb3J0ZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uICZuYnNwO0hvd2V2ZXIsIEknbSBkbyBub3Qg dGhpbmsgbWl4aW5nIHRoZSB0d28gYXR0cmlidXRlIHR5cGVzIGlzIHRoZSByaWdodCBzb2x1dGlv bi4KICA8YnI+IAogIDxicj4gQXJlIGJvdGggZW1haWwgYW5kIGEgdXNlciBuYW1lIHJlcXVpcmVk IGJ5IHlvdXIgc3lzdGVtIHdoZW4gY3JlYXRpbmcgYSB1c2VyPyAmbmJzcDsKICA8YnI+IElmIHNv LCBJIHdvdWxkIHJlY29tbWVuZCBzdG9yaW5nIGVhY2ggaW4gdGhlaXIgcmVzcGVjdGl2ZSBwcmVk ZWZpbmVkIGF0dHJpYnV0ZXMuICZuYnNwOyZuYnNwOwogIDxicj4gCiAgPGJyPiBJZiBvbmx5IGFu IGVtYWlsIGFkZHJlc3MgaXMgcmVxdWlyZWQgd2hlbiBjcmVhdGluZyBhIHVzZXIsIHdoZW4gdGhh dCBpcyBhbGwgeW91IGhhdmUsIEkgd291bGQgcmVjb21tZW5kIHN0b3JpbmcgdGhlIGVtYWlsIGlu IGJvdGggYXR0cmlidXRlcy4KICA8YnI+IAogIDxicj4gSWYgb25seSBhIHVzZXIgbmFtZSBpcyBy ZXF1aXJlZCwgYW5kIHRoZSBlbWFpbCBpcyBvcHRpb25hbCwgdGhlbiBvZiBjb3Vyc2Ugc3RvcmUg dGhlIHVzZXIgbmFtZSBhbmQgbGVhdmUgdGhlIGVtYWlsIGJsYW5rLgogIDxicj4gCiAgPGJyPiBJ biBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3aXRoIGVpdGhlciBuYW1l IHNob3VsZCBiZSBkb25lIGluIHRoZSBhdXRoZW50aWNhdGlvbiBsb2dpYywgbm90IGluIHRoZSBw cm92aXNpb25pbmcgZGF0YSB3aGVuIHRoZSB1c2VyIGlzIGNyZWF0ZWQuCiAgPGJyPiAKICA8YnI+ IC1Cam9ybiBBYW5uZXN0YWQKICA8YnI+IAogIDxicj4gCiAgPGJyPiAKICA8YnI+IAogIDxicj4g CiAgPGhyPiAKICA8Yj5Gcm9tOjwvYj4gCiAgPGEgc3R5bGU9ImN1cnNvcjogcG9pbnRlcjsiIGhy ZWY9Im1haWx0bzpEdWMgVGh1YW4gTmd1eSAobmd1eWR0aHVhbkBob3RtYWlsLmNvbSkiPkR1YyBU aHVhbiBOZ3V5IChuZ3V5ZHRodWFuQGhvdG1haWwuY29tKTwvYT4KICA8YnI+IAogIDxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEsIDIwMTMgMTA6MjggUE0KICA8YnI+IAogIDxiPlRvOjwv Yj4gCiAgPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+CiAg PGJyPiAKICA8Yj5TdWJqZWN0PC9iPjogW3NjaW1dIFJlc2VuZDogSG93IHRvIHVzZSBTQ0lNIGFn YWluc3QgYSBtdWx0aS11c2VybmFtZSBzeXN0ZW0gCiAgPGRpdiBzdHlsZT0iaGVpZ2h0OiA1cHg7 Ij4KICAgICZuYnNwOwogIDwvZGl2PiAKICA8c3R5bGU+PCEtLQouRXh0ZXJuYWxDbGFzcyAuZWN4 aG1tZXNzYWdlIFAgewpwYWRkaW5nOjBweDsKfQoKLkV4dGVybmFsQ2xhc3MgYm9keS5lY3hobW1l c3NhZ2Ugewpmb250LXNpemU6MTJwdDsKZm9udC1mYW1pbHk6Q2FsaWJyaTsKfQoKLS0+PC9zdHls ZT4gCiAgPGRpdiBkaXI9Imx0ciI+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gSGkgU0NJ TSBncm91cHMsIAogICAgPC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+IChJIHJlc2Vu ZCB0aGlzIGVtYWlsIGJlY2F1c2UgaXQgc2VlbXMgdGhlIGZpcnN0IG9uZSBnb3QgbG9zdCBzb21l d2hlcmUuIFBlcmhhcHMgaXQgaXMgYmVjYXVzZSBJIHNlbnQgaXQgZnJvbSBhbm90aGVyIGVtYWls IGFjY291bnQgd2hpY2ggd2Fzbid0IHN1YnNjcmliZWQgdG8gdGhlIFNDSU0gZ3JvdXAuIFRoaXMg ZW1haWwgYWltcyB0byBjb3JyZWN0IHRoYXQgbWlzdGFrZSk8L3A+IAogICA8cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIj4gCiAgICA8L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gT3VyIGNv bXBhbnkgd2FudHMgdG8gaW1wbGVtZW50IFNDSU0gMS4xIGZvciBvdXIgaWRlbnRpdHkgbWFuYWdl bWVudCBwcm9kdWN0LiBJIHRoaW5rIFNDSU0gaXMgZ3JlYXQgeWV0IHNpbXBsZSBmcmFtZXdvcmsg YW5kIGlzIHZlcnkgZWFnZXIgdG8gaW1wbGVtZW50IGl0LiBIb3dldmVyLCBJIGZpbmQgb25lIHBy b2JsZW0gd2hlbiBJIHRyeSB0byBhZG9wdCBTQ0lNIGZvciBvdXIgc3lzdGVtOiBzaW1wbHkgc3Bl YWtpbmcsIG91ciBzeXN0ZW0gc3VwcG9ydHMgbXVsdGlwbGUgdXNlcm5hbWVzLiBJbiBvdGhlciB3 b3Jkcywgb25lIHVzZXIgY2FuIGhhdmUgbW9yZSB0aGFuIG9uZSB1c2VybmFtZXMsIGZvciBleGFt cGxlOiAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6IC0wLjI1aW47Ij4gCiAgICA8c3Bhbj48c3Bhbj4tPHNwYW4gc3R5bGU9J2Zv bnQ6IDdwdC9ub3JtYWwgIlRpbWVzIE5ldyBSb21hbiI7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7 IGZvbnQtc3RyZXRjaDogbm9ybWFsOyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPiAKICAgIFVzZXJuYW1l X2FzX3VzZXJuYW1lOiBiamVuc2VuLiAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6IC0wLjI1aW47Ij4gCiAgICA8c3Bhbj48c3Bh bj4tPHNwYW4gc3R5bGU9J2ZvbnQ6IDdwdC9ub3JtYWwgIlRpbWVzIE5ldyBSb21hbiI7IGZvbnQt c2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPiAKICAgIEVtYWlsX2FzX3VzZXJuYW1lOiA8Zm9udCBjb2xvcj0iIzAwMDBmZiI+PGEgaHJl Zj0ibWFpbHRvOmJqZW5zZW5AZXhhbXBsZS5jb20iPmJqZW5zZW5AZXhhbXBsZS5jb208L2E+PC9m b250PiAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBBIHVzZXIgY2FuIHVz ZSBhbnkgb2YgdGhlIJN1c2VybmFtZZQgdG8gbG9naW4uIAogICAgPC9wPiAKICAgPHAgY2xhc3M9 ImVjeE1zb05vcm1hbCI+IAogICAgCiAgICAgICZuYnNwOyAKICAgIDwvcD4gCiAgIDxwIGNsYXNz PSJlY3hNc29Ob3JtYWwiPiBBcyBhIGNvbnNlcXVlbnQsIHdoZW4gYSBjcmVhdGUgdXNlciByZXF1 ZXN0IG5lZWRzIHRvIHNwZWNpZnkgbm90IG9ubHkgYSB1c2VybmFtZSBidXQgYWxzbyB0aGUgdHlw ZSBvZiB0aGF0IHVzZXJuYW1lLiBVbmZvcnR1bmF0ZWx5LCBJIGNvdWxkbpJ0IGZpbmQgYW55IHBy ZWRlZmluZWQgU0NJTSBhdHRyaWJ1dGUgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIHRoYXQgk3R5cGUg b2YgdXNlcm5hbWWULiAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiAKICAg IAogICAgICAmbmJzcDsgCiAgICA8L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gSSBj YW4gdGhpbmsgb2YgYSBmZXcgb3B0aW9uczogCiAgICA8L3A+IAogICA8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj4gCiAgICAKICAgICAgJm5ic3A7IAogICAgPC9wPiAKICAgPHAgY2xhc3M9ImVjeE1z b05vcm1hbCI+IEEgc3RhbmRhcmQgU0NJTSBjcmVhdGUgdXNlciByZXF1ZXN0OiAKICAgIDwvcD4g CiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3 YXlzOyI+IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7 IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyB7IAogICAgIDwvc3Bhbj48L3A+IAogICA8 cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsi PiA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250 LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInNjaGVtYXMiOlsidXJuOnNj aW06c2NoZW1hczpjb3JlOjEuMCJdLCAKICAgICA8L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVj eE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0 Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICA8 L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNv dXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJl eHRlcm5hbElkIjoiYmplbnNlbiIsIAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5n PSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7 Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIm5hbWUiOnsgCiAgICAgPC9zcGFuPjwvcD4gCiAg IDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZv bnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZm9y bWF0dGVkIjoiTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwgCiAgICAgPC9zcGFuPjwvcD4gCiAg IDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZv bnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZmFt aWx5TmFtZSI6IkplbnNlbiIsIAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5nPSJF TiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImdpdmVuTmFtZSI6IkJhcmJhcmEi IAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFt aWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfSAKICAgICA8L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdm b250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7 IH0gCiAgICAgPC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiAKICAgIAog ICAgICAmbmJzcDsgCiAgICA8L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gQXBwcm9h Y2ggMTogZXh0ZW5kZWQgU0NJTSBjcmVhdGUgdXNlciByZXF1ZXN0OiAKICAgIDwvcD4gCiAgIDxw IGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQt c2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyB7IAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFz cz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3Bh biBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6 IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInNjaGVtYXMiOlsidXJuOnNjaW06c2No ZW1hczpjb3JlOjEuMCJdLCAKICAgICA8L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4i IHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICA8L3NwYW4+ PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIg TmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJleHRlcm5h bElkIjoiYmplbnNlbiIsIAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5nPSJFTiIg c3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgIm5hbWUiOnsgCiAgICAgPC9zcGFuPjwvcD4gCiAgIDxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+IDxz cGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6 ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZm9ybWF0dGVk IjoiTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwgCiAgICAgPC9zcGFuPjwvcD4gCiAgIDxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+IDxz cGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6 ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZmFtaWx5TmFt ZSI6IkplbnNlbiIsIAogICAgIDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5nPSJFTiIgc3R5 bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImdpdmVuTmFtZSI6IkJhcmJhcmEiIAogICAg IDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsiPiA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAi Q291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fSAKICAgICA8L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZh bWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICJ1cm46c2NpbTpzY2hlbWFzOmV4dGVuc2lvbjpvdXJwcm9kdWN0bmFtZToxLjAiOnsg CiAgICAgPC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1p bHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAidXNlck5hbWVUeXBlIjoiZW1haWxfYXNfdXNlcm5hbWUiLCAKICAgICA8 L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOiBhbHdheXM7Ij4gPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNv dXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO30g CiAgICAgPC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+IDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1p bHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyB9IAogICAg IDwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gCiAgICAKICAgICAgJm5i c3A7IAogICAgPC9wPiAKICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+IEFwcHJvYWNoIDI6IGRl ZmluZSBzZXBhcmF0ZSBlbmRwb2ludCBmb3IgZWFjaCB1c2VybmFtZSB0eXBlOiBhbiBlbmRwb2lu dCB0byBjcmVhdGUgYSB1c2VyIHdpbGwgbG9vayBsaWtlOiA8YSBocmVmPSJodHRwczovL2V4YW1w bGUuY29tL2VtYWlsX2FzX3VzZXJuYW1lL3YxL1VzZXJzIiB0YXJnZXQ9Il9ibGFuayI+PGZvbnQg Y29sb3I9IiMwMDAwZmYiPmh0dHBzOi8vZXhhbXBsZS5jb20vZW1haWxfYXNfdXNlcm5hbWUvdjEv VXNlcnM8L2ZvbnQ+PC9hPiAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiAK ICAgIAogICAgICAmbmJzcDsgCiAgICA8L3A+IAogICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4g QXBwcm9hY2ggMzogQXNrIHRoZSBjbGllbnQgZGV2ZWxvcGVyIHRvIGFwcGVuZCBhIJN1c2VyTmFt ZVR5cGU9hZQgcGFyYW1ldGVyIHRvIHRoZSBlbmQgb2YgdGhlIHJlcXVlc3QuIAogICAgPC9wPiAK ICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+IAogICAgCiAgICAgICZuYnNwOyAKICAgIDwvcD4g CiAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBDb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgaWYg YW55IG9mIHRoZSBhcHByb2FjaGVzIGFib3ZlIGFyZSBTQ0lNIGNvbXBsaWFudCBhbmQgdXNhYmxl PyBXaGF0IGFsdGVybmF0aXZlcyBkbyBJIGhhdmU/IAogICAgPC9wPiAKICAgPHAgY2xhc3M9ImVj eE1zb05vcm1hbCI+IAogICAgCiAgICAgICZuYnNwOyAKICAgIDwvcD4gCiAgIDxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPiBUaGFuayB5b3UgaW4gYWR2YW5jZSwgCiAgICA8L3A+IAogICA8cCBjbGFz cz0iZWN4TXNvTm9ybWFsIj4gTmd1eSBEdWMgVGh1YW4uIAogICAgPC9wPiAKICA8L2Rpdj4gCiAg PGJyPjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_b5f068c4-5716-47d9-8230-f7a176ab2275_-- From bjorn.aannestad@unboundid.com Thu Oct 3 06:58:51 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38B621E8098 for ; Thu, 3 Oct 2013 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoisZUGIPBU1 for ; Thu, 3 Oct 2013 06:58:23 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 56CB521E8099 for ; Thu, 3 Oct 2013 06:51:25 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so5582658iec.32 for ; Thu, 03 Oct 2013 06:51:24 -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; bh=dCw34CFV8GeWKno7b9Ypi3H8sBZIELhRox089MH0ADI=; b=ieiseys8ILP6E2rbcrJusXwe0KauXhhp1bADfYmbjAywDH/CgfT6g72Sy4ChsCAgv2 2wUw6MPkCAMMT7sdhWDsOBxRck13rCbCgWsvR5weqEPY6o1Q8zeKez/ztIDdSW5nBFiH rJKfTUjSSeMNvDNU1JpEDROyGl4XSug4jKrUFhrJ6RbLQSakdCo7/Xw3z0vrFVOoYsmw rUKHrONZBHRSuDBGtHDkGrmmpmhglhqUTBQp3+Gm/ZSo/ssig3jxoy1BUFimc3Ni+9XN 00YMGw+/H0c77T04sJCR7H08F3TQekCQw9ctE03/aDgVwZVnl1vtqUXrp5ByYcjMCUS2 AlCQ== X-Gm-Message-State: ALoCoQl4oVIkxgsqI+Tqys1Civwfo9Jqx4ZfPz4YIHwrR76hz7efUy+LVRBnXi4/R35wH7aGmu0R X-Received: by 10.42.121.132 with SMTP id j4mr5198096icr.42.1380808284620; Thu, 03 Oct 2013 06:51:24 -0700 (PDT) Received: from [10.8.1.116] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPSA id p5sm8706911igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 06:51:23 -0700 (PDT) Message-ID: <524D7659.7020602@unboundid.com> Date: Thu, 03 Oct 2013 08:51:21 -0500 From: Bjorn Aannestad User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: scim@ietf.org References: , <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090403070907010803010204" Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:58:54 -0000 This is a multi-part message in MIME format. --------------090403070907010803010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ah, I missed the one-and-only-one aspect. Yes, the custom attribute solution is most compliant with the specification. -Bjorn On 2013-10-03 2:46 AM, Duc Thuan Nguy wrote: > Hi Bjorn, > > Thank you taking time to reply my question. Please let me explain a > little bit about our username system. In fact, normal username and > email are only two examples. Other possibilities include social > security number, or any user-defined types. There is no limitation > with regard to username types. > > Looking at the problem from the database point of view, we don't have > a single column to store username. Instead, a user has a list > of claims, e.g.: > > - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name > > - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress > > - gov:saml:attribute:SocialSecurityNumber > > - ... > > Any of them can be used as username. Our clients can set up a login > page for public users to use Name for username, and a login page for > corporate users to use email address as username. However, when > creating a new user, *one and only one* username type is required. > > So: > > Q: Are both email and a user name required by your system when > creating a user? > A: No, only one is required. Any of the username type is fine. > > I agree with you about "In all cases, allowing the user to log in with > either name should be done in the authentication logic, not in the > provisioning data when the user is created." The point here is that > when a user is created, I need to know what username type to map the > "username" specified in an SCIM request to. > > Am I right that your reply means using a custom attribute likes the > following is the best way I should do? > "urn:scim:schemas:extension:ourproductname:1.0":{ > > "userNameType":"email_as_username", > > } > > > > > Best Regards, > > Thuan. > > > ------------------------------------------------------------------------ > Date: Wed, 2 Oct 2013 17:34:51 +0000 > From: bjorn.aannestad@unboundid.com > To: nguydthuan@hotmail.com; scim@ietf.org > Subject: RE: [scim] Resend: How to use SCIM against a multi-username > system > > You could add a custom attribute for the user name type - those kinds > of extensions are supported by the specification. However, I'm do not > think mixing the two attribute types is the right solution. > > Are both email and a user name required by your system when creating a > user? > If so, I would recommend storing each in their respective predefined > attributes. > > If only an email address is required when creating a user, when that > is all you have, I would recommend storing the email in both attributes. > > If only a user name is required, and the email is optional, then of > course store the user name and leave the email blank. > > In all cases, allowing the user to log in with either name should be > done in the authentication logic, not in the provisioning data when > the user is created. > > -Bjorn Aannestad > > > > > ------------------------------------------------------------------------ > *From:* Duc Thuan Nguy (nguydthuan@hotmail.com) > > *Sent:* Tuesday, October 1, 2013 10:28 PM > *To:* scim@ietf.org > *Subject*: [scim] Resend: How to use SCIM against a multi-username system > > Hi SCIM groups, > > (I resend this email because it seems the first one got lost > somewhere. Perhaps it is because I sent it from another email account > which wasn't subscribed to the SCIM group. This email aims to correct > that mistake) > > Our company wants to implement SCIM 1.1 for our identity management > product. I think SCIM is great yet simple framework and is very eager > to implement it. However, I find one problem when I try to adopt SCIM > for our system: simply speaking, our system supports multiple > usernames. In other words, one user can have more than one usernames, > for example: > > -Username_as_username: bjensen. > > -Email_as_username: bjensen@example.com > > A user can use any of the "username" to login. > > As a consequent, when a create user request needs to specify not only > a username but also the type of that username. Unfortunately, I > couldn't find any predefined SCIM attribute which can be used for that > "type of username". > > I can think of a few options: > > A standard SCIM create user request: > > { > > "schemas":["urn:scim:schemas:core:1.0"], > > "userName":"bjensen", > > "externalId":"bjensen", > > "name":{ > > "formatted":"Ms. Barbara J Jensen III", > > "familyName":"Jensen", > > "givenName":"Barbara" > > } > > } > > Approach 1: extended SCIM create user request: > > { > > "schemas":["urn:scim:schemas:core:1.0"], > > "userName":"bjensen", > > "externalId":"bjensen", > > "name":{ > > "formatted":"Ms. Barbara J Jensen III", > > "familyName":"Jensen", > > "givenName":"Barbara" > > } > > "urn:scim:schemas:extension:ourproductname:1.0":{ > > "userNameType":"email_as_username", > > } > > } > > Approach 2: define separate endpoint for each username type: an > endpoint to create a user will look like: > https://example.com/email_as_username/v1/Users > > Approach 3: Ask the client developer to append a "userNameType=..." > parameter to the end of the request. > > Could you please tell me if any of the approaches above are SCIM > compliant and usable? What alternatives do I have? > > Thank you in advance, > > Nguy Duc Thuan. > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------090403070907010803010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ah, I missed the one-and-only-one aspect.  

Yes, the custom attribute solution is most compliant with the specification.

-Bjorn

On 2013-10-03 2:46 AM, Duc Thuan Nguy wrote:
Hi Bjorn,

Thank you taking time to reply my question. Please let me explain a little bit about our username system. In fact, normal username and email are only two examples. Other possibilities include social security number, or any user-defined types. There is no limitation with regard to username types.

 

Looking at the problem from the database point of view, we don't have a single column to store username. Instead, a user has a list of claims, e.g.:

 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

 - gov:saml:attribute:SocialSecurityNumber

- ...

Any of them can be used as username. Our clients can set up a login page for public users to use Name for username, and a login page for corporate users to use email address as username. However, when creating a new user, *one and only one* username type is required.

 

So:

Q: Are both email and a user name required by your system when creating a user?  
A: No, only one is required. Any of the username type is fine.

I agree with you about "In all cases, allowing the user to log in with either name should be done in the authentication logic, not in the provisioning data when the user is created." The point here is that when a user is created, I need to know what username type to map the "username" specified in an SCIM request to.

Am I right that your reply means using a custom attribute likes the following is the best way I should do?
     "urn:scim:schemas:extension:ourproductname:1.0":{

                "userNameType":"email_as_username",

     }

 

 

Best Regards,

Thuan.

 
Date: Wed, 2 Oct 2013 17:34:51 +0000
From: bjorn.aannestad@unboundid.com
To: nguydthuan@hotmail.com; scim@ietf.org
Subject: RE: [scim] Resend: How to use SCIM against a multi-username system

You could add a custom attribute for the user name type - those kinds of extensions are supported by the specification.  However, I'm do not think mixing the two attribute types is the right solution.

Are both email and a user name required by your system when creating a user?  
If so, I would recommend storing each in their respective predefined attributes.   

If only an email address is required when creating a user, when that is all you have, I would recommend storing the email in both attributes.

If only a user name is required, and the email is optional, then of course store the user name and leave the email blank.

In all cases, allowing the user to log in with either name should be done in the authentication logic, not in the provisioning data when the user is created.

-Bjorn Aannestad




From: Duc Thuan Nguy (nguydthuan@hotmail.com)
Sent: Tuesday, October 1, 2013 10:28 PM
To: scim@ietf.org
Subject: [scim] Resend: How to use SCIM against a multi-username system
 

Hi SCIM groups,

(I resend this email because it seems the first one got lost somewhere. Perhaps it is because I sent it from another email account which wasn't subscribed to the SCIM group. This email aims to correct that mistake)

Our company wants to implement SCIM 1.1 for our identity management product. I think SCIM is great yet simple framework and is very eager to implement it. However, I find one problem when I try to adopt SCIM for our system: simply speaking, our system supports multiple usernames. In other words, one user can have more than one usernames, for example:

-          Username_as_username: bjensen.

-          Email_as_username: bjensen@example.com

A user can use any of the “username” to login.

 

As a consequent, when a create user request needs to specify not only a username but also the type of that username. Unfortunately, I couldn’t find any predefined SCIM attribute which can be used for that “type of username”.

 

I can think of a few options:

 

A standard SCIM create user request:

   {

     "schemas":["urn:scim:schemas:core:1.0"],

     "userName":"bjensen",

     "externalId":"bjensen",

     "name":{

       "formatted":"Ms. Barbara J Jensen III",

       "familyName":"Jensen",

       "givenName":"Barbara"

     }

   }

 

Approach 1: extended SCIM create user request:

   {

     "schemas":["urn:scim:schemas:core:1.0"],

     "userName":"bjensen",

     "externalId":"bjensen",

     "name":{

       "formatted":"Ms. Barbara J Jensen III",

       "familyName":"Jensen",

       "givenName":"Barbara"

     }

     "urn:scim:schemas:extension:ourproductname:1.0":{

                "userNameType":"email_as_username",

     }

   }

 

Approach 2: define separate endpoint for each username type: an endpoint to create a user will look like: https://example.com/email_as_username/v1/Users

 

Approach 3: Ask the client developer to append a “userNameType=…” parameter to the end of the request.

 

Could you please tell me if any of the approaches above are SCIM compliant and usable? What alternatives do I have?

 

Thank you in advance,

Nguy Duc Thuan. 




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

--------------090403070907010803010204-- From aredston@switchresearch.com Thu Oct 3 23:23:53 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3785C21F99BD for ; Thu, 3 Oct 2013 23:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XuV-kDh5t-K for ; Thu, 3 Oct 2013 23:23:42 -0700 (PDT) Received: from appa.redston.com (host217-37-178-214.in-addr.btopenworld.com [217.37.178.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D621F9702 for ; Thu, 3 Oct 2013 23:23:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by appa.redston.com (Postfix) with ESMTP id E4B9048886 for ; Fri, 4 Oct 2013 07:12:07 +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 Djbhs9SDdye0 for ; Fri, 4 Oct 2013 07:12:03 +0100 (BST) Received: from [127.0.0.1] (unknown [192.168.148.27]) by appa.redston.com (Postfix) with ESMTPSA id 32F8048884 for ; Fri, 4 Oct 2013 07:12:03 +0100 (BST) Message-ID: <524E5EDB.8050307@switchresearch.com> Date: Fri, 04 Oct 2013 07:23:23 +0100 From: Alex Redston User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "scim@ietf.org" References: , <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070008070104030302090803" X-Antivirus: avast! (VPS 131002-0, 02/10/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 06:23:53 -0000 This is a multi-part message in MIME format. --------------070008070104030302090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Outside of the context of SCIM similar scenarios have come up, like in the naming of the "locality" object class in NetWare Directory Services. The naming issue you are describing is similar to that of NDS where in the schema more than one attribute could be a naming attribute for a given object. For example: Some object class definitions specify multiple naming attributes. For example, the Locality object class is named by the L (Locality Name) and S (State or Province Name) attributes. Thus, an RDN for locality can include just an L (Locality Name) attribute, just an S (State or Province Name) attribute, or both attributes. For example, the name for the Provo, Utah locality could be * L=Provo * S=Utah * L=Provo + S=Utah The last example uses both attributes with a plus sign (+) to indicate where the second attribute's value begins. When the type specifiers (in this case, L and S) are used as shown, the name is referred to as a typed name. A typeless name has the following format: "Provo+Utah". In such a system you might have two locality objects called L=Greater London or S=Middlesex they are both localities, the same class but with different naming attributes Alex Alex Redston Technical Architect, Managing Director Switch Identity Governance Limited +44 1328 838821 +44 7973 320795 Alex Redston On 03/10/2013 08:46, Duc Thuan Nguy wrote: > Hi Bjorn, > > Thank you taking time to reply my question. Please let me explain a > little bit about our username system. In fact, normal username and > email are only two examples. Other possibilities include social > security number, or any user-defined types. There is no limitation > with regard to username types. > > Looking at the problem from the database point of view, we don't have > a single column to store username. Instead, a user has a list > of claims, e.g.: > > - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name > > - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress > > - gov:saml:attribute:SocialSecurityNumber > > - ... > > Any of them can be used as username. Our clients can set up a login > page for public users to use Name for username, and a login page for > corporate users to use email address as username. However, when > creating a new user, *one and only one* username type is required. > > So: > > Q: Are both email and a user name required by your system when > creating a user? > A: No, only one is required. Any of the username type is fine. > > I agree with you about "In all cases, allowing the user to log in with > either name should be done in the authentication logic, not in the > provisioning data when the user is created." The point here is that > when a user is created, I need to know what username type to map the > "username" specified in an SCIM request to. > > Am I right that your reply means using a custom attribute likes the > following is the best way I should do? > "urn:scim:schemas:extension:ourproductname:1.0":{ > > "userNameType":"email_as_username", > > } > > > > > Best Regards, > > Thuan. > > > ------------------------------------------------------------------------ > Date: Wed, 2 Oct 2013 17:34:51 +0000 > From: bjorn.aannestad@unboundid.com > To: nguydthuan@hotmail.com; scim@ietf.org > Subject: RE: [scim] Resend: How to use SCIM against a multi-username > system > > You could add a custom attribute for the user name type - those kinds > of extensions are supported by the specification. However, I'm do not > think mixing the two attribute types is the right solution. > > Are both email and a user name required by your system when creating a > user? > If so, I would recommend storing each in their respective predefined > attributes. > > If only an email address is required when creating a user, when that > is all you have, I would recommend storing the email in both attributes. > > If only a user name is required, and the email is optional, then of > course store the user name and leave the email blank. > > In all cases, allowing the user to log in with either name should be > done in the authentication logic, not in the provisioning data when > the user is created. > > -Bjorn Aannestad > > > > > ------------------------------------------------------------------------ > *From:* Duc Thuan Nguy (nguydthuan@hotmail.com) > > *Sent:* Tuesday, October 1, 2013 10:28 PM > *To:* scim@ietf.org > *Subject*: [scim] Resend: How to use SCIM against a multi-username system > > Hi SCIM groups, > > (I resend this email because it seems the first one got lost > somewhere. Perhaps it is because I sent it from another email account > which wasn't subscribed to the SCIM group. This email aims to correct > that mistake) > > Our company wants to implement SCIM 1.1 for our identity management > product. I think SCIM is great yet simple framework and is very eager > to implement it. However, I find one problem when I try to adopt SCIM > for our system: simply speaking, our system supports multiple > usernames. In other words, one user can have more than one usernames, > for example: > > -Username_as_username: bjensen. > > -Email_as_username: bjensen@example.com > > A user can use any of the "username" to login. > > As a consequent, when a create user request needs to specify not only > a username but also the type of that username. Unfortunately, I > couldn't find any predefined SCIM attribute which can be used for that > "type of username". > > I can think of a few options: > > A standard SCIM create user request: > > { > > "schemas":["urn:scim:schemas:core:1.0"], > > "userName":"bjensen", > > "externalId":"bjensen", > > "name":{ > > "formatted":"Ms. Barbara J Jensen III", > > "familyName":"Jensen", > > "givenName":"Barbara" > > } > > } > > Approach 1: extended SCIM create user request: > > { > > "schemas":["urn:scim:schemas:core:1.0"], > > "userName":"bjensen", > > "externalId":"bjensen", > > "name":{ > > "formatted":"Ms. Barbara J Jensen III", > > "familyName":"Jensen", > > "givenName":"Barbara" > > } > > "urn:scim:schemas:extension:ourproductname:1.0":{ > > "userNameType":"email_as_username", > > } > > } > > Approach 2: define separate endpoint for each username type: an > endpoint to create a user will look like: > https://example.com/email_as_username/v1/Users > > Approach 3: Ask the client developer to append a "userNameType=..." > parameter to the end of the request. > > Could you please tell me if any of the approaches above are SCIM > compliant and usable? What alternatives do I have? > > Thank you in advance, > > Nguy Duc Thuan. > > --------------070008070104030302090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Outside of the context of SCIM similar scenarios have come up, like in the naming of the "locality" object class in NetWare Directory Services.

The naming issue you are describing is similar to that of NDS where in the schema more than one attribute could be a naming attribute for a given object.

For example:

Some object class definitions specify multiple naming attributes. For example, the Locality object class is named by the L (Locality Name) and S (State or Province Name) attributes. Thus, an RDN for locality can include just an L (Locality Name) attribute, just an S (State or Province Name) attribute, or both attributes. For example, the name for the Provo, Utah locality could be

  • L=Provo

  • S=Utah

  • L=Provo + S=Utah

The last example uses both attributes with a plus sign (+) to indicate where the second attribute’s value begins. When the type specifiers (in this case, L and S) are used as shown, the name is referred to as a typed name. A typeless name has the following format: “Provo+Utah”.

In such a system you might have two locality objects called L=Greater London or S=Middlesex they are both localities, the same class but with different naming attributes

Alex 
Alex Redston

Technical Architect, Managing Director
Switch Identity Governance Limited

+44 1328 838821
+44 7973 320795
Alex Redston
On 03/10/2013 08:46, Duc Thuan Nguy wrote:
Hi Bjorn,

Thank you taking time to reply my question. Please let me explain a little bit about our username system. In fact, normal username and email are only two examples. Other possibilities include social security number, or any user-defined types. There is no limitation with regard to username types.

 

Looking at the problem from the database point of view, we don't have a single column to store username. Instead, a user has a list of claims, e.g.:

 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

 - gov:saml:attribute:SocialSecurityNumber

- ...

Any of them can be used as username. Our clients can set up a login page for public users to use Name for username, and a login page for corporate users to use email address as username. However, when creating a new user, *one and only one* username type is required.

 

So:

Q: Are both email and a user name required by your system when creating a user?  
A: No, only one is required. Any of the username type is fine.

I agree with you about "In all cases, allowing the user to log in with either name should be done in the authentication logic, not in the provisioning data when the user is created." The point here is that when a user is created, I need to know what username type to map the "username" specified in an SCIM request to.

Am I right that your reply means using a custom attribute likes the following is the best way I should do?
     "urn:scim:schemas:extension:ourproductname:1.0":{

                "userNameType":"email_as_username",

     }

 

 

Best Regards,

Thuan.

 
Date: Wed, 2 Oct 2013 17:34:51 +0000
From: bjorn.aannestad@unboundid.com
To: nguydthuan@hotmail.com; scim@ietf.org
Subject: RE: [scim] Resend: How to use SCIM against a multi-username system

You could add a custom attribute for the user name type - those kinds of extensions are supported by the specification.  However, I'm do not think mixing the two attribute types is the right solution.

Are both email and a user name required by your system when creating a user?  
If so, I would recommend storing each in their respective predefined attributes.   

If only an email address is required when creating a user, when that is all you have, I would recommend storing the email in both attributes.

If only a user name is required, and the email is optional, then of course store the user name and leave the email blank.

In all cases, allowing the user to log in with either name should be done in the authentication logic, not in the provisioning data when the user is created.

-Bjorn Aannestad




From: Duc Thuan Nguy (nguydthuan@hotmail.com)
Sent: Tuesday, October 1, 2013 10:28 PM
To: scim@ietf.org
Subject: [scim] Resend: How to use SCIM against a multi-username system
 

Hi SCIM groups,

(I resend this email because it seems the first one got lost somewhere. Perhaps it is because I sent it from another email account which wasn't subscribed to the SCIM group. This email aims to correct that mistake)

Our company wants to implement SCIM 1.1 for our identity management product. I think SCIM is great yet simple framework and is very eager to implement it. However, I find one problem when I try to adopt SCIM for our system: simply speaking, our system supports multiple usernames. In other words, one user can have more than one usernames, for example:

-          Username_as_username: bjensen.

-          Email_as_username: bjensen@example.com

A user can use any of the “username” to login.

 

As a consequent, when a create user request needs to specify not only a username but also the type of that username. Unfortunately, I couldn’t find any predefined SCIM attribute which can be used for that “type of username”.

 

I can think of a few options:

 

A standard SCIM create user request:

   {

     "schemas":["urn:scim:schemas:core:1.0"],

     "userName":"bjensen",

     "externalId":"bjensen",

     "name":{

       "formatted":"Ms. Barbara J Jensen III",

       "familyName":"Jensen",

       "givenName":"Barbara"

     }

   }

 

Approach 1: extended SCIM create user request:

   {

     "schemas":["urn:scim:schemas:core:1.0"],

     "userName":"bjensen",

     "externalId":"bjensen",

     "name":{

       "formatted":"Ms. Barbara J Jensen III",

       "familyName":"Jensen",

       "givenName":"Barbara"

     }

     "urn:scim:schemas:extension:ourproductname:1.0":{

                "userNameType":"email_as_username",

     }

   }

 

Approach 2: define separate endpoint for each username type: an endpoint to create a user will look like: https://example.com/email_as_username/v1/Users

 

Approach 3: Ask the client developer to append a “userNameType=…” parameter to the end of the request.

 

Could you please tell me if any of the approaches above are SCIM compliant and usable? What alternatives do I have?

 

Thank you in advance,

Nguy Duc Thuan.



--------------070008070104030302090803-- From ayyagarikiran@gmail.com Thu Oct 3 23:25:43 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50CC21F8D90 for ; Thu, 3 Oct 2013 23:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08LjWTSyWuAF for ; Thu, 3 Oct 2013 23:25:37 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7921F98EE for ; Thu, 3 Oct 2013 23:25:09 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p61so3894599wes.16 for ; Thu, 03 Oct 2013 23:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=j9NLsnsBv46Xu0cbmuUG98/M63IGtBz9QxkpF4ZoJrw=; b=HJLqn2Thk5u7MbYUMjwDD4O0wKvLlg/LYQUZHN+8S20XoggtwDeb7+ihjYSfktFYYU 5bNpV+1+uNGmNPIVVm4kR68pgL5Kqqexot/dFT1FSq+Apz+bjfqwgQgPBAJ3mJultArP lGNQdOHPEIHrtD5O7NqM60UzvPTuPMULCVZQaYcpZtFUwMaZcL5yDGsbpfdvJHSx1rJk hhHRT+qWrZqLNSQs8Z4cYifHGSHWaJN6h1P2zI6lj5Uqc2i2lTc1nrm3bKANlta3MLyy 3Ej59UbEmCfYCmWgdtOZa1g16BUHT69Z0WF6vTtL9cTfS4bGdrrMlc9wgWT98uJ0lwO3 l1Vw== MIME-Version: 1.0 X-Received: by 10.180.20.77 with SMTP id l13mr5862560wie.40.1380867908825; Thu, 03 Oct 2013 23:25:08 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Thu, 3 Oct 2013 23:25:08 -0700 (PDT) Date: Fri, 4 Oct 2013 11:55:08 +0530 X-Google-Sender-Auth: nXSkCoVgGSfidcpo1bLMSBlpo_Q Message-ID: From: Kiran Ayyagari To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f346f300df104e7e45d1a Subject: [scim] Auto discovery of supported resource schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 06:25:44 -0000 --bcaec53f346f300df104e7e45d1a Content-Type: text/plain; charset=ISO-8859-1 I would like a SCIM client to auto discover the types of resources and the extensions supported by a Service Provider and I believe the intention of introducing ResourceType[1] schema is to make this possible. But the schema of ResourceType in its current format can only represent the details of a single resource's schema as shown in the example[2]. IMO the ResourceType schema should hold a complex multi-valued attribute (like for e.x. 'supportedResources' ) which will contain an array of objects each containing the single-valued attributes of ResourceType schema this will look like { "schemas": ["urn:scim:schemas:core:2.0:ResourceType"], "supportedResources":[ { "name": "User", "endpoint": "/Users", "description": "Core User", "schema": "urn:scim:schemas:core:2.0:User", "schemaExtensions": [ { "schema": "urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser", "required": true } ] }, { "name": "Group", "endpoint": "/Groups", "description": "Core Group", "schema": "urn:scim:schemas:core:2.0:Group", } ], "meta": { "resourceType": "ResourceType", "created": "2010-01-23T04:56:22Z", "lastModified": "2011-05-13T04:42:34Z", "version": "W\/\"3694e05e9dff595\"" } } with this kind of structure a SCIM client can access schema for all resources dynamically [1] https://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-10 [2] https://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.6 -- Kiran Ayyagari http://keydap.com --bcaec53f346f300df104e7e45d1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would like = a SCIM client to auto discover the types of resources
and the extensions= supported by a Service Provider and I believe
the intention of in= troducing ResourceType[1] schema is to make this
possible.

But the schema of ResourceType in its current forma= t can only represent
the details of a single resource's = schema as shown in the example[2].

IMO the ResourceType schema= should hold a complex multi-valued
attribute (like for e.x. 'supportedResources' ) which will co= ntain an
array of objects each containing the single-valued attributes = of
ResourceType schema

this will look like

{
=A0=A0=A0=A0 "schemas": ["urn:scim:schemas:core:2.0= :ResourceType"],
=A0=A0=A0=A0 "supportedResources":[
= =A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0 "name": "User",=A0=A0=A0=A0=A0=A0 "endpoint": "/Users",
=A0=A0=A0=A0=A0=A0 "description": "Core User",
=A0= =A0=A0=A0=A0=A0 "schema": "urn:scim:schemas:core:2.0:User&qu= ot;,
=A0=A0=A0=A0=A0=A0 "schemaExtensions": [
=A0=A0=A0=A0= =A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "schema": "= urn:scim:schemas:extension:enterprise:2.0:EnterpriseUser",
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "required": true
=A0=A0=A0=A0= =A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0 ]
=A0=A0=A0=A0 },
=A0=A0=A0= =A0 {
=A0=A0=A0=A0=A0=A0 "name": "Group",
=A0=A0= =A0=A0=A0=A0 "endpoint": "/Groups",
=A0=A0=A0=A0=A0= =A0 "description": "Core Group",
=A0=A0=A0=A0=A0=A0 "schema": "urn:scim:schemas:core:2.0:Grou= p",
=A0=A0=A0=A0 }=A0=A0=A0=A0
=A0=A0=A0=A0 ],
=A0=A0=A0=A0 = "meta": {
=A0=A0=A0=A0=A0=A0 "resourceType": "R= esourceType",
=A0=A0=A0=A0=A0=A0 "created": "2010-01= -23T04:56:22Z",
=A0=A0=A0=A0=A0=A0 "lastModified": "2011-05-13T04:42:34Z&quo= t;,
=A0=A0=A0=A0=A0=A0 "version": "W\/\"3694e05e9dff= 595\""
=A0=A0=A0=A0 }=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0 }<= br>

with this kind of structure a SCIM client can access= schema for all resources dynamically
[2] https://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-1= 2.6

--
Kiran Ayyagari
http://keydap.com
--bcaec53f346f300df104e7e45d1a-- From swm16@psu.edu Fri Oct 4 14:50:17 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84E21F8EEA for ; Fri, 4 Oct 2013 14:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH3TaUyN7H3K for ; Fri, 4 Oct 2013 14:50:11 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id CD16621F99FD for ; Fri, 4 Oct 2013 14:50:09 -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 r94Lo7Lp3694696 for ; Fri, 4 Oct 2013 17:50:07 -0400 Date: Fri, 4 Oct 2013 17:50:07 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <400088099.5752086.1380923407726.JavaMail.zimbra@psu.edu> In-Reply-To: <561379808.5740064.1380922167228.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Linux)/8.0.4_GA_5737) Thread-Topic: Auto discovery of supported resource schemas Thread-Index: yyii923xUvcIvytdmygC3kkW62heDA== X-Virus-Scanned: by amavisd-new Subject: Re: [scim] Auto discovery of supported resource schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 04 Oct 2013 21:50:17 -0000 It's my understanding (based on section 3 of the API document) that the ResourceType resources will be available at the ../v1/ResourceTypes end-point, so if you want a collection of all the ResourceType objects, you could query that URL. If you only want to retrieve a single ResourceType, you'd use ../v1/ResourceTypes/User or ../v1/ResourceTypes/Group. I would then expect that both the ResourceType's schema and any extensions it declares would be available at ../v1/Schemas/.. (but perhaps I'm missing something). While we're discussing the ResourceType, I was wondering if there was a logical reason that it doesn't have an "id" attribute. Should one be added? Or should we use the name as the endpoint? For consistency, I'd prefer we add an id since every other object defined in the SCIM specifications has one. Steve From hazelton@doit.wisc.edu Fri Oct 4 14:59:11 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B75F21F9DFA for ; Fri, 4 Oct 2013 14:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRupOPE-P0Xr for ; Fri, 4 Oct 2013 14:59:05 -0700 (PDT) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAC621F9E85 for ; Fri, 4 Oct 2013 14:58:58 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_5XnSP/vxHHPo1sEDWOHIcQ)" Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MU500300ZFCKQ00@smtpauth2.wiscmail.wisc.edu> for scim@ietf.org; Fri, 04 Oct 2013 16:58:57 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.4.215114, SenderIP=0.0.0.0 Received: from wiscmail.wisc.edu (unknown [144.92.8.47]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPA id <0MU500N1SZQ82J10@smtpauth2.wiscmail.wisc.edu>; Fri, 04 Oct 2013 16:58:56 -0500 (CDT) Received: from [144.92.8.47] (Forwarded-For: 144.92.8.47) by wmweb7.doit.wisc.edu (mshttpd); Fri, 04 Oct 2013 16:58:56 -0500 Date: Fri, 04 Oct 2013 16:58:56 -0500 From: Keith Hazelton In-reply-to: <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> To: scim@ietf.org Message-id: <76b099a055b72.524ef3d0@wiscmail.wisc.edu> X-Mailer: Oracle Communications Messenger Express 7u4-25.01(7.0.4.25.0) 64bit (built Feb 29 2012) Content-language: en X-Accept-Language: en Priority: normal References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> Cc: grouper-dev Subject: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: hazelton@wisc.edu List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 21:59:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5XnSP/vxHHPo1sEDWOHIcQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Are there parties interested in developing or collaborating on a full and open source SCIM library. There are a number of open source projects that could benefit from such a thing. --Keith Hazelton --Boundary_(ID_5XnSP/vxHHPo1sEDWOHIcQ) Content-type: text/x-vcard; CHARSET=US-ASCII; name=hazelton.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=hazelton.vcf Content-description: Card for "Keith Hazelton" begin:vcard n:HAZELTON;KEITH;;; fn:KEITH D HAZELTON tel;work:608 262-0771 org:University of Wisconsin-Madison;DoIT adr:;;1210 W. Dayton St.;Madison;WI;53706;US email;work;internet:hazelton@wisc.edu title:Sr. IT Architect version:2.1 end:vcard --Boundary_(ID_5XnSP/vxHHPo1sEDWOHIcQ)-- From mmahadevan@okta.com Fri Oct 4 15:03:25 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF521F9BF3 for ; Fri, 4 Oct 2013 15:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k7s594ufsva for ; Fri, 4 Oct 2013 15:03:25 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 88D4321F8C3E for ; Fri, 4 Oct 2013 15:03:24 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so2073411eak.4 for ; Fri, 04 Oct 2013 15:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=gap; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FB2EoWv7gxq7MRGrfUlWxP5lmy+7BMnSFXuHIgqza2Y=; b=MFKpd2D+P9dw0tHeRwOuKhmzYSxbSur4XPBTcqVh56ps1ZfBILwHkf/cyXZOUrED7Q FyWaclbzCKmOAspAFyiBKdgMtIyumc88QGBiCzDxv3xH0c2LWy2LJEZW8D7aIWtLIY2J xXaT+v13EkEY+vzjaRYnKgpTitcFNzc4KGOUQ= 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=FB2EoWv7gxq7MRGrfUlWxP5lmy+7BMnSFXuHIgqza2Y=; b=TcV0yR7U3RUvgRpORmusuPqfDQ06o//tNPPANlmviTYW19P+F1SWN8EW9MgjdwtzXH 8a0puv/czHUUk/X7M82OqO2Yot1gzB2Ndq2O/r1++7H5wlt9nZTirp9OqiQcB0T9Cv4S oZ0e6PYjyD/yy+gthZc9P41GvhgUwqve0mPWSphomqWDbt0A5xPT2+Edr+4NYnEfdkkY IGgr64mr64Jo2YlnTwEude+o3MxwhlKVyJNhYLMAW4isS7JbOpJtSDySizNX2w4Lw1Aq CiYsJffp0nUDwIREM1nmIwTJRIF7ejo8YFkcxmAKuihOMz6goLppP72urkvAeHHxxAA5 8t7Q== X-Gm-Message-State: ALoCoQnRDZjVEnyURULM6JHlEgICouGR0XKCaupVUXNqpaf5ppJtiHX6/3kONM/xxKdIK3APxElt X-Received: by 10.15.61.137 with SMTP id i9mr7787359eex.50.1380924202311; Fri, 04 Oct 2013 15:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.35.137 with HTTP; Fri, 4 Oct 2013 15:03:02 -0700 (PDT) In-Reply-To: <76b099a055b72.524ef3d0@wiscmail.wisc.edu> References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> From: Madhu M Date: Fri, 4 Oct 2013 18:03:02 -0400 Message-ID: To: hazelton@wisc.edu Content-Type: multipart/alternative; boundary=089e0163548c8a966204e7f17893 Cc: scim@ietf.org, grouper-dev Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 22:03:25 -0000 --089e0163548c8a966204e7f17893 Content-Type: text/plain; charset=ISO-8859-1 There is an OpenSource library by UnboundID here: https://code.google.com/p/scimsdk/ Were you looking for something different? On Fri, Oct 4, 2013 at 5:58 PM, Keith Hazelton wrote: > Are there parties interested in developing or collaborating on a full and > open source SCIM library. There are a number of open source projects that > could benefit from such a thing. > > --Keith Hazelton > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Madhu Mahadevan Sr. Technical Consultant @ okta.com c: +1 (416) 451-4611 o: +1 (415) 578-5176 b: +1 (877) 273-4202,,1083942 t: @mmaha --- Sponsor me and help raise money for United Way: http://j.mp/support-united-way --- --089e0163548c8a966204e7f17893 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is an OpenSource library by UnboundID here= :=A0https://code.google.com/= p/scimsdk/ =A0

Were you looking for something different?


On Fri, Oct 4= , 2013 at 5:58 PM, Keith Hazelton <hazelton@doit.wisc.edu> wrote:
Are there parties interested in developing o= r collaborating on a full and open source SCIM library. There are a number = of open source projects that could benefit from such a thing.

=A0--Keith Hazelton

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




--
Madhu Mah= adevan
Sr. Technical Con= sultant @ okta.com=
c: +1 (416) 45= 1-4611
o: +1 (415) 578-5176
<= font color=3D"#999999">b: +1 (877) 273-4202,,1083942
t= : @mmaha<= /span>
---
Sponsor me and help raise money for United= Way: http://j= .mp/support-united-way
---
=
--089e0163548c8a966204e7f17893-- From davel@uchicago.edu Fri Oct 4 15:29:58 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E989221F9E37 for ; Fri, 4 Oct 2013 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrLvfeUWM1Wq for ; Fri, 4 Oct 2013 15:29:54 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id C087F21F9A59 for ; Fri, 4 Oct 2013 15:29:50 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n5so4591482oag.41 for ; Fri, 04 Oct 2013 15:29: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lT8ULhpsSC3Wl0pLmubtCRtHK15qxKJNQRZLbQkaVK4=; b=lz92KBOWQlHN+obDhKxlkESnCGZ1Go+r5UIlUTRrQ3y7NLceZOR/uSBMDMz5TK/SAz CCjVcN1tj1omuLMRn2eyWknVvTVRaqJO0Ypr+u4R3ezR1qi4UJ51wj57dQKqB66Rlg40 uhhLNRuxm/Sh4t7bP5q8uXoR8DWlFRkzU1d0KBCSNteuqORvpZ26PLZaFmp3A/ckE60Z ub6qweV4QhMzZWDRi+idBR7BY6TvlWtpKRSjKtqHKiW+8fk2JHYcH2rjFhG+wmGDGbCt a/OsR0o3yNkfsplWC5fJ3vHBqooPg1cXaqHrUf82C+tuEZ5Vfnre89aHTVld1w12we32 sQQw== X-Gm-Message-State: ALoCoQmjwGlb9djmfGU3BOa6j2oE2WrETEI2ncvdWqLRyhSCAslM0DipHDWFtiBu3nwHVzwDok6a MIME-Version: 1.0 X-Received: by 10.60.56.3 with SMTP id w3mr25386251oep.37.1380925787775; Fri, 04 Oct 2013 15:29:47 -0700 (PDT) Received: by 10.60.132.136 with HTTP; Fri, 4 Oct 2013 15:29:47 -0700 (PDT) In-Reply-To: References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> Date: Fri, 4 Oct 2013 16:29:47 -0600 Message-ID: From: David Langenberg To: Madhu M Content-Type: multipart/alternative; boundary=001a11c20a720ab23a04e7f1d701 Cc: scim@ietf.org, grouper-dev , Keith Hazelton Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 22:29:58 -0000 --001a11c20a720ab23a04e7f1d701 Content-Type: text/plain; charset=ISO-8859-1 There's a few issues with the unboundID software. First off the UnboundID stuff is triple licensed. The projects Keith is talking about, and the one I'm most involved with is Apache licensed. While the first license -- GPLv2 can use Apache stuff, the reverse is not true. Second, the LGPL, while it seems to solve the problem really does not and furthermore still would make issues for folks downstream when it comes to dealing with derived works. Third (Unbound ID License) requires downstream projects to enforce US Export Restrictions and that is just not something we're prepared to do. Dave On Fri, Oct 4, 2013 at 4:03 PM, Madhu M wrote: > There is an OpenSource library by UnboundID here: > https://code.google.com/p/scimsdk/ > > Were you looking for something different? > > > On Fri, Oct 4, 2013 at 5:58 PM, Keith Hazelton wrote: > >> Are there parties interested in developing or collaborating on a full and >> open source SCIM library. There are a number of open source projects that >> could benefit from such a thing. >> >> --Keith Hazelton >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > Madhu Mahadevan > Sr. Technical Consultant @ okta.com > c: +1 (416) 451-4611 > o: +1 (415) 578-5176 > b: +1 (877) 273-4202,,1083942 > t: @mmaha > --- > Sponsor me and help raise money for United Way: > http://j.mp/support-united-way > --- > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- David Langenberg Identity & Access Management The University of Chicago --001a11c20a720ab23a04e7f1d701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There's a few issues with the unboundID software. =A0F= irst off the UnboundID stuff is triple licensed. =A0The projects Keith is t= alking about, and the one I'm most involved with is Apache licensed. = =A0While the first license -- GPLv2 can use Apache stuff, the reverse is no= t true. =A0Second, the LGPL, while it seems to solve the problem really doe= s not and furthermore still would make issues for folks downstream when it = comes to dealing with derived works. =A0Third (Unbound ID License) requires= downstream projects to enforce US Export Restrictions and that is just not= something we're prepared to do.

Dave


On Fri, Oct 4, 2013 at 4:03 PM, Madhu M <mmahadevan@ok= ta.com> wrote:
There is an OpenS= ource library by UnboundID here:=A0https://code.google.com/p/scimsdk/ =A0

Were you looking for something different?


On Fri, Oct 4, 2013 at 5:58 PM, Keith Hazelton <<= a href=3D"mailto:hazelton@doit.wisc.edu" target=3D"_blank">hazelton@doit.wi= sc.edu> wrote:
Are there parties in= terested in developing or collaborating on a full and open source SCIM libr= ary. There are a number of open source projects that could benefit from suc= h a thing.

=A0--Keith Hazelton

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


<= br clear=3D"all">

--
Madhu Mahadevan
Sr. Technical Consultant @ okta.com
o: +1 (415) 578-5176<= /div>
b: +1 (877) 273-420= 2,,1083942
t= : @mmaha<= /span>
---
Sponsor me and help raise money for United= Way: http://j= .mp/support-united-way
---
=

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




--
David La= ngenberg
Identity & Access Management
The University of C= hicago
--001a11c20a720ab23a04e7f1d701-- From prabath@wso2.com Fri Oct 4 22:17:47 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0221F9B58 for ; Fri, 4 Oct 2013 22:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaZcwXdshHnX for ; Fri, 4 Oct 2013 22:17:46 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0564B21F9B90 for ; Fri, 4 Oct 2013 22:17:45 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id f15so2104493eak.8 for ; Fri, 04 Oct 2013 22:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9kw3irfdDr1Ip00YUDdubmzSnhx6tOKkeBeUdTl9jDY=; b=dLYBlC87QfXn8y/ZJYgYBsrxkt2AVg8cb1I1SxwUlFCVqZVGgvWaQKo3UWsHQYIA1N o38lLA2Tdr0tPyuaOX2RSFHKGhF8YFKgRPaj7seg15mH4kJ/bGo2eXRAr6fvIXDMEhhQ kM3wBjGIdYJN9Ucvfgq1Dl9/WoO6ymPeysG7M= 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:date :message-id:subject:from:to:cc:content-type; bh=9kw3irfdDr1Ip00YUDdubmzSnhx6tOKkeBeUdTl9jDY=; b=QEU/9ge998/z1KxRl4U0dAwIJxhc3CS4NEfCH2XtyQLWivdmWD5kqcuCMSZmHtZOsb C2rIGtfQsGreMqbGqe9aZyLLERndWeAnDoa/Po6ulpJ/qvidR6Mjn0O9t4hwOlt+AdTc F488ODT1Ov1naggR+3byLxNGNkLvwMKhRWaQiO2rigUT6vzU7rTGdGWhNCky6JMYc5tj mZAgNT8v9HFA1SooAVx41p5zXDN6r96ATb3xnrUi0vkAdkT8iaO2oskUyMb52nVCp8Ow dXtA5sZ2Tc0h6SZpgDXQTWoVn8Mu9LmFUDknmQ4TK37BsxvaNATZaABORLkjMBUgwPqB 8Utw== X-Gm-Message-State: ALoCoQkOll++UiiIvcv2xolwlG4Ag7WgoDV+LPQbao15PEfyqfdtduIb1ZniKrxD0WAcD1z5SWi8 MIME-Version: 1.0 X-Received: by 10.14.122.132 with SMTP id t4mr28037981eeh.20.1380950264868; Fri, 04 Oct 2013 22:17:44 -0700 (PDT) Received: by 10.223.171.202 with HTTP; Fri, 4 Oct 2013 22:17:44 -0700 (PDT) In-Reply-To: <76b099a055b72.524ef3d0@wiscmail.wisc.edu> References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> Date: Sat, 5 Oct 2013 10:47:44 +0530 Message-ID: From: Prabath Siriwardena To: hazelton@wisc.edu Content-Type: multipart/alternative; boundary=001a11c28efafdab6604e7f789b5 Cc: scim@ietf.org, grouper-dev Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 05:17:47 -0000 --001a11c28efafdab6604e7f789b5 Content-Type: text/plain; charset=ISO-8859-1 WSO2 Charon http://wso2.com/projects/charon is an open source library with Apache 2.0 license Thanks & regards, -Prabath On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton wrote: > Are there parties interested in developing or collaborating on a full and > open source SCIM library. There are a number of open source projects that > could benefit from such a thing. > > --Keith Hazelton > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --001a11c28efafdab6604e7f789b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
WSO2 Charon=A0= http://wso2.com/projects/charon is an open source library with Apache 2= .0 license

Thanks & regards,
-Prabath
<= div class=3D"gmail_extra">

On Sat, Oct 5, 2013 at 3:28 AM, Keith Ha= zelton <hazelton@doit.wisc.edu> wrote:
Are there parties interested in developing or collaborating on a full and o= pen source SCIM library. There are a number of open source projects that co= uld benefit from such a thing.

=A0--Keith Hazelton

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




--
Thanks &= amp; Regards,
Prabath

--001a11c28efafdab6604e7f789b5-- From swm16@psu.edu Sat Oct 5 09:42:12 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077B921F91AB for ; Sat, 5 Oct 2013 09:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylpMnaNwq8uV for ; Sat, 5 Oct 2013 09:42:05 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4710621F915C for ; Sat, 5 Oct 2013 09:42:04 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r95Gg1ff2826278 for ; Sat, 5 Oct 2013 12:42:01 -0400 Date: Sat, 5 Oct 2013 12:42:01 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <33739784.6044171.1380991321180.JavaMail.zimbra@psu.edu> In-Reply-To: <21935579.6043094.1380991054615.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Linux)/8.0.4_GA_5737) Thread-Topic: Interest in an open source SCIM library Thread-Index: rxfpEOK0qMwAhIHQphPmqC07Fjjaxg== X-Virus-Scanned: by amavisd-new Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 05 Oct 2013 16:42:12 -0000 There are several of us working on a OSS SCIM library and server as part of the Apache Directory Server project. We've tried several different approaches and will be (hopefully) consolidating them in the next few weeks. I'm not sure how much is checked in at this point (my work is currently in a fork), but you can see the beginnings of the project at: http://svn.apache.org/viewvc/directory/escimo/. Steve From ayyagarikiran@gmail.com Sat Oct 5 10:48:24 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25121F8C93 for ; Sat, 5 Oct 2013 10:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anEli4q9gI3T for ; Sat, 5 Oct 2013 10:48:23 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 32D8621F89A5 for ; Sat, 5 Oct 2013 10:48:19 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q58so113236wes.28 for ; Sat, 05 Oct 2013 10:48: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=4w9O3wA85+/fiIPmgB+z1FGKma7ktpp8eJ2BHVVvDbA=; b=Et7Rq+lJu/IRoiqOwpAKQVt4B8Lak7AC2zBL+QK4xQ8yJO4KcxzII0PQeJfbkz6hRu KXmbJNBL4QsLorj8pySW/C5beF7bpOTcF4uOsYF6EH58AYt5u3FwU/EZrrxHtloLCkIh vPwlyC8l6jHwOfNaR+OVseohc+Fln0kyH/UqGq+PV9vjoaFbSk94DjEvYnCieajQ5nxX CLUdYMlbZECXu1bFX8E/APyi64w3swa2xuDV0x7f2657kBe+tGWFrq6dWTdI2C2pnV9G t9iTVKYyvkkre7BGRrrIpLG2mmwAlbCOqnGkzhwTifBfqqAd1rBCe/VwB2NWzT4po6ZQ AxkQ== MIME-Version: 1.0 X-Received: by 10.180.20.77 with SMTP id l13mr12435531wie.40.1380995298261; Sat, 05 Oct 2013 10:48:18 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Sat, 5 Oct 2013 10:48:18 -0700 (PDT) In-Reply-To: <33739784.6044171.1380991321180.JavaMail.zimbra@psu.edu> References: <21935579.6043094.1380991054615.JavaMail.zimbra@psu.edu> <33739784.6044171.1380991321180.JavaMail.zimbra@psu.edu> Date: Sat, 5 Oct 2013 23:18:18 +0530 X-Google-Sender-Auth: nRJ4C1Dj7YLAPybcxy72o9GkMx0 Message-ID: From: Kiran Ayyagari To: Steve Moyer Content-Type: multipart/alternative; boundary=bcaec53f346f30819d04e802069d Cc: "scim@ietf.org" Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 17:48:24 -0000 --bcaec53f346f30819d04e802069d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 5, 2013 at 10:12 PM, Steve Moyer wrote: > There are several of us working on a OSS SCIM library and server as part > of the Apache Directory Server project. We've tried several different > approaches and will be (hopefully) consolidating them in the next few > weeks. I'm not sure how much is checked in at this point (my work is > currently in a fork), but you can see the beginnings of the project at: > http://svn.apache.org/viewvc/directory/escimo/. > > currently the work in on generating Java models from the JSON schema* and also a lot of other improvements are being made to the server code all this work is in a branch at the moment see http://svn.apache.org/repos/asf/directory/escimo/branches/json-schema-experiment This will be merged into the trunk in the coming week. thanks Steve for chiming in * so that developers can use eSCIMo client to generate java classes from the resources of any Service Provider Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > -- Kiran Ayyagari http://keydap.com --bcaec53f346f30819d04e802069d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 5, 2013 at 10:12 PM, Steve Moyer <= ;smoyer@psu.edu>= wrote:
There are several of us w= orking on a OSS SCIM library and server as part of the Apache Directory Ser= ver project. =A0We've tried several different approaches and will be (h= opefully) consolidating them in the next few weeks. =A0I'm not sure how= much is checked in at this point (my work is currently in a fork), but you= can see the beginnings of the project at: http://svn.apache.org/viewvc/d= irectory/escimo/.

currently the work in on generating Java models from the JSON schema* and= also a lot of other
improvements are being made to the serve= r code all this work is in a branch at the moment
see http://svn.apache.org/repos/asf/directory/= escimo/branches/json-schema-experiment
This will be merged into the = trunk in the coming week.

thanks Steve for chiming in

* so that developers can = use eSCIMo client to generate java classes from the resources of
=A0 an= y Service Provider

Steve
___________________________= ____________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim



--
Kiran Ayyag= ari
http://keydap.com
--bcaec53f346f30819d04e802069d-- From brockallen@gmail.com Sat Oct 5 18:06:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEF921F9DED for ; Sat, 5 Oct 2013 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJr1ClUdoUb1 for ; Sat, 5 Oct 2013 18:06:41 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76C21F9DCA for ; Sat, 5 Oct 2013 18:06:32 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so5601188pde.37 for ; Sat, 05 Oct 2013 18:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=utfbHmho6xMeoXw9ikD/tygb6uldePIGaR86NKe5ofU=; b=YAhLTwhUdcDtDxLjHPpFLIE7A6690NgCMvLX4N6t+v/gDmgRe9qCK8NyY5kmEGZ8vT 0J2DQpn/1KSEhqvwFa9PwMO2Gh8GhE/ZovjJP6QBq6Qx12fUWqRnf4pkeNWp+Cu1Un79 7NWjLQ4wGWaAGlh0q9IXz3SfcAS162VW0dYJL7eC/ljgr0kS5b8sORly2n76PCLfYaRC f6pe9Kzi/njjdUanWyRXnxvUIhNTwVQaNo/ZOEumEemhDa4j2LN17/Q4UBLpPctKhnX+ J468S75R7sqnI/KR9L+TWrNXw9W9F077IRNrxjTMkQHQdU9ledmnlaPBo1VbuiC7dZu4 dySw== X-Received: by 10.66.149.231 with SMTP id ud7mr24367294pab.8.1381021590819; Sat, 05 Oct 2013 18:06:30 -0700 (PDT) Received: from monk (ip72-221-69-212.ri.ri.cox.net. [72.221.69.212]) by mx.google.com with ESMTPSA id om2sm23783126pbc.30.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 05 Oct 2013 18:06:29 -0700 (PDT) From: "Brock Allen" To: "'Prabath Siriwardena'" , References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> In-Reply-To: Date: Sat, 5 Oct 2013 21:06:21 -0400 Message-ID: <031f01cec230$46dbc5f0$d49351d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0320_01CEC20E.BFCB3760" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGFm87ZqN/cX5BRaDA0oJxE9cHuLwG6lVscAcNlOSAAiKIX1QKf13a4AWUKMMOaOMtPIA== Content-Language: en-us Cc: scim@ietf.org, 'grouper-dev' Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 01:06:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0320_01CEC20E.BFCB3760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I started working on an open source .NET SCIM v1.1 implementation. Given the recent activity on v2 I stop working until v2 settled down. Along these lines, I've not been watching too closely the v2 progress - would you consider it sufficiently stable to go build something on, or do you (meaning the collective group here) still foresee significant changes? -Brock From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Prabath Siriwardena Sent: Saturday, October 5, 2013 1:18 AM To: hazelton@wisc.edu Cc: scim@ietf.org; grouper-dev Subject: Re: [scim] Interest in an open source SCIM library WSO2 Charon http://wso2.com/projects/charon is an open source library with Apache 2.0 license Thanks & regards, -Prabath On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton > wrote: Are there parties interested in developing or collaborating on a full and open source SCIM library. There are a number of open source projects that could benefit from such a thing. --Keith Hazelton _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ------=_NextPart_000_0320_01CEC20E.BFCB3760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I started = working on an open source .NET SCIM v1.1 implementation. Given the = recent activity on v2 I stop working until v2 settled = down.

 =

Along = these lines, I’ve not been watching too closely the v2 progress = – would you consider it sufficiently stable to go build something = on, or do you (meaning the collective group here) still foresee = significant changes?

 =

-Brock=

 =

 =

From: = scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of = Prabath Siriwardena
Sent: Saturday, October 5, 2013 1:18 = AM
To: hazelton@wisc.edu
Cc: scim@ietf.org; = grouper-dev
Subject: Re: [scim] Interest in an open source = SCIM library

 

WSO2 = Charon http://wso2.com/projects/charon<= /a> is an open source library with Apache 2.0 = license

-Prabath

 

On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton <hazelton@doit.wisc.edu> = wrote:

Are there parties interested in = developing or collaborating on a full and open source SCIM library. = There are a number of open source projects that could benefit from such = a thing.

 --Keith = Hazelton

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



 

-- =
Thanks & Regards,
Prabath

 

------=_NextPart_000_0320_01CEC20E.BFCB3760-- From ayyagarikiran@gmail.com Sat Oct 5 21:29:28 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348021F9DD5 for ; Sat, 5 Oct 2013 21:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+Bzs1gIXkWA for ; Sat, 5 Oct 2013 21:29:27 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B521F9CC7 for ; Sat, 5 Oct 2013 21:29:26 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so5145804wes.6 for ; Sat, 05 Oct 2013 21:29:25 -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=0xttbx5hwFzdH6cqoXKBApNLZkhtkYvwSRvv9or211U=; b=UFqNLCxd/ZGDrgB5UgKuEkKSPYBw4GTAbuRJABlbbH05Wy47w1UZv0w0h90GQ0YXMP 2tXMm0Oidn1erCECFI469O9xDhrJijWg9wticB6J3KSbVs46UHaggb9FAEk2gO3ROq19 3U7ghkSMy29TqC3+Edk/7QiOT9sIieuQXh1aHsRZkXVNJhBU6RvslTfZnmwtHmp2ZEP9 X/1vLtVTyCmdSi8g5/8Z7GS+vK1D4qS+1E66Y+4ZtKE+icHJipP040Qm6ElMTLOrCpRO OhyOOLNejlwysTeJsLUgg4ZViQKeviqDG539E1KVo+VRO8xTdPavAiL2lQsdNSzP9DPy iSeA== MIME-Version: 1.0 X-Received: by 10.180.94.233 with SMTP id df9mr13719940wib.63.1381033764972; Sat, 05 Oct 2013 21:29:24 -0700 (PDT) Sender: ayyagarikiran@gmail.com Received: by 10.216.245.200 with HTTP; Sat, 5 Oct 2013 21:29:24 -0700 (PDT) In-Reply-To: <400088099.5752086.1380923407726.JavaMail.zimbra@psu.edu> References: <561379808.5740064.1380922167228.JavaMail.zimbra@psu.edu> <400088099.5752086.1380923407726.JavaMail.zimbra@psu.edu> Date: Sun, 6 Oct 2013 09:59:24 +0530 X-Google-Sender-Auth: iMcJUi9uAYj3i9f4KOgCWMxhBaw Message-ID: From: Kiran Ayyagari To: Steve Moyer Content-Type: multipart/alternative; boundary=f46d04462e78fbf19c04e80afaed Cc: "scim@ietf.org" Subject: Re: [scim] Auto discovery of supported resource schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 04:29:28 -0000 --f46d04462e78fbf19c04e80afaed Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 5, 2013 at 3:20 AM, Steve Moyer wrote: > It's my understanding (based on section 3 of the API document) that the > ResourceType resources will be available at the ../v1/ResourceTypes > end-point, so if you want a collection of all the ResourceType objects, I didn't find any desciption about this endpoint in the section 3.2.1 the the table in section 3 mentions it > you could query that URL. If you only want to retrieve a single > ResourceType, you'd use ../v1/ResourceTypes/User or > ../v1/ResourceTypes/Group. I would then expect that both the > ResourceType's schema and any extensions it declares would be available at > ../v1/Schemas/.. (but perhaps I'm missing something). > > While we're discussing the ResourceType, I was wondering if there was a > logical reason that it doesn't have an "id" attribute. Should one be > added? Or should we use the name as the endpoint? For consistency, I'd > prefer we add an id since every other object defined in the SCIM > specifications has one. > yes, I agree it should be consistent with the other schema definitions > > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > -- Kiran Ayyagari http://keydap.com --f46d04462e78fbf19c04e80afaed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Oct 5, 2013 at 3:20 AM, Steve Moyer <<= a href=3D"mailto:smoyer@psu.edu" target=3D"_blank">smoyer@psu.edu> wrote:
It's my understanding (based on section = 3 of the API document) that the ResourceType resources will be available at= the ../v1/ResourceTypes end-point, so if you want a collection of all the = ResourceType objects,
I didn't find any desciption about this endpoint in the section 3.= 2.1 the the table in section 3 mentions it
you could query that URL. =A0If you only want to retrieve a single Resource= Type, you'd use ../v1/ResourceTypes/User or ../v1/ResourceTypes/Group. = =A0I would then expect that both the ResourceType's schema and any exte= nsions it declares would be available at ../v1/Schemas/.. =A0(but perhaps I= 'm missing something).

While we're discussing the ResourceType, I was wondering if there was a= logical reason that it doesn't have an "id" attribute. =A0Sh= ould one be added? =A0Or should we use the name as the endpoint? =A0For con= sistency, I'd prefer we add an id since every other object defined in t= he SCIM specifications has one.
yes, I agree it should be consistent with the other schem= a definitions

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



--
Kiran Ayyagari
http://keydap.com
--f46d04462e78fbf19c04e80afaed-- From leifj@mnt.se Sun Oct 6 06:17:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5EA11E80E8 for ; Sun, 6 Oct 2013 06:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ziD87qJF3Zb for ; Sun, 6 Oct 2013 06:17:16 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDB421F9F50 for ; Sun, 6 Oct 2013 06:17:14 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so4692143lbh.34 for ; Sun, 06 Oct 2013 06:17:13 -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=wNBab6Ho0bDja46UYvYJtFY8b6gvfCBqCnXIjzy7Zr0=; b=JfpC3JEcGvqU28e4bO+H2Cpkwi5mtCZjPE3d5qqFuxB9IFOlzqagZG17aonAhfihu0 3+v/SkPxSvvUrJsULIlnYIDg8MqoPJHahlY6P8DaQfsYCEvth6xN/l/8lZwJcSfyylMn l9d3DjsLJ64RzfnCYRTeUzgPYerwWYqP1SuFdIIyRhbXcUg3cvpQTXSHz86sxrIiGIMj lACGpUeVXkhZFy4V1b55WgAIOIiOMjdei7VN7675zd8HMt86C8T/+nNcdpSGsLhzxW+K gg0zvGCPNOC7rekOf+OjLhgGdVK1n0tzLPstZSBW7NSiv06UM22P7UXIuwkpSSGUvmWH MRHQ== X-Gm-Message-State: ALoCoQm2jxeF9TY6QnWPJwOiu/+OKKfK+6bWVnyX90C79BIYMzNPnArmAW2EUMRcRH+bqLAindw0 X-Received: by 10.152.203.233 with SMTP id kt9mr1664292lac.29.1381065433884; Sun, 06 Oct 2013 06:17:13 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id n15sm20466691laa.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 06:17:13 -0700 (PDT) Message-ID: <525162D7.1090008@mnt.se> Date: Sun, 06 Oct 2013 15:17:11 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] prelim agenda X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 13:17:22 -0000 The prelim agenda for the IETF is up. Unfortunately we got a Friday slot (again) so plan your travel accordingly! We will hopefully do a lot of work in the room to close out issues so bring your brains. Cheers Leif & Morteza From samuel@erdtman.se Sun Oct 6 16:54:49 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7190721E80E1 for ; Sun, 6 Oct 2013 16:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw3FnjTCzo6k for ; Sun, 6 Oct 2013 16:54:45 -0700 (PDT) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 249FF21E80F7 for ; Sun, 6 Oct 2013 16:54:43 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so2818632eaj.6 for ; Sun, 06 Oct 2013 16:54:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cs6TR1zND7vgV5CBTGHytjI2WGDpCMlb1cQaaeASHqo=; b=kCivwb7HZfQfydCpN4wGsUIfziw120J8tgsl45nkA2IEVDNOXUctSg5ULfuGT4gtW4 VUJMtiStyZNs6xsQzXWSDyHXVJwQsK7nAuIbFJX25LRdeXNdgcFcY4uUeHGYdygA/l6h 1eN5pUcsIBdZL4l3QSio0heHwAnqXO7uvw3XIbFQI9jPNFExVztBxXz5BX7ZP0ymdkvK VUj9xEXzH+Gq7Bnf5GK6XKnESqs+Ak0+1NNLFZDybORy8U6ZFcg3OZGWDUcGrnuV37tm Z/zjgulYaZClr+REhNBR364hNvILjPKNFVN5BhjLFX45w6FG4NaOV2ARhP4cVRWy4BjS +Gpg== X-Gm-Message-State: ALoCoQlRzQC8L91hH4kFRwSCioUw6LPFSdUgaqsigTcm3PohudkLGiCVIFCj3d0aQIEOpVieA/EM MIME-Version: 1.0 X-Received: by 10.15.64.1 with SMTP id n1mr44753725eex.15.1381103682708; Sun, 06 Oct 2013 16:54:42 -0700 (PDT) Received: by 10.14.147.5 with HTTP; Sun, 6 Oct 2013 16:54:42 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Oct 2013 18:54:42 -0500 Message-ID: From: Samuel Erdtman To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1132f09468220c04e81b420a Cc: "scim@ietf.org WG" Subject: Re: [scim] Proposed changes for attribute schema X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 23:54:49 -0000 --001a1132f09468220c04e81b420a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Good write up, some minor comments/thoughts: "The attribute MAY NOT be used in a GET request" does this men that you are not allowed to filter of write only attributes or does it mean that the service provider is not allowed to return the value. If it is the second I think this sentence is unclear. "should we allow PUT on a replace operation?" If we need immutable then I do not think PUT should change immutable values. What is the use-case for immutable? is group immutable or readonly? and what is the relation between immutable and readonly. "is used for attributes that must always be returned such as "id"" Could we add something about that it is not possible for the client to exclude these attributes. Do we really need all the keywords for "returned": I think that write only indicates that an attribute is not possible/allowed to be returned. Then I think that hawing both default and requested created abundant information. Could we not just have "default" and explain in text that attributes that are not "always" or "default" are only returned if requested. I still do not rely see that "index" is needed but if the group feels that it is I think that we need to specify here how do we specify several now it only says "The index MAY be one or more of the following" Is it a comma separated list or a json-array? Cheers //Samuel On Wed, Oct 2, 2013 at 7:07 PM, Phil Hunt wrote: > Tickets 10 (attribute sensitivity), 35 (mutability), and 47 (indexing) al= l > specify qualities that attributes may have in a SCIM service provider. T= he > following is proposed changes to section 3. > > Original text > > A resource is a collection of attributes identified by one or more > schemas. Minimally, an attribute consists of the attribute name and > at least one Simple or Complex value either of which may be Multi- > valued. SCIM schema defines the data type, plurality and other > distinguishing features of an attribute. Unless otherwise specified > all attributes are modifiable by Consumers. Immutable (read-only) > attributes SHALL be specified as 'READ-ONLY' within the attribute de= finition. Additionally, Service Providers MAY choose to make some > > or all Resource attributes immutable and SHOULD identify those > attributes via the associated Resource's schema endpoint > (Section 5.2 ). > > > > Proposed text: > > A resource is a collection of attributes identified by one or more schema= s. > > Minimally, an attribute consists of the attribute name and at least one > > Simple or Complex value either of which may be Multi-valued. > > > Attribute Meta-Data Schema > > > SCIM schema > > defines the data type, plurality and other distinguishing features of an > > attribute. > > > multiValued is a BOOLEAN that expresses whether the attribute MAY have mu= ltiple values. > > > mutability is a keyword that MAY be ONE of the following values: > > "readWrite" means that the attribute MAY be returned or updated. > > "readOnly" means that the attribute MAY be returned in response= to a SCIM request. A readOnly attribute MAY be used in a SCIM GET request.= A readOnly attribute MAY NOT be used in the request portion of a POST, PUT= , or PATCH operation. > > "writeOnly" means that an attribute MAY NOT be returned in any response= to a SCIM request. The attribute MAY be included in a POST, PUT, or PATCH = request. The attribute MAY NOT be used in a GET request. > > "immutable" means that an attribute MAY only be set once at record crea= tion during a POST or PUT operation. [[should we allow PUT on a replace ope= ration?]] > > > returned is a keyword that indicates when attribute values are returned o= n a query or SCIM response. The keyword MAY be ONE of the following values: > > "always" is used for attributes that must always be returned such a= s "id" > "never" is used for write-only attributes or other internal data. > "default" means the specified attribute is returned when the attribut= e parameter of a GET query is omitted. > "request" means that the attribute will only be returned if requested= . > > > index is a keyword that indicates what type of search filter MAY be used= with the attribute. Note that if the server does not support unindexed sea= rches, specifying a filter type not supported by the index returns a no mat= ch for the purposes of filter processing. The index MAY be one or more of t= he following: > > "substring" the specified filter string MUST be contained within the at= tribute value. > > "startsWith" the specified filter string MUST occur at the start of the = attribute value. > > "endsWith" the specified filter string MUST occur at the end of the at= tribute value. > > "exact" the specified filter string MUST exactly match the a= ttribute value. > > > In section 12.7, the schema representation for all attributes needs to be > updated to reflect the new attribute meta values. Note "readOnly" is > replaced by "mutability". > > Since individual servers can choose their own values for mutability, > index, multiValued, etc, the JSON structure would have to be non-normativ= e. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a1132f09468220c04e81b420a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
Good write up, some minor comments/thoughts:
<= div>
"The attribute MAY NOT be used=
 in a GET request"
=
does this men that you are not allowed=
 to filter of write only attributes or does it mean that the service provid=
er is not allowed to return the value. If it is the second I think this sen=
tence is unclear.

"should we allow PUT on=
 a replace operation?"
If we need =
immutable then I do not think PUT should change immutable values. What is t=
he use-case for immutable? is group immutable or readonly? and what is the =
relation between immutable and readonly.

"is used for attributes that must alw=
ays be returned such as "id""
Could we add something about th=
at it is not possible for the client to exclude these attributes.


Do we really need all the keywords for "=
returned":


I think that write only indicat=
es that an attribute is not possible/allowed to be returned. Then I think t=
hat hawing both default and requested created abundant information. Could w=
e not just have "default" and explain in text that attributes tha=
t are not "always" or "default" are only returned if re=
quested.



I still do not rely see that "index" is needed but if the group feels that it is I think that we need to=
 specify here how do we specify several now it only says "The index=
 MAY be one or more of the following" Is it a comma separated list or =
a json-array?



Cheers


//Samuel



On Wed, Oct 2, 2013 at 7:07 PM, Phil Hunt <phil.hunt@oracle.com>= wrote:
Tickets 10 (attribute sensitivity), 35 = (mutability), and 47 (indexing) all specify qualities that attributes may h= ave in a SCIM service provider. =A0The following is proposed changes to sec= tion 3.

Original text

   A resou=
rce is a collection of attributes identified by one or more
   schemas.  Minimally, an attribute consists of the attribute name and
   at least one Simple or Complex value either of which may be Multi-
   valued.  SCIM schema defines the data type, plurality and other
   distinguishing features of an attribute.  Unless otherwise specified
   all attributes are modifiable by Consumers.  Immutable (read-only)
   attributes SHALL be specified as 'READ-ONLY' within the attribut=
e
   definition.  Additionally, Service Provide=
rs MAY choose to make some
   or all Resource attributes immutable and SHOUL=
D identify those
   attributes via the associated Resource's schema endpoint
   (Section 5.2).

<= /div>

Proposed text:
A resource is a collection of attributes identif=
ied by one or more schemas.=A0
Minimally, an attribute consists=
 of the attribute name and at least one=A0
Simple or Complex value either of which may be Multi=
-valued.  <=
/pre>


<New Sect=
ion> Attribute Meta-Data Schema



SCIM schema=
=A0


defines the data type, plurality and other distinguishing features of =
an=A0


attribute. =A0

multiValue=
d	is a BOOLEAN that expresses w=
hether the attribute MAY have multiple values.


=

mutability	is =
a keyword that MAY be ONE of the following values: 


=
	"readWrite"  means t=
hat the attribute MAY be returned or updated.
        "readOnly"   means that the at=
tribute MAY be returned in response to a SCIM request. A readOnly attribute=
 MAY be used in a SCIM GET request. A readOnly attribute MAY NOT be used in=
 the request portion of a POST, PUT, or PATCH operation.


=
	"writeOnly"  means t=
hat an attribute MAY NOT be returned in any response to a SCIM request. The=
 attribute MAY be included in a POST, PUT, or PATCH request. The attribute =
MAY NOT be used in a GET request.


=
	"immutable"  means t=
hat an attribute MAY only be set once at record creation during a POST or P=
UT operation. [[should we allow PUT on a replace operation?]]


=

returned	is a =
keyword that indicates when attribute values are returned on a query or SCI=
M response. The keyword MAY be ONE of the following values: 


=
 	"always"     is use=
d for attributes that must always be returned such as "id"
 	"never"      is used f=
or write-only attributes or other internal data. 

	"default"    means t=
he specified attribute is returned when the attribute parameter of a GET qu=
ery is omitted. 
	"requ=
est"    means that the attribute will only be returned if requested.



index		is a keyword that indicates what type of search filter MAY =
be used with the attribute. Note that if the server does not support uninde=
xed searches, specifying a filter type not supported by the index returns a=
 no match for the purposes of filter processing. The index MAY be one or mo=
re of the following:


=
	"substring"  the spe=
cified filter string MUST be contained within the attribute value.

	"startsWith" the specified filter string MUST o=
ccur at the start of the attribute value.
	"endsWith"   the spe=
cified filter string MUST occur at the end of the attribute value.
        "exact"	     the specified filter string MU=
ST exactly match the attribute value.

In section 12.7, the schema representation for all attributes needs to= be updated to reflect the new attribute meta values. =A0Note "readOnl= y" is replaced by "mutability".

Sin= ce individual servers can choose their own values for mutability, index, mu= ltiValued, etc, the JSON structure would have to be non-normative.

Phil

@independentid
phil.hunt@oracle.com


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


--001a1132f09468220c04e81b420a-- From t.rossner@tarent.de Sun Oct 6 23:53:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D01121E8169 for ; Sun, 6 Oct 2013 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJBGACEhGc-f for ; Sun, 6 Oct 2013 23:52:56 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 11E3521E8142 for ; Sun, 6 Oct 2013 23:52:54 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so2420018bkg.36 for ; Sun, 06 Oct 2013 23:52: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=60wGIW4GjabN3k/Thn8nFVYkGHq3jygRlR4pX7C4flE=; b=V3gIG907s2FC43YL7UUG6YBSwyz9Wn/Rw1qxTCChyK8bAP15RYEtIZMTjfSmSzh8xj AZHWe1GTXANgiRrEVBnY8m0pWfszqichnFqfdVEbl2IHaV6gdwnteGjXSfIS3XlSxfJF 0tWeVerrsJ1L6zWGwNeL+S/9j+BYcut04NlB/9WPIJXeoT7vfcAipve2lmwbWdN+sMHu rZLtPduC1L76+kPxGE5QkPOdRRsnFPFY+oxa5UecPu4pRbVAPn5dtu3SOfS7Gy4odOG+ vIXFpYUhVBg6m9eycVGdiWebeGLNG3Npb9ewHPjvnKdk/bvidytkHJpDqFb+AhIatxpx JvuA== X-Gm-Message-State: ALoCoQmKdaTsm5PAV7fMMWMkyPMbxVabF7NqJMmUamYQttSj+0uHp+ydO24MmRD/movTcHZKrcS+ X-Received: by 10.204.121.201 with SMTP id i9mr25663056bkr.13.1381128773756; Sun, 06 Oct 2013 23:52:53 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id z6sm16047922bkn.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 23:52:52 -0700 (PDT) Message-ID: <52525A3D.2000009@tarent.de> Date: Mon, 07 Oct 2013 08:52:45 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> <031f01cec230$46dbc5f0$d49351d0$@gmail.com> In-Reply-To: <031f01cec230$46dbc5f0$d49351d0$@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------090207000604060006030702" Cc: prabath@wso2.com, brockallen@gmail.com, grouper-dev@internet2.edu, hazelton@wisc.edu Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 06:53:00 -0000 This is a multi-part message in MIME format. --------------090207000604060006030702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We are working on a MIT licenced Java (SE) implementation of SCIMv2 ( https://osiam.org/ or https://github.com/osiam ). Our SCIM Schema and Connector (SCIM Client) are already available on maven.org (http://search.maven.org/#search%7Cga%7C1%7Cosiam), the server isn't currently designed to be a separate library but a SCIMv2 service. But we are happy for any support to separate a SCIMv2 library from this service. Also, as already stated earlier on this list, we are looking for other SCIM v2 implementations (Client or Server) that have a public instance and could be used for automated interop-testing. Cheers Thorsten Am 06.10.2013 03:06, schrieb Brock Allen: > > I started working on an open source .NET SCIM v1.1 implementation. > Given the recent activity on v2 I stop working until v2 settled down. > > > > Along these lines, I've not been watching too closely the v2 progress > -- would you consider it sufficiently stable to go build something on, > or do you (meaning the collective group here) still foresee > significant changes? > > > > -Brock > > > > > > *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Prabath Siriwardena > *Sent:* Saturday, October 5, 2013 1:18 AM > *To:* hazelton@wisc.edu > *Cc:* scim@ietf.org; grouper-dev > *Subject:* Re: [scim] Interest in an open source SCIM library > > > > WSO2 Charon http://wso2.com/projects/charon is an open source library > with Apache 2.0 license > > > > Thanks & regards, > > -Prabath > > > > On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton > wrote: > > Are there parties interested in developing or collaborating on a > full and open source SCIM library. There are a number of open > source projects that could benefit from such a thing. > > --Keith Hazelton > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > > -- > Thanks & Regards, > Prabath > > > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------090207000604060006030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We are working on a MIT licenced Java (SE) implementation of SCIMv2 ( https://osiam.org/ or https://github.com/osiam ).

Our SCIM Schema and Connector (SCIM Client) are already available on maven.org (http://search.maven.org/#search%7Cga%7C1%7Cosiam), the server isn't currently designed to be a separate library but a SCIMv2 service. But we are happy for any support to separate a SCIMv2 library from this service.

Also, as already stated earlier on this list, we are looking for other SCIM v2 implementations (Client or Server) that have a public instance and could be used for automated interop-testing.

Cheers
Thorsten

Am 06.10.2013 03:06, schrieb Brock Allen:

I started working on an open source .NET SCIM v1.1 implementation. Given the recent activity on v2 I stop working until v2 settled down.

 

Along these lines, I’ve not been watching too closely the v2 progress – would you consider it sufficiently stable to go build something on, or do you (meaning the collective group here) still foresee significant changes?

 

-Brock

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Prabath Siriwardena
Sent: Saturday, October 5, 2013 1:18 AM
To: hazelton@wisc.edu
Cc: scim@ietf.org; grouper-dev
Subject: Re: [scim] Interest in an open source SCIM library

 

WSO2 Charon http://wso2.com/projects/charon is an open source library with Apache 2.0 license

 

Thanks & regards,

-Prabath

 

On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton <hazelton@doit.wisc.edu> wrote:

Are there parties interested in developing or collaborating on a full and open source SCIM library. There are a number of open source projects that could benefit from such a thing.

 --Keith Hazelton

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



 

--
Thanks & Regards,
Prabath

 



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
   
--------------090207000604060006030702-- From prvs=099275AFF4=erik.wahlstrom@nexusgroup.com Mon Oct 7 02:59:54 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF521E816A for ; Mon, 7 Oct 2013 02:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HgNfduPxY1K for ; Mon, 7 Oct 2013 02:59:50 -0700 (PDT) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7221E8174 for ; Mon, 7 Oct 2013 02:59:46 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Mon, 7 Oct 2013 11:59:41 +0200 Received: from MARVMAILDB.technxs.com ([fe80::c45a:7e27:c6bf:5de]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.03.0158.001; Mon, 7 Oct 2013 11:59:44 +0200 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: =?Windows-1252?Q?Thorsten_Ro=DFner?= Thread-Topic: [scim] Interest in an open source SCIM library Thread-Index: AQHOwUz4BcxF9uhLRkem3aefw3qLoJnlcFAAgAFMGICAAfMegIAANDsA Date: Mon, 7 Oct 2013 09:59:43 +0000 Message-ID: References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> <031f01cec230$46dbc5f0$d49351d0$@gmail.com> <52525A3D.2000009@tarent.de> In-Reply-To: <52525A3D.2000009@tarent.de> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.94] Content-Type: multipart/alternative; boundary="_000_BD000A959D8848E9B8ED821D35052CE5nexussafecom_" MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:59:54 -0000 --_000_BD000A959D8848E9B8ED821D35052CE5nexussafecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable And as the osiam implementation already done, I would be happy to add any i= mplementation to the list of implementations at www.simplecloud.info page. Just send me an mail. / Erik On Oct 7, 2013, at 8:52 AM, Thorsten Ro=DFner > wrote: We are working on a MIT licenced Java (SE) implementation of SCIMv2 ( https= ://osiam.org/ or https://github.com/osiam ). Our SCIM Schema and Connector (SCIM Client) are already available on maven.= org (http://search.maven.org/#search%7Cga%7C1%7Cosiam), t= he server isn't currently designed to be a separate library but a SCIMv2 se= rvice. But we are happy for any support to separate a SCIMv2 library from t= his service. Also, as already stated earlier on this list, we are looking for other SCIM= v2 implementations (Client or Server) that have a public instance and coul= d be used for automated interop-testing. Cheers Thorsten Am 06.10.2013 03:06, schrieb Brock Allen: I started working on an open source .NET SCIM v1.1 implementation. Given th= e recent activity on v2 I stop working until v2 settled down. Along these lines, I=92ve not been watching too closely the v2 progress =96= would you consider it sufficiently stable to go build something on, or do = you (meaning the collective group here) still foresee significant changes? -Brock From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Prabath Siriwardena Sent: Saturday, October 5, 2013 1:18 AM To: hazelton@wisc.edu Cc: scim@ietf.org; grouper-dev Subject: Re: [scim] Interest in an open source SCIM library WSO2 Charon http://wso2.com/projects/charon is an open source library with = Apache 2.0 license Thanks & regards, -Prabath On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton > wrote: Are there parties interested in developing or collaborating on a full and o= pen source SCIM library. There are a number of open source projects that co= uld benefit from such a thing. --Keith Hazelton _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BD000A959D8848E9B8ED821D35052CE5nexussafecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable And as the osiam implementation already done, I would be happy to add any i= mplementation to the list of implementations at www.simplecloud.info page.

Just send me an mail.

/ Erik

On Oct 7, 2013, at 8:52 AM, Thorsten Ro=DFner <t.rossner@tarent.de> wrote:

We are working on a MIT licenced Java (SE) i= mplementation of SCIMv2 ( https://osiam.org/ or https://github.com/osiam ).

Our SCIM Schema and Connector (SCIM Client) are already available on maven.org (http://search.maven.org/#search%7Cga%7C1%7Cosiam), the server isn't cu= rrently designed to be a separate library but a SCIMv2 service. But we are = happy for any support to separate a SCIMv2 library from this service.

Also, as already stated earlier on this list, we are looking for other SCIM= v2 implementations (Client or Server) that have a public instance and coul= d be used for automated interop-testing.

Cheers
Thorsten

Am 06.10.2013 03:06, schrieb Brock Allen:

I started working on an open source .NET SCIM v1.1 implemen= tation. Given the recent activity on v2 I stop working until v2 settled dow= n.

 

Along these lines, I=92ve not been watching too closely the= v2 progress =96 would you consider it sufficiently stable to go build some= thing on, or do you (meaning the collective group here) still foresee significant changes?

 

-Brock

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Prabath Siriwardena
Sent: Saturday, October 5, 2013 1:18 AM
To: hazelton@wisc.edu
Cc: scim@ietf.org; grouper-dev
Subject: Re: [scim] Interest in an open source SCIM library

 

WSO2 Charon http://wso2.com/projects/charon is an= open source library with Apache 2.0 license

 

Thanks & regards,

-Prabath

 

On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton <<= a moz-do-not-send=3D"true" href=3D"mailto:hazelton@doit.wisc.edu" target=3D= "_blank">hazelton@doit.wisc.edu> wrote:

Are there parties int= erested in developing or collaborating on a full and open source SCIM libra= ry. There are a number of open source projects that could benefit from such= a thing.

 --Keith Hazelton

_______________________________________________
scim mailing list
scim@ietf.org=
https://www.ietf.org/mailman/listinfo/scim<= /o:p>



 

--
Thanks & Regards,
Prabath

 



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

--_000_BD000A959D8848E9B8ED821D35052CE5nexussafecom_-- From kelly.grizzle@sailpoint.com Mon Oct 7 06:31:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82211E80DC for ; Mon, 7 Oct 2013 06:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuhEBzly5SDf for ; Mon, 7 Oct 2013 06:31:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 1569721F855F for ; Mon, 7 Oct 2013 06:31:21 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 7 Oct 2013 13:31:19 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) with mapi id 15.00.0775.005; Mon, 7 Oct 2013 13:31:19 +0000 From: Kelly Grizzle To: Brock Allen , 'Prabath Siriwardena' , "hazelton@wisc.edu" Thread-Topic: [scim] Interest in an open source SCIM library Thread-Index: AQHOwUz588i8pJEUIEyFOCOFTto6j5nlkdcAgAFMGICAAmH3EA== Date: Mon, 7 Oct 2013 13:31:18 +0000 Message-ID: <7ad2e837882a495babbc5bf410703aae@BN1PR04MB392.namprd04.prod.outlook.com> References: <76f0d8705103c.524f393c@wiscmail.wisc.edu> <76a0d48e51477.524f3978@wiscmail.wisc.edu> <7650ee735776c.524f39b4@wiscmail.wisc.edu> <76a0f0cd530fe.524f39f0@wiscmail.wisc.edu> <76b099a055b72.524ef3d0@wiscmail.wisc.edu> <031f01cec230$46dbc5f0$d49351d0$@gmail.com> In-Reply-To: <031f01cec230$46dbc5f0$d49351d0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 3C8D2F470056943C8D3094 x-originating-ip: [72.182.10.254] x-forefront-prvs: 09928BEC91 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(83322001)(19580405001)(19580395003)(79102001)(80976001)(16601075003)(54316002)(56776001)(19300405004)(19273905006)(53806001)(33646001)(46102001)(83072001)(51856001)(49866001)(47736001)(47976001)(50986001)(4396001)(85306002)(76482001)(77982001)(74316001)(59766001)(15202345003)(81342001)(74876001)(56816003)(81816001)(76796001)(81542001)(81686001)(76576001)(74706001)(76786001)(66066001)(16236675002)(15975445006)(63696002)(69226001)(19609705001)(15395725003)(77096001)(65816001)(80022001)(54356001)(74366001)(74662001)(47446002)(74502001)(31966008)(24736002)(563064011); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7ad2e837882a495babbc5bf410703aaeBN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , 'grouper-dev' Subject: Re: [scim] Interest in an open source SCIM library X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:31:27 -0000 --_000_7ad2e837882a495babbc5bf410703aaeBN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My guess is that most of the major changes have been completed. There will= still be quite a bit of churn on smaller issues, but IMO it is worth picki= ng up again. From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Bro= ck Allen Sent: Saturday, October 05, 2013 8:06 PM To: 'Prabath Siriwardena'; hazelton@wisc.edu Cc: scim@ietf.org; 'grouper-dev' Subject: Re: [scim] Interest in an open source SCIM library I started working on an open source .NET SCIM v1.1 implementation. Given th= e recent activity on v2 I stop working until v2 settled down. Along these lines, I've not been watching too closely the v2 progress - wou= ld you consider it sufficiently stable to go build something on, or do you = (meaning the collective group here) still foresee significant changes? -Brock From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Prabath Siriwardena Sent: Saturday, October 5, 2013 1:18 AM To: hazelton@wisc.edu Cc: scim@ietf.org; grouper-dev Subject: Re: [scim] Interest in an open source SCIM library WSO2 Charon http://wso2.com/projects/charon is an open source library with = Apache 2.0 license Thanks & regards, -Prabath On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton > wrote: Are there parties interested in developing or collaborating on a full and o= pen source SCIM library. There are a number of open source projects that co= uld benefit from such a thing. --Keith Hazelton _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --_000_7ad2e837882a495babbc5bf410703aaeBN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My guess is that most of = the major changes have been completed.  There will still be quite a bi= t of churn on smaller issues, but IMO it is worth picking up again.

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Brock Allen
Sent: Saturday, October 05, 2013 8:06 PM
To: 'Prabath Siriwardena'; hazelton@wisc.edu
Cc: scim@ietf.org; 'grouper-dev'
Subject: Re: [scim] Interest in an open source SCIM library

 

I started working on an open source .NET SCIM v1.1 implemen= tation. Given the recent activity on v2 I stop working until v2 settled dow= n.

 

Along these lines, I’ve not been watching too closely= the v2 progress – would you consider it sufficiently stable to go bu= ild something on, or do you (meaning the collective group here) still foresee significant changes?

 

-Brock

 

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Prabath Siriwardena
Sent: Saturday, October 5, 2013 1:18 AM
To: hazelton@wisc.edu
Cc: scim@ietf.org; grouper-dev<= br> Subject: Re: [scim] Interest in an open source SCIM library

 

WSO2 Charon http://wso2.com/projects/charon is an open source library with= Apache 2.0 license

 

Thanks & regards,

-Prabath

 

On Sat, Oct 5, 2013 at 3:28 AM, Keith Hazelton <<= a href=3D"mailto:hazelton@doit.wisc.edu" target=3D"_blank">hazelton@doit.wi= sc.edu> wrote:

Are there parties int= erested in developing or collaborating on a full and open source SCIM libra= ry. There are a number of open source projects that could benefit from such= a thing.

 --Keith Hazelton

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



 

--
Thanks & Regards,
Prabath

 

--_000_7ad2e837882a495babbc5bf410703aaeBN1PR04MB392namprd04pro_-- From nguydthuan@hotmail.com Tue Oct 8 00:11:56 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABF121E8155 for ; Tue, 8 Oct 2013 00:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Ih1HV00Fz5 for ; Tue, 8 Oct 2013 00:11:44 -0700 (PDT) Received: from bay0-omc4-s18.bay0.hotmail.com (bay0-omc4-s18.bay0.hotmail.com [65.54.190.220]) by ietfa.amsl.com (Postfix) with ESMTP id EB40D21E814C for ; Tue, 8 Oct 2013 00:11:43 -0700 (PDT) Received: from BAY168-W60 ([65.54.190.199]) by bay0-omc4-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Oct 2013 00:11:43 -0700 X-TMN: [9yXAdeTCqsipYffkUzAdmQU0rBUkgvWN] X-Originating-Email: [nguydthuan@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fecb2820-1e23-4054-bd28-8970d8e1409d_" From: Duc Thuan Nguy To: Alex Redston Date: Tue, 8 Oct 2013 14:11:43 +0700 Importance: Normal In-Reply-To: <524E5D2C.9060503@redston.com> References: , <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43> , <524E5D2C.9060503@redston.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2013 07:11:43.0576 (UTC) FILETIME=[A4920580:01CEC3F5] Cc: "scim@ietf.org" Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:11:56 -0000 --_fecb2820-1e23-4054-bd28-8970d8e1409d_ Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: base64 SGkgQWxleCwNCkFoIHllcywgd2UgYWxzbyBoYXZlIGFub3RoZXIgc2VydmljZSBpbXBsZW1lbnRh dGlvbiB3aGljaCB3ZSBzdXBwb3J0IGEgZmV3IHdheXMgb2Ygc3BlY2lmeWluZyAidXNlcm5hbWUg dHlwZSIuIE9uZSBvZiB0aGVtIGlzIHRvIHVzZSBhIHNpbWlsYXIgY29tYmluYXRpb24gc2ltaWxh ciB0byB5b3VyIHN1Z2dlc3Rpb24uIEkgdGhpbmsgaXQgZG9lc24ndCBjb25mbGljdCB3aXRoIGFu eSBTQ0lNIGNvbnN0cmFpbnQgYW5kIHRodXMgaXMgYSB2aWFibGUgc29sdXRpb24uDQoNCiANClRo YW5rcyBhIGJ1bmNoLApUaHVhbi4KDQogDQpEYXRlOiBGcmksIDQgT2N0IDIwMTMgMDc6MTY6MTIg KzAxMDANCkZyb206IGFsZXhyQHJlZHN0b24uY29tDQpUbzogbmd1eWR0aHVhbkBob3RtYWlsLmNv bQ0KQ0M6IHNjaW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSZTogW3NjaW1dIFJlc2VuZDogSG93 IHRvIHVzZSBTQ0lNIGFnYWluc3QgYSBtdWx0aS11c2VybmFtZSBzeXN0ZW0NCg0KCiAgCiAgICAK ICAKICAKICAgIE91dHNpZGUgb2YgdGhlIGNvbnRleHQgb2YgU0NJTSBzaW1pbGFyCiAgICAgIHNj ZW5hcmlvcyBoYXZlIGNvbWUgdXAsIGxpa2UgaW4gdGhlIG5hbWluZyBvZiB0aGUgImxvY2FsaXR5 IgogICAgICBvYmplY3QgY2xhc3MgaW4gTmV0V2FyZSBEaXJlY3RvcnkgU2VydmljZXMuDQoKICAg ICAgDQoKICAgICAgTXVsdGlwbGUgbmFtaW5nIGF0dHJpYnV0ZXMgaW4gY29tYmluYXRpb24NCgog ICAgICANCgogICAgICBUaGUgbmFtaW5nIGlzc3VlIHlvdSBhcmUgZGVzY3JpYmluZyBpcyBzaW1p bGFyIHRvIHRoYXQgb2YgTkRTCiAgICAgIHdoZXJlIGluIHRoZSBzY2hlbWEgbW9yZSB0aGFuIG9u ZSBhdHRyaWJ1dGUgY291bGQgYmUgYSBuYW1pbmcKICAgICAgYXR0cmlidXRlIGZvciBhIGdpdmVu IG9iamVjdC4NCgogICAgICANCgogICAgICBGb3IgZXhhbXBsZToNCgogICAgICANCgogICAgICBT b21lIG9iamVjdCBjbGFzcyBkZWZpbml0aW9ucyBzcGVjaWZ5IG11bHRpcGxlCiAgICAgICAgbmFt aW5nIGF0dHJpYnV0ZXMuIEZvciBleGFtcGxlLCB0aGUgTG9jYWxpdHkgb2JqZWN0IGNsYXNzIGlz CiAgICAgICAgbmFtZWQgYnkgdGhlIEwgKExvY2FsaXR5IE5hbWUpIGFuZCBTIChTdGF0ZSBvciBQ cm92aW5jZSBOYW1lKQogICAgICAgIGF0dHJpYnV0ZXMuIFRodXMsIGFuIFJETiBmb3IgbG9jYWxp dHkgY2FuIGluY2x1ZGUganVzdCBhbiBMCiAgICAgICAgKExvY2FsaXR5IE5hbWUpIGF0dHJpYnV0 ZSwganVzdCBhbiBTIChTdGF0ZSBvciBQcm92aW5jZSBOYW1lKQogICAgICAgIGF0dHJpYnV0ZSwg b3IgYm90aCBhdHRyaWJ1dGVzLiBGb3IgZXhhbXBsZSwgdGhlIG5hbWUgZm9yIHRoZQogICAgICAg IFByb3ZvLCBVdGFoIGxvY2FsaXR5IGNvdWxkIGJlCiAgICAgIAogICAgICAgIAogICAgICAgICAg CiAgICAgICAgICAgIEw9UHJvdm8KICAgICAgICAgIAogICAgICAgICAgCiAgICAgICAgICAgIFM9 VXRhaAogICAgICAgICAgCiAgICAgICAgICAKICAgICAgICAgICAgTD1Qcm92byArIFM9VXRhaAog ICAgICAgICAgCiAgICAgICAgCiAgICAgIAogICAgICBUaGUgbGFzdCBleGFtcGxlIHVzZXMgYm90 aCBhdHRyaWJ1dGVzIHdpdGggYSBwbHVzCiAgICAgICAgc2lnbiAoKykgdG8gaW5kaWNhdGUgd2hl cmUgdGhlIHNlY29uZCBhdHRyaWJ1dGWScyB2YWx1ZSBiZWdpbnMuCiAgICAgICAgV2hlbiB0aGUg dHlwZSBzcGVjaWZpZXJzIChpbiB0aGlzIGNhc2UsIEwgYW5kIFMpIGFyZSB1c2VkIGFzCiAgICAg ICAgc2hvd24sIHRoZSBuYW1lIGlzIHJlZmVycmVkIHRvIGFzIGEgdHlwZWQgbmFtZS4gQSB0eXBl bGVzcyBuYW1lCiAgICAgICAgaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OiCTUHJvdm8rVXRhaJQu DQoKICAgICAgCiAgICAgIEFsZXgNCgogICAgICAKICAgICAgDQoKICAgICAgQWxleCBSZWRzdG9u CgpUZWNobmljYWwgQXJjaGl0ZWN0LCBNYW5hZ2luZyBEaXJlY3RvcgpSZWRzdG9uIFN5c3RlbXMg TGltaXRlZAoKKzQ0IDEzMjggODM4ODIxCis0NCA3OTczIDMyMDc5NQoKUmVnaXN0ZXJlZCBPZmZp Y2U6CjYgTEFOR0RBTEUgQ09VUlQKV0lUTkVZCk9YRk9SRFNISVJFClVOSVRFRCBLSU5HRE9NCk9Y MjggNkZHCgpDb21wYW55IE5vLiAwMjkxNjY4MgogICAgICBPbiAwMy8xMC8yMDEzIDA4OjQ2LCBE dWMgVGh1YW4gTmd1eSB3cm90ZToNCgogICAgCiAgICAKICAgICAgCiAgICAgIEhpIEJqb3JuLAog ICAgICAgIFRoYW5rIHlvdSB0YWtpbmcgdGltZSB0byByZXBseSBteSBxdWVzdGlvbi4gUGxlYXNl IGxldCBtZQogICAgICAgICAgZXhwbGFpbiBhIGxpdHRsZSBiaXQgYWJvdXQgb3VyIHVzZXJuYW1l IHN5c3RlbS4gSW4gZmFjdCwKICAgICAgICAgIG5vcm1hbCB1c2VybmFtZSBhbmQgZW1haWwgYXJl IG9ubHkgdHdvIGV4YW1wbGVzLiBPdGhlcgogICAgICAgICAgcG9zc2liaWxpdGllcyBpbmNsdWRl IHNvY2lhbCBzZWN1cml0eSBudW1iZXIsIG9yIGFueQogICAgICAgICAgdXNlci1kZWZpbmVkIHR5 cGVzLiBUaGVyZSBpcyBubyBsaW1pdGF0aW9uIHdpdGggcmVnYXJkIHRvCiAgICAgICAgICB1c2Vy bmFtZSB0eXBlcy4NCgogICAgICAgICANCgogICAgICAgIExvb2tpbmcgYXQgdGhlIHByb2JsZW0g ZnJvbSB0aGUgZGF0YWJhc2UgcG9pbnQgb2Ygdmlldywgd2UKICAgICAgICAgIGRvbid0IGhhdmUg YSBzaW5nbGUgY29sdW1uIHRvIHN0b3JlIHVzZXJuYW1lLiBJbnN0ZWFkLCBhIHVzZXIKICAgICAg ICAgIGhhcyBhIGxpc3Qgb2YgY2xhaW1zLCBlLmcuOg0KCiAgICAgICAgIC0gaHR0cDovL3NjaGVt YXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvbmFtZQ0KCiAgICAgICAg IC0gaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMv ZW1haWxhZGRyZXNzDQoKICAgICAgICAgLSBnb3Y6c2FtbDphdHRyaWJ1dGU6U29jaWFsU2VjdXJp dHlOdW1iZXINCgogICAgICAgIC0gLi4uDQoKICAgICAgICBBbnkgb2YgdGhlbSBjYW4gYmUgdXNl ZCBhcyB1c2VybmFtZS4gT3VyIGNsaWVudHMgY2FuIHNldCB1cCBhCiAgICAgICAgICBsb2dpbiBw YWdlIGZvciBwdWJsaWMgdXNlcnMgdG8gdXNlIE5hbWUgZm9yIHVzZXJuYW1lLCBhbmQgYQogICAg ICAgICAgbG9naW4gcGFnZSBmb3IgY29ycG9yYXRlIHVzZXJzIHRvIHVzZSBlbWFpbCBhZGRyZXNz IGFzCiAgICAgICAgICB1c2VybmFtZS4gSG93ZXZlciwgd2hlbiBjcmVhdGluZyBhIG5ldyB1c2Vy LCAqb25lIGFuZCBvbmx5CiAgICAgICAgICBvbmUqIHVzZXJuYW1lIHR5cGUgaXMgcmVxdWlyZWQu DQoKICAgICAgICAgDQoKICAgICAgICBTbzoNCgogICAgICAgIFE6IEFyZSBib3RoIGVtYWlsIGFu ZCBhIHVzZXIgbmFtZSByZXF1aXJlZCBieSB5b3VyIHN5c3RlbQogICAgICAgICAgd2hlbiBjcmVh dGluZyBhIHVzZXI/ICAgDQoKICAgICAgICAgIEE6IE5vLCBvbmx5IG9uZSBpcyByZXF1aXJlZC4g QW55IG9mIHRoZSB1c2VybmFtZSB0eXBlIGlzIGZpbmUuDQoKICAgICAgICAgIA0KCiAgICAgICAg ICBJIGFncmVlIHdpdGggeW91IGFib3V0ICJJbiBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2Vy IHRvIGxvZwogICAgICAgICAgaW4gd2l0aCBlaXRoZXIgbmFtZSBzaG91bGQgYmUgZG9uZSBpbiB0 aGUgYXV0aGVudGljYXRpb24KICAgICAgICAgIGxvZ2ljLCBub3QgaW4gdGhlIHByb3Zpc2lvbmlu ZyBkYXRhIHdoZW4gdGhlIHVzZXIgaXMgY3JlYXRlZC4iCiAgICAgICAgICBUaGUgcG9pbnQgaGVy ZSBpcyB0aGF0IHdoZW4gYSB1c2VyIGlzIGNyZWF0ZWQsIEkgbmVlZCB0byBrbm93CiAgICAgICAg ICB3aGF0IHVzZXJuYW1lIHR5cGUgdG8gbWFwIHRoZSAidXNlcm5hbWUiIHNwZWNpZmllZCBpbiBh biBTQ0lNCiAgICAgICAgICByZXF1ZXN0IHRvLg0KCiAgICAgICAgICANCgogICAgICAgICAgQW0g SSByaWdodCB0aGF0IHlvdXIgcmVwbHkgbWVhbnMgdXNpbmcgYSBjdXN0b20gYXR0cmlidXRlCiAg ICAgICAgICBsaWtlcyB0aGUgZm9sbG93aW5nIGlzIHRoZSBiZXN0IHdheSBJIHNob3VsZCBkbz8N CgogICAgICAgICAgICAgIAogICAgICAgICAgICAidXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246 b3VycHJvZHVjdG5hbWU6MS4wIjp7IA0KCiAgICAgICAgDQoKICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgInVzZXJOYW1lVHlwZSI6ImVtYWlsX2FzX3VzZXJuYW1lIiwgCiAgICAg ICAgICAgICB9IAogICAgICAgICANCgogICAgICAgIA0KCiAgICAgICAgIA0KCiAgICAgICAgQmVz dCBSZWdhcmRzLAogICAgICAgIFRodWFuLgogICAgICAgICANCgogICAgICAgIAogICAgICAgICAg RGF0ZTogV2VkLCAyIE9jdCAyMDEzIDE3OjM0OjUxICswMDAwDQoKICAgICAgICAgIEZyb206IGJq b3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tDQoKICAgICAgICAgIFRvOiBuZ3V5ZHRodWFuQGhv dG1haWwuY29tOyBzY2ltQGlldGYub3JnDQoKICAgICAgICAgIFN1YmplY3Q6IFJFOiBbc2NpbV0g UmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhCiAgICAgICAgICBtdWx0aS11c2VybmFt ZSBzeXN0ZW0NCgogICAgICAgICAgDQoKICAgICAgICAgIFlvdSBjb3VsZCBhZGQgYSBjdXN0b20g YXR0cmlidXRlIGZvciB0aGUgdXNlciBuYW1lIHR5cGUgLQogICAgICAgICAgdGhvc2Uga2luZHMg b2YgZXh0ZW5zaW9ucyBhcmUgc3VwcG9ydGVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uLgogICAgICAg ICAgIEhvd2V2ZXIsIEknbSBkbyBub3QgdGhpbmsgbWl4aW5nIHRoZSB0d28gYXR0cmlidXRlIHR5 cGVzIGlzCiAgICAgICAgICB0aGUgcmlnaHQgc29sdXRpb24uIA0KCiAgICAgICAgICANCgogICAg ICAgICAgQXJlIGJvdGggZW1haWwgYW5kIGEgdXNlciBuYW1lIHJlcXVpcmVkIGJ5IHlvdXIgc3lz dGVtIHdoZW4KICAgICAgICAgIGNyZWF0aW5nIGEgdXNlcj8gICANCgogICAgICAgICAgSWYgc28s IEkgd291bGQgcmVjb21tZW5kIHN0b3JpbmcgZWFjaCBpbiB0aGVpciByZXNwZWN0aXZlCiAgICAg ICAgICBwcmVkZWZpbmVkIGF0dHJpYnV0ZXMuICAgIA0KCiAgICAgICAgICANCgogICAgICAgICAg SWYgb25seSBhbiBlbWFpbCBhZGRyZXNzIGlzIHJlcXVpcmVkIHdoZW4gY3JlYXRpbmcgYSB1c2Vy LAogICAgICAgICAgd2hlbiB0aGF0IGlzIGFsbCB5b3UgaGF2ZSwgSSB3b3VsZCByZWNvbW1lbmQg c3RvcmluZyB0aGUgZW1haWwKICAgICAgICAgIGluIGJvdGggYXR0cmlidXRlcy4gDQoKICAgICAg ICAgIA0KCiAgICAgICAgICBJZiBvbmx5IGEgdXNlciBuYW1lIGlzIHJlcXVpcmVkLCBhbmQgdGhl IGVtYWlsIGlzIG9wdGlvbmFsLAogICAgICAgICAgdGhlbiBvZiBjb3Vyc2Ugc3RvcmUgdGhlIHVz ZXIgbmFtZSBhbmQgbGVhdmUgdGhlIGVtYWlsIGJsYW5rLgogICAgICAgICAgDQoKICAgICAgICAg IA0KCiAgICAgICAgICBJbiBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3 aXRoIGVpdGhlciBuYW1lCiAgICAgICAgICBzaG91bGQgYmUgZG9uZSBpbiB0aGUgYXV0aGVudGlj YXRpb24gbG9naWMsIG5vdCBpbiB0aGUKICAgICAgICAgIHByb3Zpc2lvbmluZyBkYXRhIHdoZW4g dGhlIHVzZXIgaXMgY3JlYXRlZC4gDQoKICAgICAgICAgIA0KCiAgICAgICAgICAtQmpvcm4gQWFu bmVzdGFkIA0KCiAgICAgICAgICANCgogICAgICAgICAgDQoKICAgICAgICAgIA0KCiAgICAgICAg ICANCgogICAgICAgICAgIEZyb206IER1YwogICAgICAgICAgICBUaHVhbiBOZ3V5IChuZ3V5ZHRo dWFuQGhvdG1haWwuY29tKSANCgogICAgICAgICAgU2VudDogVHVlc2RheSwgT2N0b2JlciAxLCAy MDEzIDEwOjI4IFBNIA0KCiAgICAgICAgICBUbzogc2NpbUBpZXRmLm9yZyANCgogICAgICAgICAg U3ViamVjdDogW3NjaW1dIFJlc2VuZDogSG93IHRvIHVzZSBTQ0lNIGFnYWluc3QgYQogICAgICAg ICAgbXVsdGktdXNlcm5hbWUgc3lzdGVtCiAgICAgICAgICAgICAKICAgICAgICAgIAogICAgICAg ICAgCiAgICAgICAgICAgICBIaSBTQ0lNIGdyb3VwcywgCiAgICAgICAgICAgICAoSSByZXNlbmQg dGhpcyBlbWFpbCBiZWNhdXNlIGl0CiAgICAgICAgICAgICAgc2VlbXMgdGhlIGZpcnN0IG9uZSBn b3QgbG9zdCBzb21ld2hlcmUuIFBlcmhhcHMgaXQgaXMKICAgICAgICAgICAgICBiZWNhdXNlIEkg c2VudCBpdCBmcm9tIGFub3RoZXIgZW1haWwgYWNjb3VudCB3aGljaCB3YXNuJ3QKICAgICAgICAg ICAgICBzdWJzY3JpYmVkIHRvIHRoZSBTQ0lNIGdyb3VwLiBUaGlzIGVtYWlsIGFpbXMgdG8gY29y cmVjdAogICAgICAgICAgICAgIHRoYXQgbWlzdGFrZSkKICAgICAgICAgICAgIAogICAgICAgICAg ICAgT3VyIGNvbXBhbnkgd2FudHMgdG8gaW1wbGVtZW50IFNDSU0KICAgICAgICAgICAgICAxLjEg Zm9yIG91ciBpZGVudGl0eSBtYW5hZ2VtZW50IHByb2R1Y3QuIEkgdGhpbmsgU0NJTSBpcwogICAg ICAgICAgICAgIGdyZWF0IHlldCBzaW1wbGUgZnJhbWV3b3JrIGFuZCBpcyB2ZXJ5IGVhZ2VyIHRv IGltcGxlbWVudAogICAgICAgICAgICAgIGl0LiBIb3dldmVyLCBJIGZpbmQgb25lIHByb2JsZW0g d2hlbiBJIHRyeSB0byBhZG9wdCBTQ0lNCiAgICAgICAgICAgICAgZm9yIG91ciBzeXN0ZW06IHNp bXBseSBzcGVha2luZywgb3VyIHN5c3RlbSBzdXBwb3J0cwogICAgICAgICAgICAgIG11bHRpcGxl IHVzZXJuYW1lcy4gSW4gb3RoZXIgd29yZHMsIG9uZSB1c2VyIGNhbiBoYXZlIG1vcmUKICAgICAg ICAgICAgICB0aGFuIG9uZSB1c2VybmFtZXMsIGZvciBleGFtcGxlOiAKICAgICAgICAgICAgCiAg ICAgICAgICAgICAgLSAgICAgICAgICAKICAgICAgICAgICAgICBVc2VybmFtZV9hc191c2VybmFt ZTogYmplbnNlbi4gCiAgICAgICAgICAgIAogICAgICAgICAgICAgIC0gICAgICAgICAgCiAgICAg ICAgICAgICAgRW1haWxfYXNfdXNlcm5hbWU6IGJqZW5zZW5AZXhhbXBsZS5jb20KICAgICAgICAg ICAgCiAgICAgICAgICAgICBBIHVzZXIgY2FuIHVzZSBhbnkgb2YgdGhlCiAgICAgICAgICAgICAg k3VzZXJuYW1llCB0byBsb2dpbi4gCiAgICAgICAgICAgICAgIAogICAgICAgICAgICAgQXMgYSBj b25zZXF1ZW50LCB3aGVuIGEgY3JlYXRlIHVzZXIKICAgICAgICAgICAgICByZXF1ZXN0IG5lZWRz IHRvIHNwZWNpZnkgbm90IG9ubHkgYSB1c2VybmFtZSBidXQgYWxzbyB0aGUKICAgICAgICAgICAg ICB0eXBlIG9mIHRoYXQgdXNlcm5hbWUuIFVuZm9ydHVuYXRlbHksIEkgY291bGRuknQgZmluZCBh bnkKICAgICAgICAgICAgICBwcmVkZWZpbmVkIFNDSU0gYXR0cmlidXRlIHdoaWNoIGNhbiBiZSB1 c2VkIGZvciB0aGF0IJN0eXBlCiAgICAgICAgICAgICAgb2YgdXNlcm5hbWWULiAKICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICBJIGNhbiB0aGluayBvZiBhIGZldyBvcHRpb25zOiAKICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICBBIHN0YW5kYXJkIFNDSU0gY3JlYXRlIHVzZXIKICAgICAg ICAgICAgICByZXF1ZXN0OiAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgeyAKICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgInNjaGVtYXMiOlsidXJu OnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLCAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAidXNlck5hbWUiOiJiamVuc2VuIiwgCiAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ImV4dGVybmFsSWQiOiJiamVuc2VuIiwKICAgICAgICAgICAgICAKICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAibmFtZSI6eyAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICJmb3JtYXR0ZWQiOiJNcy4KICAgICAgICAgICAgICAgIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwg CiAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgImZhbWls eU5hbWUiOiJKZW5zZW4iLCAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICJnaXZl bk5hbWUiOiJCYXJiYXJhIgogICAgICAgICAgICAgIAogICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgIH0gCiAgICAgICAgICAgIAogICAgICAgICAgICAgICAgIH0gCiAgICAgICAgICAgICAg IAogICAgICAgICAgICAgQXBwcm9hY2ggMTogZXh0ZW5kZWQgU0NJTSBjcmVhdGUKICAgICAgICAg ICAgICB1c2VyIHJlcXVlc3Q6IAogICAgICAgICAgICAKICAgICAgICAgICAgICAgICB7IAogICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAic2NoZW1hcyI6WyJ1 cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sIAogICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAiZXh0ZXJuYWxJZCI6ImJqZW5zZW4iLAogICAgICAgICAgICAgIAogICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICJuYW1lIjp7IAogICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgImZvcm1hdHRlZCI6Ik1zLgogICAgICAgICAgICAgICAgQmFyYmFyYSBKIEplbnNlbiBJSUki LCAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAiZmFt aWx5TmFtZSI6IkplbnNlbiIsIAogICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgImdp dmVuTmFtZSI6IkJhcmJhcmEiCiAgICAgICAgICAgICAgCiAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgfSAKICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgInVybjpzY2ltOnNjaGVtYXM6ZXh0ZW5zaW9uOm91cnByb2R1Y3RuYW1lOjEuMCI6eyAKICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAi dXNlck5hbWVUeXBlIjoiZW1haWxfYXNfdXNlcm5hbWUiLCAKICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICB9IAogICAgICAgICAgICAKICAgICAgICAgICAgICAgICB9IAogICAgICAgICAg ICAgICAKICAgICAgICAgICAgIEFwcHJvYWNoIDI6IGRlZmluZSBzZXBhcmF0ZQogICAgICAgICAg ICAgIGVuZHBvaW50IGZvciBlYWNoIHVzZXJuYW1lIHR5cGU6IGFuIGVuZHBvaW50IHRvIGNyZWF0 ZSBhCiAgICAgICAgICAgICAgdXNlciB3aWxsIGxvb2sgbGlrZTogaHR0cHM6Ly9leGFtcGxlLmNv bS9lbWFpbF9hc191c2VybmFtZS92MS9Vc2VycwogICAgICAgICAgICAKICAgICAgICAgICAgICAg CiAgICAgICAgICAgICBBcHByb2FjaCAzOiBBc2sgdGhlIGNsaWVudAogICAgICAgICAgICAgIGRl dmVsb3BlciB0byBhcHBlbmQgYSCTdXNlck5hbWVUeXBlPYWUIHBhcmFtZXRlciB0byB0aGUKICAg ICAgICAgICAgICBlbmQgb2YgdGhlIHJlcXVlc3QuIAogICAgICAgICAgICAgICAKICAgICAgICAg ICAgIENvdWxkIHlvdSBwbGVhc2UgdGVsbCBtZSBpZiBhbnkgb2YKICAgICAgICAgICAgICB0aGUg YXBwcm9hY2hlcyBhYm92ZSBhcmUgU0NJTSBjb21wbGlhbnQgYW5kIHVzYWJsZT8gV2hhdAogICAg ICAgICAgICAgIGFsdGVybmF0aXZlcyBkbyBJIGhhdmU/IAogICAgICAgICAgICAgICAKICAgICAg ICAgICAgIFRoYW5rIHlvdSBpbiBhZHZhbmNlLCAKICAgICAgICAgICAgIE5ndXkgRHVjIFRodWFu LiAKICAgICAgICAgIAogICAgICAgICAgDQoKICAgICAgICAKICAgICAgCiAgICAKICAgIA0KIAkJ IAkgICAJCSAg --_fecb2820-1e23-4054-bd28-8970d8e1409d_ Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGkgQWxleCw8QlI+QWggeWVzLCB3ZSBhbHNvIGhhdmUg YW5vdGhlciBzZXJ2aWNlIGltcGxlbWVudGF0aW9uIHdoaWNoIHdlIHN1cHBvcnQgYSBmZXcgd2F5 cyBvZiBzcGVjaWZ5aW5nICJ1c2VybmFtZSB0eXBlIi4gT25lIG9mIHRoZW0gaXMgdG8gdXNlIGEg c2ltaWxhciBjb21iaW5hdGlvbiBzaW1pbGFyIHRvIHlvdXIgc3VnZ2VzdGlvbi4gSSB0aGluayBp dCBkb2Vzbid0IGNvbmZsaWN0IHdpdGggYW55IFNDSU0gY29uc3RyYWludCBhbmQgdGh1cyBpcyBh IHZpYWJsZSBzb2x1dGlvbi48YnI+PEJSPiZuYnNwOzxCUj48cCBzdHlsZT0iZm9udC1mYW1pbHk6 IGNhbWJyaWE7Ij5UaGFua3MgYSBidW5jaCw8L3A+CjxwIHN0eWxlPSJmb250LWZhbWlseTogY2Ft YnJpYTsiPlRodWFuLjwvcD4KPGJyPiZuYnNwOzxCUj48ZGl2PjxociBpZD0ic3RvcFNwZWxsaW5n Ij5EYXRlOiBGcmksIDQgT2N0IDIwMTMgMDc6MTY6MTIgKzAxMDA8YnI+RnJvbTogYWxleHJAcmVk c3Rvbi5jb208YnI+VG86IG5ndXlkdGh1YW5AaG90bWFpbC5jb208YnI+Q0M6IHNjaW1AaWV0Zi5v cmc8YnI+U3ViamVjdDogUmU6IFJlOiBbc2NpbV0gUmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdh aW5zdCBhIG11bHRpLXVzZXJuYW1lIHN5c3RlbTxicj48YnI+CiAgCiAgICAKICAKICAKICAgIDxk aXYgY2xhc3M9ImVjeG1vei1jaXRlLXByZWZpeCI+T3V0c2lkZSBvZiB0aGUgY29udGV4dCBvZiBT Q0lNIHNpbWlsYXIKICAgICAgc2NlbmFyaW9zIGhhdmUgY29tZSB1cCwgbGlrZSBpbiB0aGUgbmFt aW5nIG9mIHRoZSAibG9jYWxpdHkiCiAgICAgIG9iamVjdCBjbGFzcyBpbiBOZXRXYXJlIERpcmVj dG9yeSBTZXJ2aWNlcy48YnI+CiAgICAgIDxicj4KICAgICAgTXVsdGlwbGUgbmFtaW5nIGF0dHJp YnV0ZXMgaW4gY29tYmluYXRpb248YnI+CiAgICAgIDxicj4KICAgICAgVGhlIG5hbWluZyBpc3N1 ZSB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgc2ltaWxhciB0byB0aGF0IG9mIE5EUwogICAgICB3aGVy ZSBpbiB0aGUgc2NoZW1hIG1vcmUgdGhhbiBvbmUgYXR0cmlidXRlIGNvdWxkIGJlIGEgbmFtaW5n CiAgICAgIGF0dHJpYnV0ZSBmb3IgYSBnaXZlbiBvYmplY3QuPGJyPgogICAgICA8YnI+CiAgICAg IEZvciBleGFtcGxlOjxicj4KICAgICAgPGJyPgogICAgICA8cCBjbGFzcz0iZWN4cGFyYSI+U29t ZSBvYmplY3QgY2xhc3MgZGVmaW5pdGlvbnMgc3BlY2lmeSBtdWx0aXBsZQogICAgICAgIG5hbWlu ZyBhdHRyaWJ1dGVzLiBGb3IgZXhhbXBsZSwgdGhlIExvY2FsaXR5IG9iamVjdCBjbGFzcyBpcwog ICAgICAgIG5hbWVkIGJ5IHRoZSBMIChMb2NhbGl0eSBOYW1lKSBhbmQgUyAoU3RhdGUgb3IgUHJv dmluY2UgTmFtZSkKICAgICAgICBhdHRyaWJ1dGVzLiBUaHVzLCBhbiBSRE4gZm9yIGxvY2FsaXR5 IGNhbiBpbmNsdWRlIGp1c3QgYW4gTAogICAgICAgIChMb2NhbGl0eSBOYW1lKSBhdHRyaWJ1dGUs IGp1c3QgYW4gUyAoU3RhdGUgb3IgUHJvdmluY2UgTmFtZSkKICAgICAgICBhdHRyaWJ1dGUsIG9y IGJvdGggYXR0cmlidXRlcy4gRm9yIGV4YW1wbGUsIHRoZSBuYW1lIGZvciB0aGUKICAgICAgICBQ cm92bywgVXRhaCBsb2NhbGl0eSBjb3VsZCBiZTwvcD4KICAgICAgPGRpdiBjbGFzcz0iZWN4aXRl bWl6ZWRsaXN0Ij4KICAgICAgICA8dWwgY2xhc3M9ImVjeGxpc3RidWxsZXQiPgogICAgICAgICAg PGxpIGNsYXNzPSJlY3hsaXN0aXRlbSI+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hsaXN0aXRl bSI+TD1Qcm92bzwvcD4KICAgICAgICAgIDwvbGk+CiAgICAgICAgICA8bGkgY2xhc3M9ImVjeGxp c3RpdGVtIj4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeGxpc3RpdGVtIj5TPVV0YWg8L3A+CiAg ICAgICAgICA8L2xpPgogICAgICAgICAgPGxpIGNsYXNzPSJlY3hsaXN0aXRlbSI+CiAgICAgICAg ICAgIDxwIGNsYXNzPSJlY3hsaXN0aXRlbSI+TD1Qcm92byArIFM9VXRhaDwvcD4KICAgICAgICAg IDwvbGk+CiAgICAgICAgPC91bD4KICAgICAgPC9kaXY+CiAgICAgIDxwIGNsYXNzPSJlY3hwYXJh Ij5UaGUgbGFzdCBleGFtcGxlIHVzZXMgYm90aCBhdHRyaWJ1dGVzIHdpdGggYSBwbHVzCiAgICAg ICAgc2lnbiAoKykgdG8gaW5kaWNhdGUgd2hlcmUgdGhlIHNlY29uZCBhdHRyaWJ1dGWScyB2YWx1 ZSBiZWdpbnMuCiAgICAgICAgV2hlbiB0aGUgdHlwZSBzcGVjaWZpZXJzIChpbiB0aGlzIGNhc2Us IEwgYW5kIFMpIGFyZSB1c2VkIGFzCiAgICAgICAgc2hvd24sIHRoZSBuYW1lIGlzIHJlZmVycmVk IHRvIGFzIGEgdHlwZWQgbmFtZS4gQSB0eXBlbGVzcyBuYW1lCiAgICAgICAgaGFzIHRoZSBmb2xs b3dpbmcgZm9ybWF0OiCTUHJvdm8rVXRhaJQuPGJyPgogICAgICA8L3A+CiAgICAgIDxwIGNsYXNz PSJlY3hwYXJhIj5BbGV4PGJyPgogICAgICA8L3A+CiAgICAgIDxicj4KICAgICAgPHByZSBjbGFz cz0iZWN4bW96LXNpZ25hdHVyZSI+QWxleCBSZWRzdG9uCgpUZWNobmljYWwgQXJjaGl0ZWN0LCBN YW5hZ2luZyBEaXJlY3RvcgpSZWRzdG9uIFN5c3RlbXMgTGltaXRlZAoKKzQ0IDEzMjggODM4ODIx Cis0NCA3OTczIDMyMDc5NQoKUmVnaXN0ZXJlZCBPZmZpY2U6CjYgTEFOR0RBTEUgQ09VUlQKV0lU TkVZCk9YRk9SRFNISVJFClVOSVRFRCBLSU5HRE9NCk9YMjggNkZHCgpDb21wYW55IE5vLiAwMjkx NjY4MjwvcHJlPgogICAgICBPbiAwMy8xMC8yMDEzIDA4OjQ2LCBEdWMgVGh1YW4gTmd1eSB3cm90 ZTo8YnI+CiAgICA8L2Rpdj4KICAgIDxibG9ja3F1b3RlIGNpdGU9Im1pZDolM0NCQVkxNjgtVzQ5 MDJBQUM0RUEyMUMxNUI3NzAwNTZDODE3MEBwaHguZ2JsJTNFIj4KICAgICAgPHN0eWxlPjwhLS0K LkV4dGVybmFsQ2xhc3MgLmVjeGhtbWVzc2FnZSBQIHsKcGFkZGluZzowcHg7Cn0KCi5FeHRlcm5h bENsYXNzIGJvZHkuZWN4aG1tZXNzYWdlIHsKZm9udC1zaXplOjEycHQ7CmZvbnQtZmFtaWx5OkNh bGlicmk7Cn0KCi0tPjwvc3R5bGU+CiAgICAgIDxkaXYgZGlyPSJsdHIiPkhpIEJqb3JuLAogICAg ICAgIFRoYW5rIHlvdSB0YWtpbmcgdGltZSB0byByZXBseSBteSBxdWVzdGlvbi4gUGxlYXNlIGxl dCBtZQogICAgICAgICAgZXhwbGFpbiBhIGxpdHRsZSBiaXQgYWJvdXQgb3VyIHVzZXJuYW1lIHN5 c3RlbS4gSW4gZmFjdCwKICAgICAgICAgIG5vcm1hbCB1c2VybmFtZSBhbmQgZW1haWwgYXJlIG9u bHkgdHdvIGV4YW1wbGVzLiZuYnNwO090aGVyCiAgICAgICAgICBwb3NzaWJpbGl0aWVzIGluY2x1 ZGUmbmJzcDtzb2NpYWwgc2VjdXJpdHkgbnVtYmVyLCBvciBhbnkKICAgICAgICAgIHVzZXItZGVm aW5lZCB0eXBlcy4gVGhlcmUgaXMgbm8gbGltaXRhdGlvbiB3aXRoIHJlZ2FyZCB0bwogICAgICAg ICAgdXNlcm5hbWUgdHlwZXMuPEJSPgogICAgICAgICZuYnNwOzxCUj4KICAgICAgICBMb29raW5n IGF0IHRoZSBwcm9ibGVtIGZyb20gdGhlIGRhdGFiYXNlIHBvaW50IG9mIHZpZXcsIHdlCiAgICAg ICAgICBkb24ndCBoYXZlIGEgc2luZ2xlIGNvbHVtbiB0byBzdG9yZSB1c2VybmFtZS4gSW5zdGVh ZCwgYSB1c2VyCiAgICAgICAgICBoYXMgYSBsaXN0IG9mJm5ic3A7Y2xhaW1zLCZuYnNwO2UuZy46 PEJSPgogICAgICAgICZuYnNwOy0gPGEgaHJlZj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcv d3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvbmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9z Y2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL25hbWU8L2E+PEJS PgogICAgICAgICZuYnNwOy0gPGEgaHJlZj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3Mv MjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvZW1haWxhZGRyZXNzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvZW1haWxh ZGRyZXNzPC9hPjxCUj4KICAgICAgICAmbmJzcDstIGdvdjpzYW1sOmF0dHJpYnV0ZTpTb2NpYWxT ZWN1cml0eU51bWJlcjxCUj4KICAgICAgICAtIC4uLjxCUj4KICAgICAgICBBbnkmbmJzcDtvZiB0 aGVtIGNhbiBiZSB1c2VkIGFzIHVzZXJuYW1lLiBPdXIgY2xpZW50cyBjYW4gc2V0IHVwIGEKICAg ICAgICAgIGxvZ2luIHBhZ2UgZm9yIHB1YmxpYyB1c2VycyB0byB1c2UgTmFtZSBmb3IgdXNlcm5h bWUsIGFuZCBhCiAgICAgICAgICBsb2dpbiBwYWdlIGZvciBjb3Jwb3JhdGUgdXNlcnMgdG8gdXNl IGVtYWlsIGFkZHJlc3MgYXMKICAgICAgICAgIHVzZXJuYW1lLiZuYnNwO0hvd2V2ZXIsIHdoZW4g Y3JlYXRpbmcgYSBuZXcgdXNlciwgKm9uZSBhbmQgb25seQogICAgICAgICAgb25lKiB1c2VybmFt ZSB0eXBlIGlzIHJlcXVpcmVkLjxCUj4KICAgICAgICAmbmJzcDs8QlI+CiAgICAgICAgU286PEJS PgogICAgICAgIFE6IEFyZSBib3RoIGVtYWlsIGFuZCBhIHVzZXIgbmFtZSByZXF1aXJlZCBieSB5 b3VyIHN5c3RlbQogICAgICAgICAgd2hlbiBjcmVhdGluZyBhIHVzZXI/ICZuYnNwOyA8YnI+CiAg ICAgICAgICBBOiZuYnNwO05vLCBvbmx5IG9uZSBpcyByZXF1aXJlZC4gQW55IG9mIHRoZSB1c2Vy bmFtZSB0eXBlIGlzIGZpbmUuPGJyPgogICAgICAgICAgPGJyPgogICAgICAgICAgSSBhZ3JlZSB3 aXRoIHlvdSBhYm91dCAiSW4gYWxsIGNhc2VzLCBhbGxvd2luZyB0aGUgdXNlciB0byBsb2cKICAg ICAgICAgIGluIHdpdGggZWl0aGVyIG5hbWUgc2hvdWxkIGJlIGRvbmUgaW4gdGhlIGF1dGhlbnRp Y2F0aW9uCiAgICAgICAgICBsb2dpYywgbm90IGluIHRoZSBwcm92aXNpb25pbmcgZGF0YSB3aGVu IHRoZSB1c2VyIGlzIGNyZWF0ZWQuIgogICAgICAgICAgVGhlIHBvaW50IGhlcmUgaXMgdGhhdCB3 aGVuIGEgdXNlciBpcyBjcmVhdGVkLCBJIG5lZWQgdG8ga25vdwogICAgICAgICAgd2hhdCB1c2Vy bmFtZSB0eXBlIHRvIG1hcCB0aGUgInVzZXJuYW1lIiBzcGVjaWZpZWQgaW4gYW4gU0NJTQogICAg ICAgICAgcmVxdWVzdCB0by48YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICBBbSBJIHJpZ2h0 IHRoYXQgeW91ciByZXBseSBtZWFucyB1c2luZyBhIGN1c3RvbSBhdHRyaWJ1dGUKICAgICAgICAg IGxpa2VzIHRoZSBmb2xsb3dpbmcgaXMgdGhlIGJlc3Qgd2F5IEkgc2hvdWxkIGRvPzxicj4KICAg ICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7 IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwogICAgICAgICAgICAi dXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246b3VycHJvZHVjdG5hbWU6MS4wIjp7IDwvc3Bhbj48 YnI+CiAgICAgICAgPEJSPgogICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZh bWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7CiAgICAgICAgICAgICJ1c2VyTmFtZVR5cGUiOiJlbWFpbF9hc191c2Vy bmFtZSIsIDwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQt ZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7fSA8L3NwYW4+PC9wPgogICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9u dC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPjwvc3Bhbj4mbmJzcDs8 YnI+CiAgICAgICAgPGJyPgogICAgICAgICZuYnNwOzxicj4KICAgICAgICA8cCBzdHlsZT0iZm9u dC1mYW1pbHk6IGNhbWJyaWE7Ij5CZXN0IFJlZ2FyZHMsPC9wPgogICAgICAgIDxwIHN0eWxlPSJm b250LWZhbWlseTogY2FtYnJpYTsiPlRodWFuLjwvcD4KICAgICAgICAmbmJzcDs8YnI+CiAgICAg ICAgPGRpdj4KICAgICAgICAgIDxociBpZD0iZWN4c3RvcFNwZWxsaW5nIj5EYXRlOiBXZWQsIDIg T2N0IDIwMTMgMTc6MzQ6NTEgKzAwMDA8YnI+CiAgICAgICAgICBGcm9tOiA8YSBjbGFzcz0iZWN4 bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Ympvcm4uYWFubmVzdGFkQHVu Ym91bmRpZC5jb20iPmJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tPC9hPjxicj4KICAgICAg ICAgIFRvOiA8YSBjbGFzcz0iZWN4bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls dG86bmd1eWR0aHVhbkBob3RtYWlsLmNvbSI+bmd1eWR0aHVhbkBob3RtYWlsLmNvbTwvYT47IDxh IGNsYXNzPSJlY3htb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpzY2ltQGll dGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4KICAgICAgICAgIFN1YmplY3Q6IFJFOiBbc2Np bV0gUmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhCiAgICAgICAgICBtdWx0aS11c2Vy bmFtZSBzeXN0ZW08YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICBZb3UgY291bGQgYWRkIGEg Y3VzdG9tIGF0dHJpYnV0ZSBmb3IgdGhlIHVzZXIgbmFtZSB0eXBlIC0KICAgICAgICAgIHRob3Nl IGtpbmRzIG9mIGV4dGVuc2lvbnMgYXJlIHN1cHBvcnRlZCBieSB0aGUgc3BlY2lmaWNhdGlvbi4K ICAgICAgICAgICZuYnNwO0hvd2V2ZXIsIEknbSBkbyBub3QgdGhpbmsgbWl4aW5nIHRoZSB0d28g YXR0cmlidXRlIHR5cGVzIGlzCiAgICAgICAgICB0aGUgcmlnaHQgc29sdXRpb24uIDxicj4KICAg ICAgICAgIDxicj4KICAgICAgICAgIEFyZSBib3RoIGVtYWlsIGFuZCBhIHVzZXIgbmFtZSByZXF1 aXJlZCBieSB5b3VyIHN5c3RlbSB3aGVuCiAgICAgICAgICBjcmVhdGluZyBhIHVzZXI/ICZuYnNw OyA8YnI+CiAgICAgICAgICBJZiBzbywgSSB3b3VsZCByZWNvbW1lbmQgc3RvcmluZyBlYWNoIGlu IHRoZWlyIHJlc3BlY3RpdmUKICAgICAgICAgIHByZWRlZmluZWQgYXR0cmlidXRlcy4gJm5ic3A7 Jm5ic3A7IDxicj4KICAgICAgICAgIDxicj4KICAgICAgICAgIElmIG9ubHkgYW4gZW1haWwgYWRk cmVzcyBpcyByZXF1aXJlZCB3aGVuIGNyZWF0aW5nIGEgdXNlciwKICAgICAgICAgIHdoZW4gdGhh dCBpcyBhbGwgeW91IGhhdmUsIEkgd291bGQgcmVjb21tZW5kIHN0b3JpbmcgdGhlIGVtYWlsCiAg ICAgICAgICBpbiBib3RoIGF0dHJpYnV0ZXMuIDxicj4KICAgICAgICAgIDxicj4KICAgICAgICAg IElmIG9ubHkgYSB1c2VyIG5hbWUgaXMgcmVxdWlyZWQsIGFuZCB0aGUgZW1haWwgaXMgb3B0aW9u YWwsCiAgICAgICAgICB0aGVuIG9mIGNvdXJzZSBzdG9yZSB0aGUgdXNlciBuYW1lIGFuZCBsZWF2 ZSB0aGUgZW1haWwgYmxhbmsuCiAgICAgICAgICA8YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAg ICBJbiBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3aXRoIGVpdGhlciBu YW1lCiAgICAgICAgICBzaG91bGQgYmUgZG9uZSBpbiB0aGUgYXV0aGVudGljYXRpb24gbG9naWMs IG5vdCBpbiB0aGUKICAgICAgICAgIHByb3Zpc2lvbmluZyBkYXRhIHdoZW4gdGhlIHVzZXIgaXMg Y3JlYXRlZC4gPGJyPgogICAgICAgICAgPGJyPgogICAgICAgICAgLUJqb3JuIEFhbm5lc3RhZCA8 YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAg ICA8YnI+CiAgICAgICAgICA8aHI+IDxiPkZyb206PC9iPiA8YSBzdHlsZT0iY3Vyc29yOiBwb2lu dGVyOyIgaHJlZj0ibWFpbHRvOkR1YyUyMFRodWFuJTIwTmd1eSUyMCUyOG5ndXlkdGh1YW5AaG90 bWFpbC5jb20lMjkiPkR1YwogICAgICAgICAgICBUaHVhbiBOZ3V5IChuZ3V5ZHRodWFuQGhvdG1h aWwuY29tKTwvYT4gPGJyPgogICAgICAgICAgPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIg MSwgMjAxMyAxMDoyOCBQTSA8YnI+CiAgICAgICAgICA8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiA8YnI+CiAgICAgICAgICA8Yj5TdWJq ZWN0PC9iPjogW3NjaW1dIFJlc2VuZDogSG93IHRvIHVzZSBTQ0lNIGFnYWluc3QgYQogICAgICAg ICAgbXVsdGktdXNlcm5hbWUgc3lzdGVtCiAgICAgICAgICA8ZGl2IHN0eWxlPSJoZWlnaHQ6IDVw eDsiPiAmbmJzcDsgPC9kaXY+CiAgICAgICAgICA8c3R5bGU+PCEtLQouRXh0ZXJuYWxDbGFzcyAu ZWN4aG1tZXNzYWdlIFAgewpwYWRkaW5nOjBweDsKfQoKLkV4dGVybmFsQ2xhc3MgYm9keS5lY3ho bW1lc3NhZ2Ugewpmb250LXNpemU6MTJwdDsKZm9udC1mYW1pbHk6Q2FsaWJyaTsKfQoKCi0tPjwv c3R5bGU+CiAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4KICAgICAgICAgICAgPHAgY2xhc3M9ImVj eE1zb05vcm1hbCI+IEhpIFNDSU0gZ3JvdXBzLCA8L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPiAoSSByZXNlbmQgdGhpcyBlbWFpbCBiZWNhdXNlIGl0CiAgICAgICAgICAg ICAgc2VlbXMgdGhlIGZpcnN0IG9uZSBnb3QgbG9zdCBzb21ld2hlcmUuIFBlcmhhcHMgaXQgaXMK ICAgICAgICAgICAgICBiZWNhdXNlIEkgc2VudCBpdCBmcm9tIGFub3RoZXIgZW1haWwgYWNjb3Vu dCB3aGljaCB3YXNuJ3QKICAgICAgICAgICAgICBzdWJzY3JpYmVkIHRvIHRoZSBTQ0lNIGdyb3Vw LiBUaGlzIGVtYWlsIGFpbXMgdG8gY29ycmVjdAogICAgICAgICAgICAgIHRoYXQgbWlzdGFrZSk8 L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiA8L3A+CiAgICAgICAgICAg IDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBPdXIgY29tcGFueSB3YW50cyB0byBpbXBsZW1lbnQg U0NJTQogICAgICAgICAgICAgIDEuMSBmb3Igb3VyIGlkZW50aXR5IG1hbmFnZW1lbnQgcHJvZHVj dC4gSSB0aGluayBTQ0lNIGlzCiAgICAgICAgICAgICAgZ3JlYXQgeWV0IHNpbXBsZSBmcmFtZXdv cmsgYW5kIGlzIHZlcnkgZWFnZXIgdG8gaW1wbGVtZW50CiAgICAgICAgICAgICAgaXQuIEhvd2V2 ZXIsIEkgZmluZCBvbmUgcHJvYmxlbSB3aGVuIEkgdHJ5IHRvIGFkb3B0IFNDSU0KICAgICAgICAg ICAgICBmb3Igb3VyIHN5c3RlbTogc2ltcGx5IHNwZWFraW5nLCBvdXIgc3lzdGVtIHN1cHBvcnRz CiAgICAgICAgICAgICAgbXVsdGlwbGUgdXNlcm5hbWVzLiBJbiBvdGhlciB3b3Jkcywgb25lIHVz ZXIgY2FuIGhhdmUgbW9yZQogICAgICAgICAgICAgIHRoYW4gb25lIHVzZXJuYW1lcywgZm9yIGV4 YW1wbGU6IDwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDogLTAuMjVpbjsiPgogICAgICAgICAgICAgIDxzcGFuPjxzcGFuPi08 c3BhbiBzdHlsZT0nZm9udDogN3B0L25vcm1hbCAiVGltZXMgTmV3IFJvbWFuIjsgZm9udC1zaXpl LWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWw7Jz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ CiAgICAgICAgICAgICAgVXNlcm5hbWVfYXNfdXNlcm5hbWU6IGJqZW5zZW4uIDwvcD4KICAgICAg ICAgICAgPHAgY2xhc3M9ImVjeE1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDog LTAuMjVpbjsiPgogICAgICAgICAgICAgIDxzcGFuPjxzcGFuPi08c3BhbiBzdHlsZT0nZm9udDog N3B0L25vcm1hbCAiVGltZXMgTmV3IFJvbWFuIjsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9u dC1zdHJldGNoOiBub3JtYWw7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+CiAgICAgICAgICAgICAgRW1h aWxfYXNfdXNlcm5hbWU6IDxmb250IGNvbG9yPSIjMDAwMGZmIj48YSBocmVmPSJtYWlsdG86Ympl bnNlbkBleGFtcGxlLmNvbSI+YmplbnNlbkBleGFtcGxlLmNvbTwvYT48L2ZvbnQ+CiAgICAgICAg ICAgIDwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+IEEgdXNlciBjYW4g dXNlIGFueSBvZiB0aGUKICAgICAgICAgICAgICCTdXNlcm5hbWWUIHRvIGxvZ2luLiA8L3A+CiAg ICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiAmbmJzcDsgPC9wPgogICAgICAgICAg ICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gQXMgYSBjb25zZXF1ZW50LCB3aGVuIGEgY3JlYXRl IHVzZXIKICAgICAgICAgICAgICByZXF1ZXN0IG5lZWRzIHRvIHNwZWNpZnkgbm90IG9ubHkgYSB1 c2VybmFtZSBidXQgYWxzbyB0aGUKICAgICAgICAgICAgICB0eXBlIG9mIHRoYXQgdXNlcm5hbWUu IFVuZm9ydHVuYXRlbHksIEkgY291bGRuknQgZmluZCBhbnkKICAgICAgICAgICAgICBwcmVkZWZp bmVkIFNDSU0gYXR0cmlidXRlIHdoaWNoIGNhbiBiZSB1c2VkIGZvciB0aGF0IJN0eXBlCiAgICAg ICAgICAgICAgb2YgdXNlcm5hbWWULiA8L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29O b3JtYWwiPiAmbmJzcDsgPC9wPgogICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4g SSBjYW4gdGhpbmsgb2YgYSBmZXcgb3B0aW9uczogPC9wPgogICAgICAgICAgICA8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj4gJm5ic3A7IDwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05v cm1hbCI+IEEgc3RhbmRhcmQgU0NJTSBjcmVhdGUgdXNlcgogICAgICAgICAgICAgIHJlcXVlc3Q6 IDwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAgICAgICAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9 J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJz cDsgeyA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgogICAgICAgICAgICAgIDxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwogICAgICAgICAgICAgICAgInNjaGVtYXMiOlsidXJu OnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLCA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFz cz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgogICAg ICAgICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5l dyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAidXNlck5hbWUi OiJiamVuc2VuIiwgPC9zcGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAgICAgICAgICA8c3Bh biBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6 IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImV4dGVybmFsSWQiOiJiamVuc2VuIiwK ICAgICAgICAgICAgICA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgogICAgICAgICAgICAgIDxz cGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6 ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAibmFtZSI6eyA8L3NwYW4+PC9wPgog ICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6IGFsd2F5czsiPgogICAgICAgICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1m YW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAiZm9ybWF0dGVkIjoiTXMuCiAgICAgICAgICAgICAgICBCYXJi YXJhIEogSmVuc2VuIElJSSIsIDwvc3Bhbj48L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hN c29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+CiAgICAgICAgICAg ICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9u dC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiAgICAg ICAgICAgICAgICAiZmFtaWx5TmFtZSI6IkplbnNlbiIsIDwvc3Bhbj48L3A+CiAgICAgICAgICAg IDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+CiAgICAgICAgICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNv dXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICJnaXZlbk5hbWUiOiJCYXJiYXJhIgogICAgICAgICAgICAgIDwvc3Bhbj48L3A+ CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTogYWx3YXlzOyI+CiAgICAgICAgICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250 LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH0gPC9zcGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAgICAgICAgICA8c3Bh biBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6 IDEycHQ7Jz4mbmJzcDsmbmJzcDsgfSA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj4gJm5ic3A7IDwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05v cm1hbCI+IEFwcHJvYWNoIDE6IGV4dGVuZGVkIFNDSU0gY3JlYXRlCiAgICAgICAgICAgICAgdXNl ciByZXF1ZXN0OiA8L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+CiAgICAgICAgICAgICAgPHNwYW4gbGFuZz0i RU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+ Jm5ic3A7Jm5ic3A7IHsgPC9zcGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAgICAgICAgICA8 c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNp emU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKICAgICAgICAgICAgICAgICJzY2hl bWFzIjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwgPC9zcGFuPjwvcD4KICAgICAgICAg ICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdh eXM7Ij4KICAgICAgICAgICAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAi Q291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg InVzZXJOYW1lIjoiYmplbnNlbiIsIDwvc3Bhbj48L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+CiAgICAgICAg ICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Ijsg Zm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJleHRlcm5hbElkIjoi YmplbnNlbiIsCiAgICAgICAgICAgICAgPC9zcGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9 ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAg ICAgICAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXci OyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIm5hbWUiOnsgPC9z cGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOiBhbHdheXM7Ij4KICAgICAgICAgICAgICA8c3BhbiBsYW5nPSJFTiIgc3R5 bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImZvcm1hdHRlZCI6Ik1zLgogICAgICAgICAg ICAgICAgQmFyYmFyYSBKIEplbnNlbiBJSUkiLCA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBj bGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgog ICAgICAgICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVy IE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwogICAgICAgICAgICAgICAgImZhbWlseU5hbWUiOiJKZW5zZW4iLCA8L3NwYW4+PC9wPgog ICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6IGFsd2F5czsiPgogICAgICAgICAgICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1m YW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAiZ2l2ZW5OYW1lIjoiQmFyYmFyYSIKICAgICAgICAgICAgICA8 L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgogICAgICAgICAgICAgIDxzcGFuIGxhbmc9IkVOIiBz dHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB9IDwvc3Bhbj48L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+CiAgICAgICAg ICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Ijsg Zm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiAgICAgICAgICAgICAg ICAidXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246b3VycHJvZHVjdG5hbWU6MS4wIjp7IDwvc3Bh bj48L3A+CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTogYWx3YXlzOyI+CiAgICAgICAgICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxl PSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiAgICAgICAgICAgICAgICAidXNlck5hbWVUeXBlIjoi ZW1haWxfYXNfdXNlcm5hbWUiLCA8L3NwYW4+PC9wPgogICAgICAgICAgICA8cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPgogICAgICAgICAg ICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZv bnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDt9IDwvc3Bhbj48L3A+CiAg ICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTogYWx3YXlzOyI+CiAgICAgICAgICAgICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZh bWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7IH0gPC9z cGFuPjwvcD4KICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+ICZuYnNwOyA8L3A+ CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBBcHByb2FjaCAyOiBkZWZpbmUg c2VwYXJhdGUKICAgICAgICAgICAgICBlbmRwb2ludCBmb3IgZWFjaCB1c2VybmFtZSB0eXBlOiBh biBlbmRwb2ludCB0byBjcmVhdGUgYQogICAgICAgICAgICAgIHVzZXIgd2lsbCBsb29rIGxpa2U6 IDxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vZW1haWxfYXNfdXNlcm5hbWUvdjEvVXNlcnMi IHRhcmdldD0iX2JsYW5rIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+aHR0cHM6Ly9leGFtcGxlLmNv bS9lbWFpbF9hc191c2VybmFtZS92MS9Vc2VyczwvZm9udD48L2E+CiAgICAgICAgICAgIDwvcD4K ICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+ICZuYnNwOyA8L3A+CiAgICAgICAg ICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBBcHByb2FjaCAzOiBBc2sgdGhlIGNsaWVudAog ICAgICAgICAgICAgIGRldmVsb3BlciB0byBhcHBlbmQgYSCTdXNlck5hbWVUeXBlPYWUIHBhcmFt ZXRlciB0byB0aGUKICAgICAgICAgICAgICBlbmQgb2YgdGhlIHJlcXVlc3QuIDwvcD4KICAgICAg ICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+ICZuYnNwOyA8L3A+CiAgICAgICAgICAgIDxw IGNsYXNzPSJlY3hNc29Ob3JtYWwiPiBDb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgaWYgYW55IG9m CiAgICAgICAgICAgICAgdGhlIGFwcHJvYWNoZXMgYWJvdmUgYXJlIFNDSU0gY29tcGxpYW50IGFu ZCB1c2FibGU/IFdoYXQKICAgICAgICAgICAgICBhbHRlcm5hdGl2ZXMgZG8gSSBoYXZlPyA8L3A+ CiAgICAgICAgICAgIDxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiAmbmJzcDsgPC9wPgogICAgICAg ICAgICA8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4gVGhhbmsgeW91IGluIGFkdmFuY2UsIDwvcD4K ICAgICAgICAgICAgPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+IE5ndXkgRHVjIFRodWFuLiA8L3A+ CiAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDxicj4KICAgICAgICA8L2Rpdj4KICAgICAgPC9k aXY+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+PC9kaXY+IAkJIAkgICAJCSAgPC9kaXY+PC9i b2R5Pg0KPC9odG1sPg== --_fecb2820-1e23-4054-bd28-8970d8e1409d_-- From nguydthuan@hotmail.com Tue Oct 8 00:24:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC721F9C52 for ; Tue, 8 Oct 2013 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajPHcBS5JBIY for ; Tue, 8 Oct 2013 00:24:50 -0700 (PDT) Received: from bay0-omc4-s4.bay0.hotmail.com (bay0-omc4-s4.bay0.hotmail.com [65.54.190.206]) by ietfa.amsl.com (Postfix) with ESMTP id 562AE21E8155 for ; Tue, 8 Oct 2013 00:24:47 -0700 (PDT) Received: from BAY168-W19 ([65.54.190.200]) by bay0-omc4-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Oct 2013 00:24:46 -0700 X-TMN: [ESqzfN6gTsrDI6X2tcTD80INJ5UF0uvi] X-Originating-Email: [nguydthuan@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_04cfbf6a-500e-41e2-a708-94f2e8a2a820_" From: Duc Thuan Nguy To: "samuel@erdtman.se" Date: Tue, 8 Oct 2013 14:24:46 +0700 Importance: Normal In-Reply-To: References: , <975670102.4475.1380735293319.JavaMail.tomcat@ip-10-46-217-43>, , MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2013 07:24:46.0633 (UTC) FILETIME=[774F0990:01CEC3F7] Cc: "scim@ietf.org" Subject: Re: [scim] Resend: How to use SCIM against a multi-username system X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:24:55 -0000 --_04cfbf6a-500e-41e2-a708-94f2e8a2a820_ Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: base64 CgoKSGkgU2FtdWVsLA0KTm9wZSwgbm90IGxhdGUgeWV0LiBJIGRlbGF5ZWQgdGhpcyB0YXNrIGZv ciBhIHdlZWsgYW5kIHBsYW5uZWQgdG8gc3RhcnQgaXQgdG9tb3Jyb3cuIEJhY2sgdG8gdG9waWMs IGluIHRoZSB3b3JsZCBvZiBmZWRlcmF0ZWQgYWNjZXNzIG1hbmFnZW1lbnQgd2hlcmUgd2UgbmVl ZCB0byBtYW5hZ2UgaWRlbnRpdGllcyBmcm9tIG11bHRpcGxlIElkZW50aXR5IFByb3ZpZGVycywg SSB0aGluayB0aGVyZSBhcmUgb3RoZXIgcGVvcGxlIHdobyBuZWVkIHRvIGRlYWwgd2l0aCBzaW1p bGFyIHVzZSBjYXNlcy4gSSdtIGVhZ2VyIHRvIHNlZSB3aGF0IHNvbHV0aW9ucyB0aGV5IGNvbWUg dXAgd2l0aCB0aGV5IHN0YXJ0IHRvIGFkb3B0IFNDSU0uDQoNCkJlc3QgUmVnYXJkcyxUaHVhbi4K IAoNCiANCkRhdGU6IFN1biwgNiBPY3QgMjAxMyAxOTowNzoyNyAtMDUwMA0KU3ViamVjdDogUmU6 IFtzY2ltXSBSZXNlbmQ6IEhvdyB0byB1c2UgU0NJTSBhZ2FpbnN0IGEgbXVsdGktdXNlcm5hbWUg c3lzdGVtDQpGcm9tOiBzYW11ZWxAZXJkdG1hbi5zZQ0KVG86IG5ndXlkdGh1YW5AaG90bWFpbC5j b20NCkNDOiBzY2ltQGlldGYub3JnDQoNCkhpIFRodWFuLA0KQSBiaXQgbGF0ZSBidXQgYW55d2F5 LkludGVyZXN0aW5nIHVzZS1jYXNlLCBJIHRoaW5rIHRoYXQgeW91IHNvbHV0aW9uIHdpdGggdGhl IGV4dGVuc2lvbiBpcyBhIGdvb2Qgd2F5IHRvIGdvIHRvIHNwZWNpZnkgdGhlIGF0dHJpYnV0ZSB0 aGF0IHRoZSB1c2VyIHNob3VsZCB1c2UgdG8gYXV0aGVudGljYXRlIHdpdGguIE9uZSBjb21tZW50 IHRob3VnaCwgSSB3b3VsZCBjcmVhdGUgdGhlIGV4dGVuc2lvbiBsaWtlIHRoaXM6CiJ1cm46c2Np bTpzY2hlbWFzOmV4dGVuc2lvbjo8QWRpdGlvbmFsIGxvZ2luIGRhdGE+OjEuMCI6ew0KICAgInVz ZXJOYW1lIjoiPHNjaW1fYXR0cmlidXRlX25hbWU+IiwNCgp9DQpJZiBtb3JlIHBlb3BsZSBoYXMg dGhpcyBwcm9ibGVtIHRoZXkgbWlnaHQgd2FudCB0byB1c2UgeW91IGV4dGVuc2lvbiBpZiBpdCBk b2VzIG5vdCBjb250YWluIHlvdSBjb21wYW55IG5hbWUuIEFuZCBpZiB0aGVyZSBpcyBlbm91Z2gg dHJhY3Rpb24gaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gaW5jbHVkZSBpbiBhIGZ1dHVyZSB2ZXJz aW9uIG9mIFNDSU0uCg0KQ2hlZXJzLy9TYW11ZWwNCg0KDQoNCg0KDQoNCk9uIFRodSwgT2N0IDMs IDIwMTMgYXQgMjo0NiBBTSwgRHVjIFRodWFuIE5ndXkgPG5ndXlkdGh1YW5AaG90bWFpbC5jb20+ IHdyb3RlOg0KCgoKCkhpIEJqb3JuLFRoYW5rIHlvdSB0YWtpbmcgdGltZSB0byByZXBseSBteSBx dWVzdGlvbi4gUGxlYXNlIGxldCBtZSBleHBsYWluIGEgbGl0dGxlIGJpdCBhYm91dCBvdXIgdXNl cm5hbWUgc3lzdGVtLiBJbiBmYWN0LCBub3JtYWwgdXNlcm5hbWUgYW5kIGVtYWlsIGFyZSBvbmx5 IHR3byBleGFtcGxlcy4gT3RoZXIgcG9zc2liaWxpdGllcyBpbmNsdWRlIHNvY2lhbCBzZWN1cml0 eSBudW1iZXIsIG9yIGFueSB1c2VyLWRlZmluZWQgdHlwZXMuIFRoZXJlIGlzIG5vIGxpbWl0YXRp b24gd2l0aCByZWdhcmQgdG8gdXNlcm5hbWUgdHlwZXMuDQoKIA0KTG9va2luZyBhdCB0aGUgcHJv YmxlbSBmcm9tIHRoZSBkYXRhYmFzZSBwb2ludCBvZiB2aWV3LCB3ZSBkb24ndCBoYXZlIGEgc2lu Z2xlIGNvbHVtbiB0byBzdG9yZSB1c2VybmFtZS4gSW5zdGVhZCwgYSB1c2VyIGhhcyBhIGxpc3Qg b2YgY2xhaW1zLCBlLmcuOg0KIC0gaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8w NS9pZGVudGl0eS9jbGFpbXMvbmFtZQ0KCiAtIGh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dz LzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL2VtYWlsYWRkcmVzcw0KIC0gZ292OnNhbWw6YXR0cmli dXRlOlNvY2lhbFNlY3VyaXR5TnVtYmVyDQoKLSAuLi4NCkFueSBvZiB0aGVtIGNhbiBiZSB1c2Vk IGFzIHVzZXJuYW1lLiBPdXIgY2xpZW50cyBjYW4gc2V0IHVwIGEgbG9naW4gcGFnZSBmb3IgcHVi bGljIHVzZXJzIHRvIHVzZSBOYW1lIGZvciB1c2VybmFtZSwgYW5kIGEgbG9naW4gcGFnZSBmb3Ig Y29ycG9yYXRlIHVzZXJzIHRvIHVzZSBlbWFpbCBhZGRyZXNzIGFzIHVzZXJuYW1lLiBIb3dldmVy LCB3aGVuIGNyZWF0aW5nIGEgbmV3IHVzZXIsICpvbmUgYW5kIG9ubHkgb25lKiB1c2VybmFtZSB0 eXBlIGlzIHJlcXVpcmVkLg0KCiANClNvOg0KUTogQXJlIGJvdGggZW1haWwgYW5kIGEgdXNlciBu YW1lIHJlcXVpcmVkIGJ5IHlvdXIgc3lzdGVtIHdoZW4gY3JlYXRpbmcgYSB1c2VyPyAgICAgDQog QTogTm8sIG9ubHkgb25lIGlzIHJlcXVpcmVkLiBBbnkgb2YgdGhlIHVzZXJuYW1lIHR5cGUgaXMg ZmluZS4NCg0KSSBhZ3JlZSB3aXRoIHlvdSBhYm91dCAiSW4gYWxsIGNhc2VzLCBhbGxvd2luZyB0 aGUgdXNlciB0byBsb2cgaW4gd2l0aCBlaXRoZXIgbmFtZSBzaG91bGQgYmUgZG9uZSBpbiB0aGUg YXV0aGVudGljYXRpb24gbG9naWMsIG5vdCBpbiB0aGUgcHJvdmlzaW9uaW5nIGRhdGEgd2hlbiB0 aGUgdXNlciBpcyBjcmVhdGVkLiIgVGhlIHBvaW50IGhlcmUgaXMgdGhhdCB3aGVuIGEgdXNlciBp cyBjcmVhdGVkLCBJIG5lZWQgdG8ga25vdyB3aGF0IHVzZXJuYW1lIHR5cGUgdG8gbWFwIHRoZSAi dXNlcm5hbWUiIHNwZWNpZmllZCBpbiBhbiBTQ0lNIHJlcXVlc3QgdG8uDQoKDQpBbSBJIHJpZ2h0 IHRoYXQgeW91ciByZXBseSBtZWFucyB1c2luZyBhIGN1c3RvbSBhdHRyaWJ1dGUgbGlrZXMgdGhl IGZvbGxvd2luZyBpcyB0aGUgYmVzdCB3YXkgSSBzaG91bGQgZG8/DQoNCiAgICAgInVybjpzY2lt OnNjaGVtYXM6ZXh0ZW5zaW9uOm91cnByb2R1Y3RuYW1lOjEuMCI6eyAgICAgICANCgogICAgICAg ICAgICAgICAgInVzZXJOYW1lVHlwZSI6ImVtYWlsX2FzX3VzZXJuYW1lIiwgICAgICAgDQogICAg IH0gDQoKIA0KDQogDQpCZXN0IFJlZ2FyZHMsClRodWFuLgogDQpEYXRlOiBXZWQsIDIgT2N0IDIw MTMgMTc6MzQ6NTEgKzAwMDANCkZyb206IGJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tDQpU bzogbmd1eWR0aHVhbkBob3RtYWlsLmNvbTsgc2NpbUBpZXRmLm9yZw0KClN1YmplY3Q6IFJFOiBb c2NpbV0gUmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhIG11bHRpLXVzZXJuYW1lIHN5 c3RlbQ0KDQoKIAogCiAgWW91IGNvdWxkIGFkZCBhIGN1c3RvbSBhdHRyaWJ1dGUgZm9yIHRoZSB1 c2VyIG5hbWUgdHlwZSAtIHRob3NlIGtpbmRzIG9mIGV4dGVuc2lvbnMgYXJlIHN1cHBvcnRlZCBi eSB0aGUgc3BlY2lmaWNhdGlvbi4gIEhvd2V2ZXIsIEknbSBkbyBub3QgdGhpbmsgbWl4aW5nIHRo ZSB0d28gYXR0cmlidXRlIHR5cGVzIGlzIHRoZSByaWdodCBzb2x1dGlvbi4KICANCiAKICANCiBB cmUgYm90aCBlbWFpbCBhbmQgYSB1c2VyIG5hbWUgcmVxdWlyZWQgYnkgeW91ciBzeXN0ZW0gd2hl biBjcmVhdGluZyBhIHVzZXI/ICAKICANCiBJZiBzbywgSSB3b3VsZCByZWNvbW1lbmQgc3Rvcmlu ZyBlYWNoIGluIHRoZWlyIHJlc3BlY3RpdmUgcHJlZGVmaW5lZCBhdHRyaWJ1dGVzLiAgIAogIA0K IAogIA0KIElmIG9ubHkgYW4gZW1haWwgYWRkcmVzcyBpcyByZXF1aXJlZCB3aGVuIGNyZWF0aW5n IGEgdXNlciwgd2hlbiB0aGF0IGlzIGFsbCB5b3UgaGF2ZSwgSSB3b3VsZCByZWNvbW1lbmQgc3Rv cmluZyB0aGUgZW1haWwgaW4gYm90aCBhdHRyaWJ1dGVzLgogIA0KIAogIA0KIElmIG9ubHkgYSB1 c2VyIG5hbWUgaXMgcmVxdWlyZWQsIGFuZCB0aGUgZW1haWwgaXMgb3B0aW9uYWwsIHRoZW4gb2Yg Y291cnNlIHN0b3JlIHRoZSB1c2VyIG5hbWUgYW5kIGxlYXZlIHRoZSBlbWFpbCBibGFuay4KICAN CiAKICANCiBJbiBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3aXRoIGVp dGhlciBuYW1lIHNob3VsZCBiZSBkb25lIGluIHRoZSBhdXRoZW50aWNhdGlvbiBsb2dpYywgbm90 IGluIHRoZSBwcm92aXNpb25pbmcgZGF0YSB3aGVuIHRoZSB1c2VyIGlzIGNyZWF0ZWQuCiAgDQog CiAgDQogLUJqb3JuIEFhbm5lc3RhZAogIA0KIAogIA0KIAogIA0KIAogIA0KIAogIA0KIAogICAK ICBGcm9tOiAKICBEdWMgVGh1YW4gTmd1eSAobmd1eWR0aHVhbkBob3RtYWlsLmNvbSkKICANCiAK ICBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEsIDIwMTMgMTA6MjggUE0KICANCiAKICBUbzogCiAg c2NpbUBpZXRmLm9yZwogIA0KIAogIFN1YmplY3Q6IFtzY2ltXSBSZXNlbmQ6IEhvdyB0byB1c2Ug U0NJTSBhZ2FpbnN0IGEgbXVsdGktdXNlcm5hbWUgc3lzdGVtIAogIAogICAgIAogICAKICAgCiAg IAogICAgSGkgU0NJTSBncm91cHMsIAogICAgDQogCiAgICAoSSByZXNlbmQgdGhpcyBlbWFpbCBi ZWNhdXNlIGl0IHNlZW1zIHRoZSBmaXJzdCBvbmUgZ290IGxvc3Qgc29tZXdoZXJlLiBQZXJoYXBz IGl0IGlzIGJlY2F1c2UgSSBzZW50IGl0IGZyb20gYW5vdGhlciBlbWFpbCBhY2NvdW50IHdoaWNo IHdhc24ndCBzdWJzY3JpYmVkIHRvIHRoZSBTQ0lNIGdyb3VwLiBUaGlzIGVtYWlsIGFpbXMgdG8g Y29ycmVjdCB0aGF0IG1pc3Rha2UpDQoKIAogICAgCiAgICANCiAKICAgIE91ciBjb21wYW55IHdh bnRzIHRvIGltcGxlbWVudCBTQ0lNIDEuMSBmb3Igb3VyIGlkZW50aXR5IG1hbmFnZW1lbnQgcHJv ZHVjdC4gSSB0aGluayBTQ0lNIGlzIGdyZWF0IHlldCBzaW1wbGUgZnJhbWV3b3JrIGFuZCBpcyB2 ZXJ5IGVhZ2VyIHRvIGltcGxlbWVudCBpdC4gSG93ZXZlciwgSSBmaW5kIG9uZSBwcm9ibGVtIHdo ZW4gSSB0cnkgdG8gYWRvcHQgU0NJTSBmb3Igb3VyIHN5c3RlbTogc2ltcGx5IHNwZWFraW5nLCBv dXIgc3lzdGVtIHN1cHBvcnRzIG11bHRpcGxlIHVzZXJuYW1lcy4gSW4gb3RoZXIgd29yZHMsIG9u ZSB1c2VyIGNhbiBoYXZlIG1vcmUgdGhhbiBvbmUgdXNlcm5hbWVzLCBmb3IgZXhhbXBsZTogCiAg ICANCiAKICAgIAogICAgLSAgICAgICAgICAgCiAgICBVc2VybmFtZV9hc191c2VybmFtZTogYmpl bnNlbi4gCiAgICANCiAKICAgIAogICAgLSAgICAgICAgICAgCiAgICBFbWFpbF9hc191c2VybmFt ZTogYmplbnNlbkBleGFtcGxlLmNvbSAKICAgIA0KIAogICAgQSB1c2VyIGNhbiB1c2UgYW55IG9m IHRoZSCTdXNlcm5hbWWUIHRvIGxvZ2luLiAKICAgIA0KIAogICAgCiAgICAKICAgICAgICAKICAg IA0KIAogICAgQXMgYSBjb25zZXF1ZW50LCB3aGVuIGEgY3JlYXRlIHVzZXIgcmVxdWVzdCBuZWVk cyB0byBzcGVjaWZ5IG5vdCBvbmx5IGEgdXNlcm5hbWUgYnV0IGFsc28gdGhlIHR5cGUgb2YgdGhh dCB1c2VybmFtZS4gVW5mb3J0dW5hdGVseSwgSSBjb3VsZG6SdCBmaW5kIGFueSBwcmVkZWZpbmVk IFNDSU0gYXR0cmlidXRlIHdoaWNoIGNhbiBiZSB1c2VkIGZvciB0aGF0IJN0eXBlIG9mIHVzZXJu YW1llC4gCiAgICANCiAKICAgIAogICAgCiAgICAgICAgCiAgICANCiAKICAgIEkgY2FuIHRoaW5r IG9mIGEgZmV3IG9wdGlvbnM6IAogICAgDQogCiAgICAKICAgIAogICAgICAgIAogICAgDQogCiAg ICBBIHN0YW5kYXJkIFNDSU0gY3JlYXRlIHVzZXIgcmVxdWVzdDogCiAgICANCiAKICAgICAgIHsg CiAgICAgDQogCiAgICAgICAgICJzY2hlbWFzIjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAi XSwgCiAgICAgDQogCiAgICAgICAgICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICANCiAKICAg ICAgICAgImV4dGVybmFsSWQiOiJiamVuc2VuIiwgCiAgICAgDQogCiAgICAgICAgICJuYW1lIjp7 IAogICAgIA0KIAogICAgICAgICAgICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJ SUkiLCAKICAgICANCiAKICAgICAgICAgICAiZmFtaWx5TmFtZSI6IkplbnNlbiIsIAogICAgIA0K IAogICAgICAgICAgICJnaXZlbk5hbWUiOiJCYXJiYXJhIiAKICAgICANCiAKICAgICAgICAgfSAK ICAgICANCiAKICAgICAgIH0gCiAgICAgDQogCiAgICAKICAgIAogICAgICAgIAogICAgDQogCiAg ICBBcHByb2FjaCAxOiBleHRlbmRlZCBTQ0lNIGNyZWF0ZSB1c2VyIHJlcXVlc3Q6IAogICAgDQog CiAgICAgICB7IAogICAgIA0KIAogICAgICAgICAic2NoZW1hcyI6WyJ1cm46c2NpbTpzY2hlbWFz OmNvcmU6MS4wIl0sIAogICAgIA0KIAogICAgICAgICAidXNlck5hbWUiOiJiamVuc2VuIiwgCiAg ICAgDQogCiAgICAgICAgICJleHRlcm5hbElkIjoiYmplbnNlbiIsIAogICAgIA0KIAogICAgICAg ICAibmFtZSI6eyAKICAgICANCiAKICAgICAgICAgICAiZm9ybWF0dGVkIjoiTXMuIEJhcmJhcmEg SiBKZW5zZW4gSUlJIiwgCiAgICAgDQogCiAgICAgICAgICAgImZhbWlseU5hbWUiOiJKZW5zZW4i LCAKICAgICANCiAKICAgICAgICAgICAiZ2l2ZW5OYW1lIjoiQmFyYmFyYSIgCiAgICAgDQogCiAg ICAgICAgIH0gCiAgICAgDQogCiAgICAgICAgICJ1cm46c2NpbTpzY2hlbWFzOmV4dGVuc2lvbjpv dXJwcm9kdWN0bmFtZToxLjAiOnsgCiAgICAgDQogCiAgICAgICAgICAgICAgICAgICAgInVzZXJO YW1lVHlwZSI6ImVtYWlsX2FzX3VzZXJuYW1lIiwgCiAgICAgDQogCiAgICAgICAgIH0gCiAgICAg DQogCiAgICAgICB9IAogICAgIA0KIAogICAgCiAgICAKICAgICAgICAKICAgIA0KIAogICAgQXBw cm9hY2ggMjogZGVmaW5lIHNlcGFyYXRlIGVuZHBvaW50IGZvciBlYWNoIHVzZXJuYW1lIHR5cGU6 IGFuIGVuZHBvaW50IHRvIGNyZWF0ZSBhIHVzZXIgd2lsbCBsb29rIGxpa2U6IGh0dHBzOi8vZXhh bXBsZS5jb20vZW1haWxfYXNfdXNlcm5hbWUvdjEvVXNlcnMgCiAgICANCiAKICAgIAogICAgCiAg ICAgICAgCiAgICANCiAKICAgIEFwcHJvYWNoIDM6IEFzayB0aGUgY2xpZW50IGRldmVsb3BlciB0 byBhcHBlbmQgYSCTdXNlck5hbWVUeXBlPYWUIHBhcmFtZXRlciB0byB0aGUgZW5kIG9mIHRoZSBy ZXF1ZXN0LiAKICAgIA0KIAogICAgCiAgICAKICAgICAgICAKICAgIA0KIAogICAgQ291bGQgeW91 IHBsZWFzZSB0ZWxsIG1lIGlmIGFueSBvZiB0aGUgYXBwcm9hY2hlcyBhYm92ZSBhcmUgU0NJTSBj b21wbGlhbnQgYW5kIHVzYWJsZT8gV2hhdCBhbHRlcm5hdGl2ZXMgZG8gSSBoYXZlPyAKICAgIA0K IAogICAgCiAgICAKICAgICAgICAKICAgIA0KIAogICAgVGhhbmsgeW91IGluIGFkdmFuY2UsIAog ICAgDQogCiAgICBOZ3V5IER1YyBUaHVhbi4gCiAgICANCiAKICAgCiAgDQogCQkgCSAgIAkJICAN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCgpzY2ltIG1haWxpbmcgbGlzdA0KCnNjaW1AaWV0Zi5vcmcNCgpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCgoNCg0KCiAJCSAJICAgCQkg IA== --_04cfbf6a-500e-41e2-a708-94f2e8a2a820_ Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5IGNsYXNzPSdobW1lc3NhZ2UnPjxkaXYgZGly PSdsdHInPgoKPHN0eWxlPjwhLS0KLmhtbWVzc2FnZSBQCnsKbWFyZ2luOjBweDsKcGFkZGluZzow cHgKfQpib2R5LmhtbWVzc2FnZQp7CmZvbnQtc2l6ZTogMTJwdDsKZm9udC1mYW1pbHk6Q2FsaWJy aQp9Ci0tPjwvc3R5bGU+CjxkaXYgZGlyPSJsdHIiPkhpIFNhbXVlbCw8YnI+Tm9wZSwgbm90IGxh dGUgeWV0LiBJJm5ic3A7ZGVsYXllZCB0aGlzIHRhc2smbmJzcDtmb3IgYSB3ZWVrJm5ic3A7YW5k IHBsYW5uZWQgdG8mbmJzcDtzdGFydCBpdCB0b21vcnJvdy4mbmJzcDtCYWNrIHRvIHRvcGljLCBp biB0aGUgd29ybGQgb2YgZmVkZXJhdGVkIGFjY2VzcyBtYW5hZ2VtZW50IHdoZXJlIHdlIG5lZWQg dG8gbWFuYWdlIGlkZW50aXRpZXMgZnJvbSBtdWx0aXBsZSBJZGVudGl0eSBQcm92aWRlcnMsIEkg dGhpbmsgdGhlcmUgYXJlIG90aGVyIHBlb3BsZSB3aG8gbmVlZCB0byBkZWFsIHdpdGggc2ltaWxh ciB1c2UgY2FzZXMuIEknbSBlYWdlciB0byBzZWUgd2hhdCBzb2x1dGlvbnMgdGhleSBjb21lIHVw IHdpdGggdGhleSBzdGFydCB0byBhZG9wdCBTQ0lNLjxicj48YnI+PHAgc3R5bGU9ImZvbnQtZmFt aWx5OiBjYW1icmlhOyI+QmVzdCBSZWdhcmRzLDwvcD48cCBzdHlsZT0iZm9udC1mYW1pbHk6IGNh bWJyaWE7Ij5UaHVhbi48L3A+CjxwIHN0eWxlPSJmb250LWZhbWlseTogY2FtYnJpYTsiPiZuYnNw OzwvcD4KPGJyPiZuYnNwOzxicj48ZGl2PjxociBpZD0ic3RvcFNwZWxsaW5nIj5EYXRlOiBTdW4s IDYgT2N0IDIwMTMgMTk6MDc6MjcgLTA1MDA8YnI+U3ViamVjdDogUmU6IFtzY2ltXSBSZXNlbmQ6 IEhvdyB0byB1c2UgU0NJTSBhZ2FpbnN0IGEgbXVsdGktdXNlcm5hbWUgc3lzdGVtPGJyPkZyb206 IHNhbXVlbEBlcmR0bWFuLnNlPGJyPlRvOiBuZ3V5ZHRodWFuQGhvdG1haWwuY29tPGJyPkNDOiBz Y2ltQGlldGYub3JnPGJyPjxicj48ZGl2IGRpcj0ibHRyIj5IaSBUaHVhbiw8ZGl2Pjxicj48L2Rp dj48ZGl2PkEgYml0IGxhdGUgYnV0IGFueXdheS48L2Rpdj48ZGl2PkludGVyZXN0aW5nIHVzZS1j YXNlLCBJIHRoaW5rIHRoYXQgeW91IHNvbHV0aW9uIHdpdGggdGhlIGV4dGVuc2lvbiBpcyBhIGdv b2Qgd2F5IHRvIGdvIHRvIHNwZWNpZnkgdGhlIGF0dHJpYnV0ZSB0aGF0IHRoZSB1c2VyIHNob3Vs ZCB1c2UgdG8gYXV0aGVudGljYXRlIHdpdGguIE9uZSBjb21tZW50IHRob3VnaCwgSSB3b3VsZCBj cmVhdGUgdGhlIGV4dGVuc2lvbiBsaWtlIHRoaXM6PC9kaXY+CjxkaXY+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSdjb2xvcjogcmdiKDgwLCAwLCA4MCk7IGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXci OyBmb250LXNpemU6IDEycHQ7Jz4idXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246Jmx0O0FkaXRp b25hbCBsb2dpbiBkYXRhJmd0OzoxLjAiOns8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjog cmdiKDgwLCAwLCA4MCk7IGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEy cHQ7Jz4mbmJzcDsgJm5ic3A7InVzZXJOYW1lIjoiJmx0O3NjaW1fYXR0cmlidXRlX25hbWUmZ3Q7 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjogcmdiKDgwLCAwLCA4MCk7IGZvbnQtZmFtaWx5OiAi Q291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4iLDxicj4KPC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjogcmdiKDgwLCAwLCA4MCk7IGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250 LXNpemU6IDEycHQ7Jz59PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgbW9yZSBw ZW9wbGUgaGFzIHRoaXMgcHJvYmxlbSB0aGV5IG1pZ2h0IHdhbnQgdG8gdXNlIHlvdSBleHRlbnNp b24gaWYgaXQgZG9lcyBub3QgY29udGFpbiB5b3UgY29tcGFueSBuYW1lLiBBbmQgaWYgdGhlcmUg aXMgZW5vdWdoIHRyYWN0aW9uIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGluY2x1ZGUgaW4gYSBm dXR1cmUgdmVyc2lvbiBvZiBTQ0lNLjwvZGl2Pgo8ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVyczwv ZGl2PjxkaXY+Ly9TYW11ZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNz PSJlY3hnbWFpbF9leHRyYSI+PGJyPjxicj48ZGl2IGNsYXNzPSJlY3hnbWFpbF9xdW90ZSI+T24g VGh1LCBPY3QgMywgMjAxMyBhdCAyOjQ2IEFNLCBEdWMgVGh1YW4gTmd1eSA8c3BhbiBkaXI9Imx0 ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpuZ3V5ZHRodWFuQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bmd1eWR0aHVhbkBob3RtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+Cjxi bG9ja3F1b3RlIGNsYXNzPSJlY3hnbWFpbF9xdW90ZSIgc3R5bGU9InBhZGRpbmctbGVmdDogMWV4 OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0 aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7Ij4KCgo8ZGl2PjxkaXYgZGlyPSJsdHIi PkhpIEJqb3JuLFRoYW5rIHlvdSB0YWtpbmcgdGltZSB0byByZXBseSBteSBxdWVzdGlvbi4gUGxl YXNlIGxldCBtZSBleHBsYWluIGEgbGl0dGxlIGJpdCBhYm91dCBvdXIgdXNlcm5hbWUgc3lzdGVt LiBJbiBmYWN0LCBub3JtYWwgdXNlcm5hbWUgYW5kIGVtYWlsIGFyZSBvbmx5IHR3byBleGFtcGxl cy4mbmJzcDtPdGhlciBwb3NzaWJpbGl0aWVzIGluY2x1ZGUmbmJzcDtzb2NpYWwgc2VjdXJpdHkg bnVtYmVyLCBvciBhbnkgdXNlci1kZWZpbmVkIHR5cGVzLiBUaGVyZSBpcyBubyBsaW1pdGF0aW9u IHdpdGggcmVnYXJkIHRvIHVzZXJuYW1lIHR5cGVzLjxicj4KJm5ic3A7PGJyPkxvb2tpbmcgYXQg dGhlIHByb2JsZW0gZnJvbSB0aGUgZGF0YWJhc2UgcG9pbnQgb2Ygdmlldywgd2UgZG9uJ3QgaGF2 ZSBhIHNpbmdsZSBjb2x1bW4gdG8gc3RvcmUgdXNlcm5hbWUuIEluc3RlYWQsIGEgdXNlciBoYXMg YSBsaXN0IG9mJm5ic3A7Y2xhaW1zLCZuYnNwO2UuZy46PGJyPiZuYnNwOy0gPGEgaHJlZj0iaHR0 cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvbmFtZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRl bnRpdHkvY2xhaW1zL25hbWU8L2E+PGJyPgombmJzcDstIDxhIGhyZWY9Imh0dHA6Ly9zY2hlbWFz LnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL2VtYWlsYWRkcmVzcyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRp dHkvY2xhaW1zL2VtYWlsYWRkcmVzczwvYT48YnI+Jm5ic3A7LSBnb3Y6c2FtbDphdHRyaWJ1dGU6 U29jaWFsU2VjdXJpdHlOdW1iZXI8YnI+Ci0gLi4uPGJyPkFueSZuYnNwO29mIHRoZW0gY2FuIGJl IHVzZWQgYXMgdXNlcm5hbWUuIE91ciBjbGllbnRzIGNhbiBzZXQgdXAgYSBsb2dpbiBwYWdlIGZv ciBwdWJsaWMgdXNlcnMgdG8gdXNlIE5hbWUgZm9yIHVzZXJuYW1lLCBhbmQgYSBsb2dpbiBwYWdl IGZvciBjb3Jwb3JhdGUgdXNlcnMgdG8gdXNlIGVtYWlsIGFkZHJlc3MgYXMgdXNlcm5hbWUuJm5i c3A7SG93ZXZlciwgd2hlbiBjcmVhdGluZyBhIG5ldyB1c2VyLCAqb25lIGFuZCBvbmx5IG9uZSog dXNlcm5hbWUgdHlwZSBpcyByZXF1aXJlZC48YnI+CiZuYnNwOzxicj5Tbzo8YnI+UTogQXJlIGJv dGggZW1haWwgYW5kIGEgdXNlciBuYW1lIHJlcXVpcmVkIGJ5IHlvdXIgc3lzdGVtIHdoZW4gY3Jl YXRpbmcgYSB1c2VyPyAmbmJzcDsgICA8YnI+IEE6Jm5ic3A7Tm8sIG9ubHkgb25lIGlzIHJlcXVp cmVkLiBBbnkgb2YgdGhlIHVzZXJuYW1lIHR5cGUgaXMgZmluZS48YnI+PGJyPkkgYWdyZWUgd2l0 aCB5b3UgYWJvdXQgIkluIGFsbCBjYXNlcywgYWxsb3dpbmcgdGhlIHVzZXIgdG8gbG9nIGluIHdp dGggZWl0aGVyIG5hbWUgc2hvdWxkIGJlIGRvbmUgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIGxvZ2lj LCBub3QgaW4gdGhlIHByb3Zpc2lvbmluZyBkYXRhIHdoZW4gdGhlIHVzZXIgaXMgY3JlYXRlZC4i IFRoZSBwb2ludCBoZXJlIGlzIHRoYXQgd2hlbiBhIHVzZXIgaXMgY3JlYXRlZCwgSSBuZWVkIHRv IGtub3cgd2hhdCB1c2VybmFtZSB0eXBlIHRvIG1hcCB0aGUgInVzZXJuYW1lIiBzcGVjaWZpZWQg aW4gYW4gU0NJTSByZXF1ZXN0IHRvLjxicj4KPGJyPkFtIEkgcmlnaHQgdGhhdCB5b3VyIHJlcGx5 IG1lYW5zIHVzaW5nIGEgY3VzdG9tIGF0dHJpYnV0ZSBsaWtlcyB0aGUgZm9sbG93aW5nIGlzIHRo ZSBiZXN0IHdheSBJIHNob3VsZCBkbz88YnI+PGRpdiBjbGFzcz0iZWN4aW0iPjxicj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEy cHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInVybjpzY2ltOnNjaGVtYXM6ZXh0ZW5zaW9u Om91cnByb2R1Y3RuYW1lOjEuMCI6eyAgICAgICA8L3NwYW4+PGJyPgo8c3BhbiBsYW5nPSJFTiIg c3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInVzZXJOYW1lVHlwZSI6ImVtYWlsX2FzX3Vz ZXJuYW1lIiwgICAgICAgPC9zcGFuPjxicj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFt aWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7fSA8L3NwYW4+PGJyPgo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAi Q291cmllciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz48L3NwYW4+Jm5ic3A7PGJyPjxicj4mbmJz cDs8YnI+PC9kaXY+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBjYW1icmlhOyI+QmVzdCBSZWdhcmRz LDwvcD4KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBjYW1icmlhOyI+VGh1YW4uPC9wPgombmJzcDs8 ZGl2IGNsYXNzPSJlY3hobSBlY3hIT0VuWmIiPjxicj48L2Rpdj48ZGl2PjxkaXYgY2xhc3M9ImVj eGhtIGVjeEhPRW5aYiI+PGhyPkRhdGU6IFdlZCwgMiBPY3QgMjAxMyAxNzozNDo1MSArMDAwMDxi cj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86Ympvcm4uYWFubmVzdGFkQHVuYm91bmRpZC5jb20iIHRh cmdldD0iX2JsYW5rIj5iam9ybi5hYW5uZXN0YWRAdW5ib3VuZGlkLmNvbTwvYT48YnI+VG86IDxh IGhyZWY9Im1haWx0bzpuZ3V5ZHRodWFuQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmd1 eWR0aHVhbkBob3RtYWlsLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+ClN1YmplY3Q6IFJFOiBbc2NpbV0g UmVzZW5kOiBIb3cgdG8gdXNlIFNDSU0gYWdhaW5zdCBhIG11bHRpLXVzZXJuYW1lIHN5c3RlbTwv ZGl2PjxkaXY+PGRpdiBjbGFzcz0iaDUiPjxicj48YnI+CiAKIAogIFlvdSBjb3VsZCBhZGQgYSBj dXN0b20gYXR0cmlidXRlIGZvciB0aGUgdXNlciBuYW1lIHR5cGUgLSB0aG9zZSBraW5kcyBvZiBl eHRlbnNpb25zIGFyZSBzdXBwb3J0ZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uICZuYnNwO0hvd2V2 ZXIsIEknbSBkbyBub3QgdGhpbmsgbWl4aW5nIHRoZSB0d28gYXR0cmlidXRlIHR5cGVzIGlzIHRo ZSByaWdodCBzb2x1dGlvbi4KICA8YnI+IAogIDxicj4gQXJlIGJvdGggZW1haWwgYW5kIGEgdXNl ciBuYW1lIHJlcXVpcmVkIGJ5IHlvdXIgc3lzdGVtIHdoZW4gY3JlYXRpbmcgYSB1c2VyPyAmbmJz cDsKICA8YnI+IElmIHNvLCBJIHdvdWxkIHJlY29tbWVuZCBzdG9yaW5nIGVhY2ggaW4gdGhlaXIg cmVzcGVjdGl2ZSBwcmVkZWZpbmVkIGF0dHJpYnV0ZXMuICZuYnNwOyZuYnNwOwogIDxicj4gCiAg PGJyPiBJZiBvbmx5IGFuIGVtYWlsIGFkZHJlc3MgaXMgcmVxdWlyZWQgd2hlbiBjcmVhdGluZyBh IHVzZXIsIHdoZW4gdGhhdCBpcyBhbGwgeW91IGhhdmUsIEkgd291bGQgcmVjb21tZW5kIHN0b3Jp bmcgdGhlIGVtYWlsIGluIGJvdGggYXR0cmlidXRlcy4KICA8YnI+IAogIDxicj4gSWYgb25seSBh IHVzZXIgbmFtZSBpcyByZXF1aXJlZCwgYW5kIHRoZSBlbWFpbCBpcyBvcHRpb25hbCwgdGhlbiBv ZiBjb3Vyc2Ugc3RvcmUgdGhlIHVzZXIgbmFtZSBhbmQgbGVhdmUgdGhlIGVtYWlsIGJsYW5rLgog IDxicj4gCiAgPGJyPiBJbiBhbGwgY2FzZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGxvZyBpbiB3 aXRoIGVpdGhlciBuYW1lIHNob3VsZCBiZSBkb25lIGluIHRoZSBhdXRoZW50aWNhdGlvbiBsb2dp Yywgbm90IGluIHRoZSBwcm92aXNpb25pbmcgZGF0YSB3aGVuIHRoZSB1c2VyIGlzIGNyZWF0ZWQu CiAgPGJyPiAKICA8YnI+IC1Cam9ybiBBYW5uZXN0YWQKICA8YnI+IAogIDxicj4gCiAgPGJyPiAK ICA8YnI+IAogIDxicj4gCiAgPGhyPiAKICA8Yj5Gcm9tOjwvYj4gCiAgPGEgaHJlZj0ibWFpbHRv OkR1YytUaHVhbitOZ3V5KyhuZ3V5ZHRodWFuQGhvdG1haWwuY29tKSIgdGFyZ2V0PSJfYmxhbmsi PkR1YyBUaHVhbiBOZ3V5IChuZ3V5ZHRodWFuQGhvdG1haWwuY29tKTwvYT4KICA8YnI+IAogIDxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEsIDIwMTMgMTA6MjggUE0KICA8YnI+IAogIDxi PlRvOjwvYj4gCiAgPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zY2ltQGlldGYub3JnPC9hPgogIDxicj4gCiAgPGI+U3ViamVjdDwvYj46IFtzY2ltXSBSZXNl bmQ6IEhvdyB0byB1c2UgU0NJTSBhZ2FpbnN0IGEgbXVsdGktdXNlcm5hbWUgc3lzdGVtIAogIDxk aXYgc3R5bGU9Im1pbi1oZWlnaHQ6IDVweDsiPgogICAgJm5ic3A7CiAgPC9kaXY+IAogICAKICA8 ZGl2IGRpcj0ibHRyIj4gCiAgICBIaSBTQ0lNIGdyb3VwcywgCiAgICA8YnI+IAogICAgKEkgcmVz ZW5kIHRoaXMgZW1haWwgYmVjYXVzZSBpdCBzZWVtcyB0aGUgZmlyc3Qgb25lIGdvdCBsb3N0IHNv bWV3aGVyZS4gUGVyaGFwcyBpdCBpcyBiZWNhdXNlIEkgc2VudCBpdCBmcm9tIGFub3RoZXIgZW1h aWwgYWNjb3VudCB3aGljaCB3YXNuJ3Qgc3Vic2NyaWJlZCB0byB0aGUgU0NJTSBncm91cC4gVGhp cyBlbWFpbCBhaW1zIHRvIGNvcnJlY3QgdGhhdCBtaXN0YWtlKTxicj4KIAogICAgCiAgICA8YnI+ IAogICAgT3VyIGNvbXBhbnkgd2FudHMgdG8gaW1wbGVtZW50IFNDSU0gMS4xIGZvciBvdXIgaWRl bnRpdHkgbWFuYWdlbWVudCBwcm9kdWN0LiBJIHRoaW5rIFNDSU0gaXMgZ3JlYXQgeWV0IHNpbXBs ZSBmcmFtZXdvcmsgYW5kIGlzIHZlcnkgZWFnZXIgdG8gaW1wbGVtZW50IGl0LiBIb3dldmVyLCBJ IGZpbmQgb25lIHByb2JsZW0gd2hlbiBJIHRyeSB0byBhZG9wdCBTQ0lNIGZvciBvdXIgc3lzdGVt OiBzaW1wbHkgc3BlYWtpbmcsIG91ciBzeXN0ZW0gc3VwcG9ydHMgbXVsdGlwbGUgdXNlcm5hbWVz LiBJbiBvdGhlciB3b3Jkcywgb25lIHVzZXIgY2FuIGhhdmUgbW9yZSB0aGFuIG9uZSB1c2VybmFt ZXMsIGZvciBleGFtcGxlOiAKICAgIDxicj4gCiAgICAKICAgIDxzcGFuPjxzcGFuPi08c3BhbiBz dHlsZT0nZm9udDogN3B0L25vcm1hbCAiVGltZXMgTmV3IFJvbWFuIjsgZm9udC1zaXplLWFkanVz dDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWw7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+IAogICAg VXNlcm5hbWVfYXNfdXNlcm5hbWU6IGJqZW5zZW4uIAogICAgPGJyPiAKICAgIAogICAgPHNwYW4+ PHNwYW4+LTxzcGFuIHN0eWxlPSdmb250OiA3cHQvbm9ybWFsICJUaW1lcyBOZXcgUm9tYW4iOyBm b250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj4gCiAgICBFbWFpbF9hc191c2VybmFtZTogPGZvbnQgY29sb3I9IiMwMDAwZmYiPjxh IGhyZWY9Im1haWx0bzpiamVuc2VuQGV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmplbnNl bkBleGFtcGxlLmNvbTwvYT48L2ZvbnQ+IAogICAgPGJyPiAKICAgIEEgdXNlciBjYW4gdXNlIGFu eSBvZiB0aGUgk3VzZXJuYW1llCB0byBsb2dpbi4gCiAgICA8YnI+IAogICAgCiAgICAKICAgICAg Jm5ic3A7IAogICAgPGJyPiAKICAgIEFzIGEgY29uc2VxdWVudCwgd2hlbiBhIGNyZWF0ZSB1c2Vy IHJlcXVlc3QgbmVlZHMgdG8gc3BlY2lmeSBub3Qgb25seSBhIHVzZXJuYW1lIGJ1dCBhbHNvIHRo ZSB0eXBlIG9mIHRoYXQgdXNlcm5hbWUuIFVuZm9ydHVuYXRlbHksIEkgY291bGRuknQgZmluZCBh bnkgcHJlZGVmaW5lZCBTQ0lNIGF0dHJpYnV0ZSB3aGljaCBjYW4gYmUgdXNlZCBmb3IgdGhhdCCT dHlwZSBvZiB1c2VybmFtZZQuIAogICAgPGJyPiAKICAgIAogICAgCiAgICAgICZuYnNwOyAKICAg IDxicj4gCiAgICBJIGNhbiB0aGluayBvZiBhIGZldyBvcHRpb25zOiAKICAgIDxicj4gCiAgICAK ICAgIAogICAgICAmbmJzcDsgCiAgICA8YnI+IAogICAgQSBzdGFuZGFyZCBTQ0lNIGNyZWF0ZSB1 c2VyIHJlcXVlc3Q6IAogICAgPGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1m YW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyB7IAog ICAgIDwvc3Bhbj48YnI+IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTog IkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICJzY2hlbWFzIjpbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSwgCiAgICAgPC9zcGFuPjxi cj4gCiAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXci OyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInVzZXJOYW1lIjoi YmplbnNlbiIsIAogICAgIDwvc3Bhbj48YnI+IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdm b250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICJleHRlcm5hbElkIjoiYmplbnNlbiIsIAogICAgIDwvc3Bhbj48YnI+IAog ICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9u dC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJuYW1lIjp7IAogICAgIDwv c3Bhbj48YnI+IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJp ZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICJmb3JtYXR0ZWQiOiJNcy4gQmFyYmFyYSBKIEplbnNlbiBJSUkiLCAKICAgICA8L3Nw YW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVy IE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAiZmFtaWx5TmFtZSI6IkplbnNlbiIsIAogICAgIDwvc3Bhbj48YnI+IAogICAgPHNwYW4g bGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAx MnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJnaXZlbk5hbWUiOiJC YXJiYXJhIiAKICAgICA8L3NwYW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9u dC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9IAogICAgIDwvc3Bhbj48YnI+IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxl PSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5i c3A7IH0gCiAgICAgPC9zcGFuPjxicj4gCiAgICAKICAgIAogICAgICAmbmJzcDsgCiAgICA8YnI+ IAogICAgQXBwcm9hY2ggMTogZXh0ZW5kZWQgU0NJTSBjcmVhdGUgdXNlciByZXF1ZXN0OiAKICAg IDxicj4gCiAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBO ZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsgeyAKICAgICA8L3NwYW4+PGJyPiAK ICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZv bnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAic2NoZW1hcyI6WyJ1cm46 c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sIAogICAgIDwvc3Bhbj48YnI+IAogICAgPHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0 Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJ1c2VyTmFtZSI6ImJqZW5zZW4iLCAKICAgICA8 L3NwYW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3Vy aWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZXh0 ZXJuYWxJZCI6ImJqZW5zZW4iLCAKICAgICA8L3NwYW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVO IiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAibmFtZSI6eyAKICAgICA8L3NwYW4+PGJyPiAKICAgIDxz cGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6 ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZm9ybWF0dGVk IjoiTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJIiwgCiAgICAgPC9zcGFuPjxicj4gCiAgICA8c3Bh biBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciOyBmb250LXNpemU6 IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImZhbWlseU5hbWUi OiJKZW5zZW4iLCAKICAgICA8L3NwYW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0n Zm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZ2l2ZW5OYW1lIjoiQmFyYmFyYSIgCiAgICAgPC9z cGFuPjxicj4gCiAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmll ciBOZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSAKICAg ICA8L3NwYW4+PGJyPiAKICAgIDxzcGFuIGxhbmc9IkVOIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJD b3VyaWVyIE5ldyI7IGZvbnQtc2l6ZTogMTJwdDsnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAi dXJuOnNjaW06c2NoZW1hczpleHRlbnNpb246b3VycHJvZHVjdG5hbWU6MS4wIjp7IAogICAgIDwv c3Bhbj48YnI+IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJp ZXIgTmV3IjsgZm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICJ1c2VyTmFtZVR5cGUiOiJlbWFpbF9hc191c2VybmFtZSIsIAogICAgIDwvc3Bhbj48YnI+ IAogICAgPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSdmb250LWZhbWlseTogIkNvdXJpZXIgTmV3Ijsg Zm9udC1zaXplOiAxMnB0Oyc+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO30gCiAgICAgPC9zcGFu Pjxicj4gCiAgICA8c3BhbiBsYW5nPSJFTiIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ291cmllciBO ZXciOyBmb250LXNpemU6IDEycHQ7Jz4mbmJzcDsmbmJzcDsgfSAKICAgICA8L3NwYW4+PGJyPiAK ICAgIAogICAgCiAgICAgICZuYnNwOyAKICAgIDxicj4gCiAgICBBcHByb2FjaCAyOiBkZWZpbmUg c2VwYXJhdGUgZW5kcG9pbnQgZm9yIGVhY2ggdXNlcm5hbWUgdHlwZTogYW4gZW5kcG9pbnQgdG8g Y3JlYXRlIGEgdXNlciB3aWxsIGxvb2sgbGlrZTogPGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNv bS9lbWFpbF9hc191c2VybmFtZS92MS9Vc2VycyIgdGFyZ2V0PSJfYmxhbmsiPjxmb250IGNvbG9y PSIjMDAwMGZmIj5odHRwczovL2V4YW1wbGUuY29tL2VtYWlsX2FzX3VzZXJuYW1lL3YxL1VzZXJz PC9mb250PjwvYT4gCiAgICA8YnI+IAogICAgCiAgICAKICAgICAgJm5ic3A7IAogICAgPGJyPiAK ICAgIEFwcHJvYWNoIDM6IEFzayB0aGUgY2xpZW50IGRldmVsb3BlciB0byBhcHBlbmQgYSCTdXNl ck5hbWVUeXBlPYWUIHBhcmFtZXRlciB0byB0aGUgZW5kIG9mIHRoZSByZXF1ZXN0LiAKICAgIDxi cj4gCiAgICAKICAgIAogICAgICAmbmJzcDsgCiAgICA8YnI+IAogICAgQ291bGQgeW91IHBsZWFz ZSB0ZWxsIG1lIGlmIGFueSBvZiB0aGUgYXBwcm9hY2hlcyBhYm92ZSBhcmUgU0NJTSBjb21wbGlh bnQgYW5kIHVzYWJsZT8gV2hhdCBhbHRlcm5hdGl2ZXMgZG8gSSBoYXZlPyAKICAgIDxicj4gCiAg ICAKICAgIAogICAgICAmbmJzcDsgCiAgICA8YnI+IAogICAgVGhhbmsgeW91IGluIGFkdmFuY2Us IAogICAgPGJyPiAKICAgIE5ndXkgRHVjIFRodWFuLiAKICAgIDxicj4gCiAgPC9kaXY+IAogIDxi cj48L2Rpdj48L2Rpdj48L2Rpdj4gCQkgCSAgIAkJICA8YnI+PGJyPjxicj48YnI+PGJyPjxicj48 YnI+PGJyPjxicj48YnI+PGJyPjwvZGl2PjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CnNjaW0gbWFpbGluZyBsaXN0PGJyPgo8YSBo cmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48YnI+Cjxi cj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjwvZGl2PgogCQkgCSAgIAkJICA8 L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_04cfbf6a-500e-41e2-a708-94f2e8a2a820_-- From swm16@psu.edu Tue Oct 8 08:17:54 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328F021E81A2 for ; Tue, 8 Oct 2013 08:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfGQ9fXUZdOp for ; Tue, 8 Oct 2013 08:17:34 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65821E80AC for ; Tue, 8 Oct 2013 08:17:29 -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 r98FHSIW3666046 for ; Tue, 8 Oct 2013 11:17:28 -0400 Date: Tue, 8 Oct 2013 11:17:28 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <1315462510.609258.1381245448040.JavaMail.zimbra@psu.edu> In-Reply-To: <1277255486.499169.1381242489408.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: Filter ambiguity Thread-Index: ZdYX5SURDCjdOGRENL6XnD/FW5moUA== X-Virus-Scanned: by amavisd-new Subject: [scim] Filter ambiguity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 15:17:54 -0000 I've got a working lexer/parser (with a couple minor problems) to convert the SCIM filter syntax into an expression tree, and now that I'm using it to generate queries, I've noticed that there are ambiguities that will affect what's returned by the back-end. Our back-end is LDAP-based (which includes other problems) but I'll describe the issue I'm seeing using SQL since I think it's a clearer way to describe the problem. This ambiguity can occur for any multi-valued attribute, but it will be most severe for the address object. Given a user smoyer with a work e-mail address of smoyer@psu.edu and a home e-mail address of smoyer1@selesy.com, the following SCIM filter: emails.type eq "work" and emails.value eq "smoyer1@selesy.com" would return the user smoyer as a result. If I was writing this filter, it would be my intention that only users with an e-mail address type of work AND with the value smoyer@psu.edu should be returned. An SQL statement that shows what I believe would be a common case is: select user.* from user u, email e where u.userName = e.userName and e.type = 'work' and e.value = 'smoyer1@selesy.com'; would not return the user smoyer. In fact, the behavior the SCIM filter implies would require an intersection as follows: (select user.* from user u, email e where u.userName = e.userName and e.type = 'work') intersect (select user.* from user u, email e where u.userName = e.userName and e.value = 'smoyer1@selesy.com') In thinking through solutions to searches including multi-valued attributes, the only reasonable solution I've come up with is that when fields of a multi-valued attribute are specified, we implicitly agree that they're supposed to be ANDed together within the same object. Am I missing anything? (And did I explain the problem correctly?). Please help me clarify how to address these searches. Steve From phil.hunt@oracle.com Tue Oct 8 08:26:26 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8621E80AC for ; Tue, 8 Oct 2013 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5 tests=[AWL=-2.197, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKn0ShGDhWCR for ; Tue, 8 Oct 2013 08:26:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1121E80AA for ; Tue, 8 Oct 2013 08:26:20 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r98FQJFB022579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 15:26:20 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 r98FQIsQ013104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 15:26:18 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98FQIho019123; Tue, 8 Oct 2013 15:26:18 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Oct 2013 08:26:17 -0700 References: <1315462510.609258.1381245448040.JavaMail.zimbra@psu.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <1315462510.609258.1381245448040.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3D011D34-A9A9-45FA-9791-1D8FC7CA39D1@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Tue, 8 Oct 2013 08:26:15 -0700 To: Steve Moyer X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" Subject: Re: [scim] Filter ambiguity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:26:26 -0000 Yes you are right.=20 Another problem is that a filter is for a record match and not a multi value= match.=20 It seems there are times when you just want the single matched value returne= d rather than all values (which would be the correct interpretation).=20 I wonder if there are any rest examples out there? Phil > On Oct 8, 2013, at 8:17, Steve Moyer wrote: >=20 > I've got a working lexer/parser (with a couple minor problems) to convert t= he SCIM filter syntax into an expression tree, and now that I'm using it to g= enerate queries, I've noticed that there are ambiguities that will affect wh= at's returned by the back-end. Our back-end is LDAP-based (which includes o= ther problems) but I'll describe the issue I'm seeing using SQL since I thin= k it's a clearer way to describe the problem. This ambiguity can occur for a= ny multi-valued attribute, but it will be most severe for the address object= . >=20 > Given a user smoyer with a work e-mail address of smoyer@psu.edu and a hom= e e-mail address of smoyer1@selesy.com, the following SCIM filter: >=20 > emails.type eq "work" and emails.value eq "smoyer1@selesy.com" >=20 > would return the user smoyer as a result. >=20 > If I was writing this filter, it would be my intention that only users wit= h an e-mail address type of work AND with the value smoyer@psu.edu should be= returned. >=20 > An SQL statement that shows what I believe would be a common case is: >=20 > select user.* from user u, email e where u.userName =3D e.userName and e.t= ype =3D 'work' and e.value =3D 'smoyer1@selesy.com'; >=20 > would not return the user smoyer. In fact, the behavior the SCIM filter i= mplies would require an intersection as follows: >=20 > (select user.* from user u, email e where u.userName =3D e.userName and e.= type =3D 'work') intersect (select user.* from user u, email e where u.userN= ame =3D e.userName and e.value =3D 'smoyer1@selesy.com') >=20 > In thinking through solutions to searches including multi-valued attribute= s, the only reasonable solution I've come up with is that when fields of a m= ulti-valued attribute are specified, we implicitly agree that they're suppos= ed to be ANDed together within the same object. >=20 > Am I missing anything? (And did I explain the problem correctly?). Pleas= e help me clarify how to address these searches. >=20 > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Tue Oct 8 08:32:11 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5780021E81F1 for ; Tue, 8 Oct 2013 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5fGFUUgwNEP for ; Tue, 8 Oct 2013 08:32:05 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id F0E9921E80F0 for ; Tue, 8 Oct 2013 08:32:04 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r98FVY601642652; Tue, 8 Oct 2013 11:31:34 -0400 Date: Tue, 8 Oct 2013 11:31:34 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> In-Reply-To: <1552691527.625348.1381245932930.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: #45: LDAP mapping Thread-Index: ALXYA2dDe9yuS9r35maDoqNO1MKaLA== X-Virus-Scanned: by amavisd-new Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 15:32:11 -0000 Peter et al, There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping). Since we've been through some of that pain, would it make sense to collaborate on creating this mapping? Steve From phil.hunt@oracle.com Tue Oct 8 08:35:23 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47C021E81C0 for ; Tue, 8 Oct 2013 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZXUivl-dkY1 for ; Tue, 8 Oct 2013 08:35:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6729D21E81A2 for ; Tue, 8 Oct 2013 08:35:13 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r98FZCL6001822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 15:35:12 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98FZBqJ011638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 15:35:11 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98FZBsm029861; Tue, 8 Oct 2013 15:35:11 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Oct 2013 08:35:10 -0700 References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <67923AC2-2332-4E3D-8A19-6C06B0808EB6@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Tue, 8 Oct 2013 08:35:10 -0700 To: Steve Moyer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:35:23 -0000 If you look at my scim directory draft you are welcome to use the mapping th= ere.=20 Phil > On Oct 8, 2013, at 8:31, Steve Moyer wrote: >=20 > Peter et al, >=20 > There are a couple of us on the list who have preliminary mappings between= SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: L= DAP mapping). Since we've been through some of that pain, would it make sen= se to collaborate on creating this mapping? >=20 > Steve >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From peter.gietz@daasi.de Tue Oct 8 09:06:34 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9A21E8245 for ; Tue, 8 Oct 2013 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNKSnpJbT0z7 for ; Tue, 8 Oct 2013 09:06:30 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E721E8219 for ; Tue, 8 Oct 2013 09:04:09 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 6F075400720; Tue, 8 Oct 2013 18:03:56 +0200 (CEST) Received: from [192.168.100.210] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 8539B4003BC; Tue, 8 Oct 2013 18:03:55 +0200 (CEST) Message-ID: <52542CEA.2010103@daasi.de> Date: Tue, 08 Oct 2013 18:03:54 +0200 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Steve Moyer References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> In-Reply-To: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: scim@ietf.org, Phil Hunt Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:06:34 -0000 Hi Steve, Thanks a lot for this which sort of comes just in time, since working on that is on the agenda for this week. Of course it will make sense to collaborate on this. How should we start that. Shall I do a first draft, which uses part of Phil's document, and you will comment on it, or do you also have something already on which we can build on? We also will have to be clear about the scope of the document. I would prefer first to do a schema only document and leave other scim-directory things to a second document, which could reuse other parts of Phil's document but which also could include a LDAP Error to HTTP error mapping. @Steve, Phil, all: Does this make sense to you? Peter Am 08.10.2013 17:31, schrieb Steve Moyer: > Peter et al, > > There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping). Since we've been through some of that pain, would it make sense to collaborate on creating this mapping? > > Steve > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From phil.hunt@oracle.com Tue Oct 8 09:33:15 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F8121E8269 for ; Tue, 8 Oct 2013 09:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyJTXmo8s9-A for ; Tue, 8 Oct 2013 09:33:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BEF1821E81C6 for ; Tue, 8 Oct 2013 09:33:08 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r98GX4Ps005178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 16:33:05 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98GX3jd024070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 16:33:03 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98GX22r016723; Tue, 8 Oct 2013 16:33:02 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Oct 2013 09:33:02 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <52542CEA.2010103@daasi.de> Date: Tue, 8 Oct 2013 09:33:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> To: Peter Gietz X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim@ietf.org, Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:33:15 -0000 Peter, I think we need to talk through the use cases for LDAP mapping. The reason that this is important, is I hear a lot of people saying "why = can't I simply implement a SCIM API on top of my LDAP server?". Without = bi-directional mapping, you can't make a SCIM server based on an LDAP = platform. This is an important limitation to understand. The reason I = wrote the directory draft was to point out you have to move to an = underlying data model that supports complex attributes (a SCIM = Directory). Once you have that, it becomes possible to provide LDAP on = top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP = Directory. Keeping in mind that our WG focus is actually "provisioning" and not = "directory services", it is however possible to support LDAP in a = provisioning only way: 1. As an endpoint, where a SCIM centric entity pushes provisioning = requests to an LDAP endpoint. 2. Where a directory is used to push "limited" attributes to a SCIM SP. These can only work as long as the client does not expect = read-after-write to produce the same JSON. The challenge for such a mapping is the amount of variability that = results, particularly with dealing with how to handle = mullti-valued/typed data. This generates per-deployment and = per-transaction variability that causes errors. For example what should = a server do when a multi-value type appears which has no mapping (which = is static)? For example, a mapping for home address and work address is = defined, but what happens when "other" address value appears? If we could talk through the use cases, we may be able to come up with a = document structure that works (which might well be what you propose). Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-08, at 9:03 AM, Peter Gietz wrote: > Hi Steve, >=20 > Thanks a lot for this which sort of comes just in time, since working = on > that is on the agenda for this week. >=20 > Of course it will make sense to collaborate on this. How should we = start > that. Shall I do a first draft, which uses part of Phil's document, = and > you will comment on it, or do you also have something already on which > we can build on? >=20 > We also will have to be clear about the scope of the document. I would > prefer first to do a schema only document and leave other = scim-directory > things to a second document, which could reuse other parts of Phil's > document but which also could include a LDAP Error to HTTP error = mapping. >=20 > @Steve, Phil, all: Does this make sense to you? >=20 > Peter >=20 > Am 08.10.2013 17:31, schrieb Steve Moyer: >> Peter et al, >>=20 >> There are a couple of us on the list who have preliminary mappings = between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: = [scim] #45: LDAP mapping). Since we've been through some of that pain, = would it make sense to collaborate on creating this mapping? >>=20 >> Steve >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=FCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=FCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=E4ftsleitung: Peter Gietz >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From peter.gietz@daasi.de Tue Oct 8 09:39:03 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2924821E80AA for ; Tue, 8 Oct 2013 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9e01AWP2hfi for ; Tue, 8 Oct 2013 09:38:57 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7807121E8252 for ; Tue, 8 Oct 2013 09:38:55 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 4F513400720; Tue, 8 Oct 2013 18:38:53 +0200 (CEST) Received: from [192.168.100.210] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 42BF34003BC; Tue, 8 Oct 2013 18:38:53 +0200 (CEST) Message-ID: <5254351C.2060005@daasi.de> Date: Tue, 08 Oct 2013 18:38:52 +0200 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Phil Hunt References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: scim@ietf.org, Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:39:03 -0000 Am 08.10.2013 18:33, schrieb Phil Hunt: > Peter, > > I think we need to talk through the use cases for LDAP mapping. Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of the next scim telcos? Cheers, Peter > > The reason that this is important, is I hear a lot of people saying "why can't I simply implement a SCIM API on top of my LDAP server?". Without bi-directional mapping, you can't make a SCIM server based on an LDAP platform. This is an important limitation to understand. The reason I wrote the directory draft was to point out you have to move to an underlying data model that supports complex attributes (a SCIM Directory). Once you have that, it becomes possible to provide LDAP on top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP Directory. > > Keeping in mind that our WG focus is actually "provisioning" and not "directory services", it is however possible to support LDAP in a provisioning only way: > > 1. As an endpoint, where a SCIM centric entity pushes provisioning requests to an LDAP endpoint. > 2. Where a directory is used to push "limited" attributes to a SCIM SP. > > These can only work as long as the client does not expect read-after-write to produce the same JSON. > > The challenge for such a mapping is the amount of variability that results, particularly with dealing with how to handle mullti-valued/typed data. This generates per-deployment and per-transaction variability that causes errors. For example what should a server do when a multi-value type appears which has no mapping (which is static)? For example, a mapping for home address and work address is defined, but what happens when "other" address value appears? > > If we could talk through the use cases, we may be able to come up with a document structure that works (which might well be what you propose). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2013-10-08, at 9:03 AM, Peter Gietz wrote: > >> Hi Steve, >> >> Thanks a lot for this which sort of comes just in time, since working on >> that is on the agenda for this week. >> >> Of course it will make sense to collaborate on this. How should we start >> that. Shall I do a first draft, which uses part of Phil's document, and >> you will comment on it, or do you also have something already on which >> we can build on? >> >> We also will have to be clear about the scope of the document. I would >> prefer first to do a schema only document and leave other scim-directory >> things to a second document, which could reuse other parts of Phil's >> document but which also could include a LDAP Error to HTTP error mapping. >> >> @Steve, Phil, all: Does this make sense to you? >> >> Peter >> >> Am 08.10.2013 17:31, schrieb Steve Moyer: >>> Peter et al, >>> >>> There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping). Since we've been through some of that pain, would it make sense to collaborate on creating this mapping? >>> >>> Steve >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> >> -- >> >> Peter Gietz, CEO >> >> DAASI International GmbH >> Europaplatz 3 >> D-72072 Tübingen >> Germany >> >> phone: +49 7071 407109-0 >> fax: +49 7071 407109-9 >> email: peter.gietz@daasi.de >> web: www.daasi.de >> >> Sitz der Gesellschaft: Tübingen >> Registergericht: Amtsgericht Stuttgart, HRB 382175 >> Geschäftsleitung: Peter Gietz >> >> >> _______________________________________________ >> 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 -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From phil.hunt@oracle.com Tue Oct 8 09:53:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344A321E823C for ; Tue, 8 Oct 2013 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KperCDm5vHKu for ; Tue, 8 Oct 2013 09:53:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EDEA721E8276 for ; Tue, 8 Oct 2013 09:52:55 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r98GqpPg025958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 16:52:52 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 r98GqpIV004666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 16:52:51 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98Gqoc4015560; Tue, 8 Oct 2013 16:52:50 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Oct 2013 09:52:50 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5254351C.2060005@daasi.de> Date: Tue, 8 Oct 2013 09:52:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC5EC3E-6770-4BEA-99E5-185A6E6CB142@oracle.com> References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> To: Peter Gietz X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org, Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:53:09 -0000 I think we should start on this list. The first question to ask is which use-case solution does the WG expect: 1. SCIM on a LDAP Directory (in order to have a single identity store), 2. LDAP as a SCIM provisioning endpoint", or 3. LDAP on a SCIM Directory (in order to have a single identity store)? I think once we have consensus on the above, our efforts will be much = more scoped for the actual mapping. =20 I think 2 and 3 are possible, but not 1. FWIW, it goes without saying = that 2 is technically what is in the WG mandate. I mention the others, = because people keep talking about #1 as it seems the least disruptive = approach to SCIM adoption (which it isn't). After that, we could start the list and get the chairs to book a = separate call (there is a mandatory announcement period these days I = think). Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-08, at 9:38 AM, Peter Gietz wrote: > Am 08.10.2013 18:33, schrieb Phil Hunt: >> Peter, >>=20 >> I think we need to talk through the use cases for LDAP mapping. >=20 > Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of > the next scim telcos? >=20 > Cheers, >=20 > Peter >=20 >=20 >>=20 >> The reason that this is important, is I hear a lot of people saying = "why can't I simply implement a SCIM API on top of my LDAP server?". = Without bi-directional mapping, you can't make a SCIM server based on an = LDAP platform. This is an important limitation to understand. The = reason I wrote the directory draft was to point out you have to move to = an underlying data model that supports complex attributes (a SCIM = Directory). Once you have that, it becomes possible to provide LDAP on = top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP = Directory. >>=20 >> Keeping in mind that our WG focus is actually "provisioning" and not = "directory services", it is however possible to support LDAP in a = provisioning only way: >>=20 >> 1. As an endpoint, where a SCIM centric entity pushes provisioning = requests to an LDAP endpoint. >> 2. Where a directory is used to push "limited" attributes to a SCIM = SP. >>=20 >> These can only work as long as the client does not expect = read-after-write to produce the same JSON. >>=20 >> The challenge for such a mapping is the amount of variability that = results, particularly with dealing with how to handle = mullti-valued/typed data. This generates per-deployment and = per-transaction variability that causes errors. For example what should = a server do when a multi-value type appears which has no mapping (which = is static)? For example, a mapping for home address and work address is = defined, but what happens when "other" address value appears? >>=20 >> If we could talk through the use cases, we may be able to come up = with a document structure that works (which might well be what you = propose). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>=20 >>> Hi Steve, >>>=20 >>> Thanks a lot for this which sort of comes just in time, since = working on >>> that is on the agenda for this week. >>>=20 >>> Of course it will make sense to collaborate on this. How should we = start >>> that. Shall I do a first draft, which uses part of Phil's document, = and >>> you will comment on it, or do you also have something already on = which >>> we can build on? >>>=20 >>> We also will have to be clear about the scope of the document. I = would >>> prefer first to do a schema only document and leave other = scim-directory >>> things to a second document, which could reuse other parts of Phil's >>> document but which also could include a LDAP Error to HTTP error = mapping. >>>=20 >>> @Steve, Phil, all: Does this make sense to you? >>>=20 >>> Peter >>>=20 >>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>> Peter et al, >>>>=20 >>>> There are a couple of us on the list who have preliminary mappings = between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: = [scim] #45: LDAP mapping). Since we've been through some of that pain, = would it make sense to collaborate on creating this mapping? >>>>=20 >>>> Steve >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> --=20 >>>=20 >>> Peter Gietz, CEO >>>=20 >>> DAASI International GmbH =20 >>> Europaplatz 3 =20 >>> D-72072 T=FCbingen =20 >>> Germany =20 >>>=20 >>> phone: +49 7071 407109-0 >>> fax: +49 7071 407109-9 =20 >>> email: peter.gietz@daasi.de >>> web: www.daasi.de >>>=20 >>> Sitz der Gesellschaft: T=FCbingen >>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>> Gesch=E4ftsleitung: Peter Gietz >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=FCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=FCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=E4ftsleitung: Peter Gietz >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Tue Oct 8 10:39:27 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8F21E826C for ; Tue, 8 Oct 2013 10:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsvCRnfY7j6k for ; Tue, 8 Oct 2013 10:39:23 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2E21E80AD for ; Tue, 8 Oct 2013 10:39: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 r98HdAuh1896552; Tue, 8 Oct 2013 13:39:10 -0400 Date: Tue, 8 Oct 2013 13:39:10 -0400 (EDT) From: Steve Moyer To: Peter Gietz Message-ID: <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> In-Reply-To: <5254351C.2060005@daasi.de> References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> 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.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: #45: LDAP mapping Thread-Index: 3Hhc2oVwBZB0hmhgB6BKTo8Au1pEIw== X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org, Phil Hunt Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 17:39:27 -0000 I agree with both of you (aren't I just diplomatic today), the business log= ic for translating a SCIM user to an inetOrgPerson and back is important, a= nd the other thread I started today (Filter ambiguity) will be impacted by = both the LDAP mapping and the business rules for the resources being mapped= . For the mapping itself, I'd agree that we should start with the table Ph= il has provided in section 2.2.3.4. (Attribute Name Mapping). The only err= or I see in that table is that region is not a synonym for locality and sho= uld be address.region and mapped to the LDAP "st" attribute. There are som= e other attributes that aren't mapped the same way we're doing things, but = that's why I restarted the discussion! I'm actually more concerned (at this point) with how to store the "type" an= d "primary flag" for each multi-valued attribute, and how to guarantee the = correct ordering of attributes that make up an address (so that the proper = parts are kept together). LDAP doesn't natively guarantee the storage orde= r of attributes or even that the returned order matches the insertion order= . We're using the proposed specification for "Ordered Entries and Values i= n LDAP" (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep thi= ngs aligned. In our current system, we're using the postalAddress to store= the "type" and "primary flag" along with the formatted value (yes, this br= eaks LDAP clients in some cases, but our intention is to move people away f= rom direct LDAP access and onto the SCIM RESTful services. I'd be happy to work with you in whatever manner seems easiest ... We have = custom user extensions that we know won't match the group's consensus for L= DAP mapping, but we'd like to migrate the attributes that make sense to be = compatible. Steve P.S. For those following along, Phil's document is here: https://www.ietf.= org/id/draft-hunt-scim-directory-01.txt ----- Original Message ----- From: "Peter Gietz" To: "Phil Hunt" Cc: scim@ietf.org, "Steve Moyer" Sent: Tuesday, October 8, 2013 12:38:52 PM Subject: Re: [scim] #45: LDAP mapping Am 08.10.2013 18:33, schrieb Phil Hunt: > Peter, > > I think we need to talk through the use cases for LDAP mapping. Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of the next scim telcos? Cheers, Peter > > The reason that this is important, is I hear a lot of people saying "why = can't I simply implement a SCIM API on top of my LDAP server?". Without bi= -directional mapping, you can't make a SCIM server based on an LDAP platfor= m. This is an important limitation to understand. The reason I wrote the = directory draft was to point out you have to move to an underlying data mod= el that supports complex attributes (a SCIM Directory). Once you have that= , it becomes possible to provide LDAP on top of a SCIM Directory rather the= n a SCIM API sitting on top of an LDAP Directory. > > Keeping in mind that our WG focus is actually "provisioning" and not "dir= ectory services", it is however possible to support LDAP in a provisioning = only way: > > 1. As an endpoint, where a SCIM centric entity pushes provisioning reque= sts to an LDAP endpoint. > 2. Where a directory is used to push "limited" attributes to a SCIM SP. > > These can only work as long as the client does not expect read-after-writ= e to produce the same JSON. > > The challenge for such a mapping is the amount of variability that result= s, particularly with dealing with how to handle mullti-valued/typed data. = This generates per-deployment and per-transaction variability that causes e= rrors. For example what should a server do when a multi-value type appears = which has no mapping (which is static)? For example, a mapping for home ad= dress and work address is defined, but what happens when "other" address va= lue appears? > > If we could talk through the use cases, we may be able to come up with a = document structure that works (which might well be what you propose). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2013-10-08, at 9:03 AM, Peter Gietz wrote: > >> Hi Steve, >> >> Thanks a lot for this which sort of comes just in time, since working on >> that is on the agenda for this week. >> >> Of course it will make sense to collaborate on this. How should we start >> that. Shall I do a first draft, which uses part of Phil's document, and >> you will comment on it, or do you also have something already on which >> we can build on? >> >> We also will have to be clear about the scope of the document. I would >> prefer first to do a schema only document and leave other scim-directory >> things to a second document, which could reuse other parts of Phil's >> document but which also could include a LDAP Error to HTTP error mapping= . >> >> @Steve, Phil, all: Does this make sense to you? >> >> Peter >> >> Am 08.10.2013 17:31, schrieb Steve Moyer: >>> Peter et al, >>> >>> There are a couple of us on the list who have preliminary mappings betw= een SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #= 45: LDAP mapping). Since we've been through some of that pain, would it ma= ke sense to collaborate on creating this mapping? >>> >>> Steve >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> >> --=20 >> >> Peter Gietz, CEO >> >> DAASI International GmbH =20 >> Europaplatz 3 =20 >> D-72072 T=C3=BCbingen =20 >> Germany =20 >> >> phone: +49 7071 407109-0 >> fax: +49 7071 407109-9 =20 >> email: peter.gietz@daasi.de >> web: www.daasi.de >> >> Sitz der Gesellschaft: T=C3=BCbingen >> Registergericht: Amtsgericht Stuttgart, HRB 382175 >> Gesch=C3=A4ftsleitung: Peter Gietz >> >> >> _______________________________________________ >> 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 Peter Gietz, CEO DAASI International GmbH =20 Europaplatz 3 =20 D-72072 T=C3=BCbingen =20 Germany =20 phone: +49 7071 407109-0 fax: +49 7071 407109-9 =20 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: T=C3=BCbingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Gesch=C3=A4ftsleitung: Peter Gietz From kelly.grizzle@sailpoint.com Tue Oct 8 10:46:11 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C575E11E810C for ; Tue, 8 Oct 2013 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXDCsT8V+GTW for ; Tue, 8 Oct 2013 10:46:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9FF11E81B5 for ; Tue, 8 Oct 2013 10:45:59 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 17:45:57 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) with mapi id 15.00.0775.005; Tue, 8 Oct 2013 17:45:57 +0000 From: Kelly Grizzle To: Phil Hunt , Steve Moyer Thread-Topic: [scim] Filter ambiguity Thread-Index: Ac7ETj2H8WOZZsCQRxqHlWWb+mIoog== Date: Tue, 8 Oct 2013 17:45:56 +0000 Message-ID: References: <1315462510.609258.1381245448040.JavaMail.zimbra@psu.edu> <3D011D34-A9A9-45FA-9791-1D8FC7CA39D1@oracle.com> In-Reply-To: <3D011D34-A9A9-45FA-9791-1D8FC7CA39D1@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 429CAF9D0056B8429CB0EA x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(53474002)(377454003)(54094003)(189002)(199002)(24454002)(13464003)(52044002)(74706001)(46102001)(59766001)(77982001)(51856001)(56776001)(54316002)(74366001)(74316001)(83322001)(19580405001)(19580395003)(15975445006)(74876001)(47976001)(50986001)(4396001)(49866001)(47736001)(83072001)(69226001)(33646001)(81342001)(63696002)(85306002)(77096001)(56816003)(80022001)(65816001)(76796001)(76576001)(15202345003)(76786001)(79102001)(81686001)(76482001)(81816001)(80976001)(31966008)(74502001)(81542001)(74662001)(47446002)(53806001)(54356001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Filter ambiguity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:46:14 -0000 Steve, You're actually referring to the exact same problem that ticket #50 is tryi= ng to address - http://tools.ietf.org/wg/scim/trac/ticket/50. I believe th= at this is going to be discussed on the next concall, but feel free to star= t a discussion here. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Tuesday, October 08, 2013 10:26 AM To: Steve Moyer Cc: scim@ietf.org Subject: Re: [scim] Filter ambiguity Yes you are right.=20 Another problem is that a filter is for a record match and not a multi valu= e match.=20 It seems there are times when you just want the single matched value return= ed rather than all values (which would be the correct interpretation).=20 I wonder if there are any rest examples out there? Phil > On Oct 8, 2013, at 8:17, Steve Moyer wrote: >=20 > I've got a working lexer/parser (with a couple minor problems) to convert= the SCIM filter syntax into an expression tree, and now that I'm using it = to generate queries, I've noticed that there are ambiguities that will affe= ct what's returned by the back-end. Our back-end is LDAP-based (which incl= udes other problems) but I'll describe the issue I'm seeing using SQL since= I think it's a clearer way to describe the problem. This ambiguity can oc= cur for any multi-valued attribute, but it will be most severe for the addr= ess object. >=20 > Given a user smoyer with a work e-mail address of smoyer@psu.edu and a ho= me e-mail address of smoyer1@selesy.com, the following SCIM filter: >=20 > emails.type eq "work" and emails.value eq "smoyer1@selesy.com" >=20 > would return the user smoyer as a result. >=20 > If I was writing this filter, it would be my intention that only users wi= th an e-mail address type of work AND with the value smoyer@psu.edu should = be returned. >=20 > An SQL statement that shows what I believe would be a common case is: >=20 > select user.* from user u, email e where u.userName =3D e.userName and e.= type =3D 'work' and e.value =3D 'smoyer1@selesy.com'; >=20 > would not return the user smoyer. In fact, the behavior the SCIM filter = implies would require an intersection as follows: >=20 > (select user.* from user u, email e where u.userName =3D e.userName and e= .type =3D 'work') intersect (select user.* from user u, email e where u.use= rName =3D e.userName and e.value =3D 'smoyer1@selesy.com') >=20 > In thinking through solutions to searches including multi-valued attribut= es, the only reasonable solution I've come up with is that when fields of a= multi-valued attribute are specified, we implicitly agree that they're sup= posed to be ANDed together within the same object. >=20 > Am I missing anything? (And did I explain the problem correctly?). Plea= se help me clarify how to address these searches. >=20 > Steve > _______________________________________________ > 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 kelly.grizzle@sailpoint.com Tue Oct 8 10:50:13 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D443F11E80F8 for ; Tue, 8 Oct 2013 10:50:12 -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=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfwspyDenKkH for ; Tue, 8 Oct 2013 10:50:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0615911E81C3 for ; Tue, 8 Oct 2013 10:50:03 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 8 Oct 2013 17:50:00 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.9.199]) with mapi id 15.00.0775.005; Tue, 8 Oct 2013 17:50:00 +0000 From: Kelly Grizzle To: Steve Moyer , Peter Gietz , "Bjorn Aannestad (bjorn.aannestad@unboundid.com)" Thread-Topic: #45: LDAP mapping Thread-Index: AQHOxE1bbdSvDBlsZEeBbDZVBveleJnrFJfg Date: Tue, 8 Oct 2013 17:50:00 +0000 Message-ID: <8a93f1a1e9e44aa69418a927e1b5d313@BN1PR04MB392.namprd04.prod.outlook.com> References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> In-Reply-To: <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 42A0648A0056B842A065D7 x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(51704005)(252514010)(13464003)(13604004)(377424004)(199002)(189002)(24454002)(15975445006)(77096001)(63696002)(69226001)(81342001)(81542001)(76796001)(76576001)(81686001)(74706001)(76786001)(81816001)(56816003)(74876001)(74662001)(47446002)(54356001)(74366001)(31966008)(74502001)(65816001)(15974865002)(80022001)(79102001)(80976001)(56776001)(54316002)(551934002)(19580405001)(83322001)(19580395003)(15202345003)(77982001)(74316001)(59766001)(76482001)(83072001)(46102001)(33646001)(49866001)(51856001)(53806001)(85306002)(50986001)(47736001)(47976001)(4396001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:50:13 -0000 QW5vdGhlciBwb2ludCBvZiByZWZlcmVuY2UgaXMgdGhlIFNDSU0gU0RLIGRldmVsb3BlZCBieSBV bmJvdW5kSUQgLSBodHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL3NjaW1zZGsvLiAgQmpvcm4gY2Fu IHByb3ZpZGUgaW5mb3JtYXRpb24gb24gdGhlIHdheSB0aGF0IHRoZXkgaGF2ZSBpbXBsZW1lbnRl ZCBpdC4NCg0KLS1LZWxseQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2Np bS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU3RldmUgTW95ZXINClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDgsIDIwMTMgMTI6Mzkg UE0NClRvOiBQZXRlciBHaWV0eg0KQ2M6IHNjaW1AaWV0Zi5vcmc7IFBoaWwgSHVudA0KU3ViamVj dDogUmU6IFtzY2ltXSAjNDU6IExEQVAgbWFwcGluZw0KDQpJIGFncmVlIHdpdGggYm90aCBvZiB5 b3UgKGFyZW4ndCBJIGp1c3QgZGlwbG9tYXRpYyB0b2RheSksIHRoZSBidXNpbmVzcyBsb2dpYyBm b3IgdHJhbnNsYXRpbmcgYSBTQ0lNIHVzZXIgdG8gYW4gaW5ldE9yZ1BlcnNvbiBhbmQgYmFjayBp cyBpbXBvcnRhbnQsIGFuZCB0aGUgb3RoZXIgdGhyZWFkIEkgc3RhcnRlZCB0b2RheSAoRmlsdGVy IGFtYmlndWl0eSkgd2lsbCBiZSBpbXBhY3RlZCBieSBib3RoIHRoZSBMREFQIG1hcHBpbmcgYW5k IHRoZSBidXNpbmVzcyBydWxlcyBmb3IgdGhlIHJlc291cmNlcyBiZWluZyBtYXBwZWQuICBGb3Ig dGhlIG1hcHBpbmcgaXRzZWxmLCBJJ2QgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc3RhcnQgd2l0aCB0 aGUgdGFibGUgUGhpbCBoYXMgcHJvdmlkZWQgaW4gc2VjdGlvbiAyLjIuMy40LiAoQXR0cmlidXRl IE5hbWUgTWFwcGluZykuICBUaGUgb25seSBlcnJvciBJIHNlZSBpbiB0aGF0IHRhYmxlIGlzIHRo YXQgcmVnaW9uIGlzIG5vdCBhIHN5bm9ueW0gZm9yIGxvY2FsaXR5IGFuZCBzaG91bGQgYmUgYWRk cmVzcy5yZWdpb24gYW5kIG1hcHBlZCB0byB0aGUgTERBUCAic3QiIGF0dHJpYnV0ZS4gIFRoZXJl IGFyZSBzb21lIG90aGVyIGF0dHJpYnV0ZXMgdGhhdCBhcmVuJ3QgbWFwcGVkIHRoZSBzYW1lIHdh eSB3ZSdyZSBkb2luZyB0aGluZ3MsIGJ1dCB0aGF0J3Mgd2h5IEkgcmVzdGFydGVkIHRoZSBkaXNj dXNzaW9uIQ0KDQpJJ20gYWN0dWFsbHkgbW9yZSBjb25jZXJuZWQgKGF0IHRoaXMgcG9pbnQpIHdp dGggaG93IHRvIHN0b3JlIHRoZSAidHlwZSIgYW5kICJwcmltYXJ5IGZsYWciIGZvciBlYWNoIG11 bHRpLXZhbHVlZCBhdHRyaWJ1dGUsIGFuZCBob3cgdG8gZ3VhcmFudGVlIHRoZSBjb3JyZWN0IG9y ZGVyaW5nIG9mIGF0dHJpYnV0ZXMgdGhhdCBtYWtlIHVwIGFuIGFkZHJlc3MgKHNvIHRoYXQgdGhl IHByb3BlciBwYXJ0cyBhcmUga2VwdCB0b2dldGhlcikuICBMREFQIGRvZXNuJ3QgbmF0aXZlbHkg Z3VhcmFudGVlIHRoZSBzdG9yYWdlIG9yZGVyIG9mIGF0dHJpYnV0ZXMgb3IgZXZlbiB0aGF0IHRo ZSByZXR1cm5lZCBvcmRlciBtYXRjaGVzIHRoZSBpbnNlcnRpb24gb3JkZXIuICBXZSdyZSB1c2lu ZyB0aGUgcHJvcG9zZWQgc3BlY2lmaWNhdGlvbiBmb3IgIk9yZGVyZWQgRW50cmllcyBhbmQgVmFs dWVzIGluIExEQVAiIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaHUtbGRhcC14 b3JkZXJlZC0wMCkgdG8ga2VlcCB0aGluZ3MgYWxpZ25lZC4gIEluIG91ciBjdXJyZW50IHN5c3Rl bSwgd2UncmUgdXNpbmcgdGhlIHBvc3RhbEFkZHJlc3MgdG8gc3RvcmUgdGhlICJ0eXBlIiBhbmQg InByaW1hcnkgZmxhZyIgYWxvbmcgd2l0aCB0aGUgZm9ybWF0dGVkIHZhbHVlICh5ZXMsIHRoaXMg YnJlYWtzIExEQVAgY2xpZW50cyBpbiBzb21lIGNhc2VzLCBidXQgb3VyIGludGVudGlvbiBpcyB0 byBtb3ZlIHBlb3BsZSBhd2F5IGZyb20gZGlyZWN0IExEQVAgYWNjZXNzIGFuZCBvbnRvIHRoZSBT Q0lNIFJFU1RmdWwgc2VydmljZXMuDQoNCkknZCBiZSBoYXBweSB0byB3b3JrIHdpdGggeW91IGlu IHdoYXRldmVyIG1hbm5lciBzZWVtcyBlYXNpZXN0IC4uLiBXZSBoYXZlIGN1c3RvbSB1c2VyIGV4 dGVuc2lvbnMgdGhhdCB3ZSBrbm93IHdvbid0IG1hdGNoIHRoZSBncm91cCdzIGNvbnNlbnN1cyBm b3IgTERBUCBtYXBwaW5nLCBidXQgd2UnZCBsaWtlIHRvIG1pZ3JhdGUgdGhlIGF0dHJpYnV0ZXMg dGhhdCBtYWtlIHNlbnNlIHRvIGJlIGNvbXBhdGlibGUuDQoNClN0ZXZlDQoNClAuUy4gIEZvciB0 aG9zZSBmb2xsb3dpbmcgYWxvbmcsIFBoaWwncyBkb2N1bWVudCBpcyBoZXJlOiBodHRwczovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1odW50LXNjaW0tZGlyZWN0b3J5LTAxLnR4dA0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGV0ZXIgR2lldHoiIDxwZXRlci5naWV0ekBk YWFzaS5kZT4NClRvOiAiUGhpbCBIdW50IiA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogc2Np bUBpZXRmLm9yZywgIlN0ZXZlIE1veWVyIiA8c21veWVyQHBzdS5lZHU+DQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDgsIDIwMTMgMTI6Mzg6NTIgUE0NClN1YmplY3Q6IFJlOiBbc2NpbV0gIzQ1OiBM REFQIG1hcHBpbmcNCg0KQW0gMDguMTAuMjAxMyAxODozMywgc2NocmllYiBQaGlsIEh1bnQ6DQo+ IFBldGVyLA0KPg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gdGFsayB0aHJvdWdoIHRoZSB1c2UgY2Fz ZXMgZm9yIExEQVAgbWFwcGluZy4NCg0KQWdyZWVkLiBTaG91bGQgd2UgZG8gdGhpcyAxLikgaGVy ZSwgMi4pIG9mZi1saW5lIG9yIDMuKSBkdXJpbmcgb25lIG9mIHRoZSBuZXh0IHNjaW0gdGVsY29z Pw0KDQpDaGVlcnMsDQoNClBldGVyDQoNCg0KPg0KPiBUaGUgcmVhc29uIHRoYXQgdGhpcyBpcyBp bXBvcnRhbnQsIGlzIEkgaGVhciBhIGxvdCBvZiBwZW9wbGUgc2F5aW5nICJ3aHkgY2FuJ3QgSSBz aW1wbHkgaW1wbGVtZW50IGEgU0NJTSBBUEkgb24gdG9wIG9mIG15IExEQVAgc2VydmVyPyIuICBX aXRob3V0IGJpLWRpcmVjdGlvbmFsIG1hcHBpbmcsIHlvdSBjYW4ndCBtYWtlIGEgU0NJTSBzZXJ2 ZXIgYmFzZWQgb24gYW4gTERBUCBwbGF0Zm9ybS4gIFRoaXMgaXMgYW4gaW1wb3J0YW50IGxpbWl0 YXRpb24gdG8gdW5kZXJzdGFuZC4gIFRoZSByZWFzb24gSSB3cm90ZSB0aGUgZGlyZWN0b3J5IGRy YWZ0IHdhcyB0byBwb2ludCBvdXQgeW91IGhhdmUgdG8gbW92ZSB0byBhbiB1bmRlcmx5aW5nIGRh dGEgbW9kZWwgdGhhdCBzdXBwb3J0cyBjb21wbGV4IGF0dHJpYnV0ZXMgKGEgU0NJTSBEaXJlY3Rv cnkpLiAgT25jZSB5b3UgaGF2ZSB0aGF0LCBpdCBiZWNvbWVzIHBvc3NpYmxlIHRvIHByb3ZpZGUg TERBUCBvbiB0b3Agb2YgYSBTQ0lNIERpcmVjdG9yeSByYXRoZXIgdGhlbiBhIFNDSU0gQVBJIHNp dHRpbmcgb24gdG9wIG9mIGFuIExEQVAgRGlyZWN0b3J5Lg0KPg0KPiBLZWVwaW5nIGluIG1pbmQg dGhhdCBvdXIgV0cgZm9jdXMgaXMgYWN0dWFsbHkgInByb3Zpc2lvbmluZyIgYW5kIG5vdCAiZGly ZWN0b3J5IHNlcnZpY2VzIiwgaXQgaXMgaG93ZXZlciBwb3NzaWJsZSB0byBzdXBwb3J0IExEQVAg aW4gYSBwcm92aXNpb25pbmcgb25seSB3YXk6DQo+DQo+IDEuICBBcyBhbiBlbmRwb2ludCwgd2hl cmUgYSBTQ0lNIGNlbnRyaWMgZW50aXR5IHB1c2hlcyBwcm92aXNpb25pbmcgcmVxdWVzdHMgdG8g YW4gTERBUCBlbmRwb2ludC4NCj4gMi4gIFdoZXJlIGEgZGlyZWN0b3J5IGlzIHVzZWQgdG8gcHVz aCAibGltaXRlZCIgYXR0cmlidXRlcyB0byBhIFNDSU0gU1AuDQo+DQo+IFRoZXNlIGNhbiBvbmx5 IHdvcmsgYXMgbG9uZyBhcyB0aGUgY2xpZW50IGRvZXMgbm90IGV4cGVjdCByZWFkLWFmdGVyLXdy aXRlIHRvIHByb2R1Y2UgdGhlIHNhbWUgSlNPTi4NCj4NCj4gVGhlIGNoYWxsZW5nZSBmb3Igc3Vj aCBhIG1hcHBpbmcgaXMgdGhlIGFtb3VudCBvZiB2YXJpYWJpbGl0eSB0aGF0IHJlc3VsdHMsIHBh cnRpY3VsYXJseSB3aXRoIGRlYWxpbmcgd2l0aCBob3cgdG8gaGFuZGxlIG11bGx0aS12YWx1ZWQv dHlwZWQgZGF0YS4gIFRoaXMgZ2VuZXJhdGVzIHBlci1kZXBsb3ltZW50IGFuZCBwZXItdHJhbnNh Y3Rpb24gdmFyaWFiaWxpdHkgdGhhdCBjYXVzZXMgZXJyb3JzLiBGb3IgZXhhbXBsZSB3aGF0IHNo b3VsZCBhIHNlcnZlciBkbyB3aGVuIGEgbXVsdGktdmFsdWUgdHlwZSBhcHBlYXJzIHdoaWNoIGhh cyBubyBtYXBwaW5nICh3aGljaCBpcyBzdGF0aWMpPyAgRm9yIGV4YW1wbGUsIGEgbWFwcGluZyBm b3IgaG9tZSBhZGRyZXNzIGFuZCB3b3JrIGFkZHJlc3MgaXMgZGVmaW5lZCwgYnV0IHdoYXQgaGFw cGVucyB3aGVuICJvdGhlciIgYWRkcmVzcyB2YWx1ZSBhcHBlYXJzPw0KPg0KPiBJZiB3ZSBjb3Vs ZCB0YWxrIHRocm91Z2ggdGhlIHVzZSBjYXNlcywgd2UgbWF5IGJlIGFibGUgdG8gY29tZSB1cCB3 aXRoIGEgZG9jdW1lbnQgc3RydWN0dXJlIHRoYXQgd29ya3MgKHdoaWNoIG1pZ2h0IHdlbGwgYmUg d2hhdCB5b3UgcHJvcG9zZSkuDQo+DQo+IFBoaWwNCj4NCj4gQGluZGVwZW5kZW50aWQNCj4gd3d3 LmluZGVwZW5kZW50aWQuY29tDQo+IHBoaWwuaHVudEBvcmFjbGUuY29tDQo+DQo+IE9uIDIwMTMt MTAtMDgsIGF0IDk6MDMgQU0sIFBldGVyIEdpZXR6IDxwZXRlci5naWV0ekBkYWFzaS5kZT4gd3Jv dGU6DQo+DQo+PiBIaSBTdGV2ZSwNCj4+DQo+PiBUaGFua3MgYSBsb3QgZm9yIHRoaXMgd2hpY2gg c29ydCBvZiBjb21lcyBqdXN0IGluIHRpbWUsIHNpbmNlIHdvcmtpbmcgDQo+PiBvbiB0aGF0IGlz IG9uIHRoZSBhZ2VuZGEgZm9yIHRoaXMgd2Vlay4NCj4+DQo+PiBPZiBjb3Vyc2UgaXQgd2lsbCBt YWtlIHNlbnNlIHRvIGNvbGxhYm9yYXRlIG9uIHRoaXMuIEhvdyBzaG91bGQgd2UgDQo+PiBzdGFy dCB0aGF0LiBTaGFsbCBJIGRvIGEgZmlyc3QgZHJhZnQsIHdoaWNoIHVzZXMgcGFydCBvZiBQaGls J3MgDQo+PiBkb2N1bWVudCwgYW5kIHlvdSB3aWxsIGNvbW1lbnQgb24gaXQsIG9yIGRvIHlvdSBh bHNvIGhhdmUgc29tZXRoaW5nIA0KPj4gYWxyZWFkeSBvbiB3aGljaCB3ZSBjYW4gYnVpbGQgb24/ DQo+Pg0KPj4gV2UgYWxzbyB3aWxsIGhhdmUgdG8gYmUgY2xlYXIgYWJvdXQgdGhlIHNjb3BlIG9m IHRoZSBkb2N1bWVudC4gSSANCj4+IHdvdWxkIHByZWZlciBmaXJzdCB0byBkbyBhIHNjaGVtYSBv bmx5IGRvY3VtZW50IGFuZCBsZWF2ZSBvdGhlciANCj4+IHNjaW0tZGlyZWN0b3J5IHRoaW5ncyB0 byBhIHNlY29uZCBkb2N1bWVudCwgd2hpY2ggY291bGQgcmV1c2Ugb3RoZXIgDQo+PiBwYXJ0cyBv ZiBQaGlsJ3MgZG9jdW1lbnQgYnV0IHdoaWNoIGFsc28gY291bGQgaW5jbHVkZSBhIExEQVAgRXJy b3IgdG8gSFRUUCBlcnJvciBtYXBwaW5nLg0KPj4NCj4+IEBTdGV2ZSwgUGhpbCwgYWxsOiBEb2Vz IHRoaXMgbWFrZSBzZW5zZSB0byB5b3U/DQo+Pg0KPj4gUGV0ZXINCj4+DQo+PiBBbSAwOC4xMC4y MDEzIDE3OjMxLCBzY2hyaWViIFN0ZXZlIE1veWVyOg0KPj4+IFBldGVyIGV0IGFsLA0KPj4+DQo+ Pj4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHVzIG9uIHRoZSBsaXN0IHdobyBoYXZlIHByZWxpbWlu YXJ5IG1hcHBpbmdzIGJldHdlZW4gU0NJTSBhbmQgTERBUCdzIGluZXRPcmdQZXJzb24gKGFzIGRl c2NyaWJlZCBpbiB0aGlzIGlzc3VlOiBSZTogW3NjaW1dICM0NTogTERBUCBtYXBwaW5nKS4gIFNp bmNlIHdlJ3ZlIGJlZW4gdGhyb3VnaCBzb21lIG9mIHRoYXQgcGFpbiwgd291bGQgaXQgbWFrZSBz ZW5zZSB0byBjb2xsYWJvcmF0ZSBvbiBjcmVhdGluZyB0aGlzIG1hcHBpbmc/DQo+Pj4NCj4+PiBT dGV2ZQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBzY2ltIG1haWxpbmcgbGlzdA0KPj4+IHNjaW1AaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCj4+DQo+PiAtLQ0KPj4NCj4+ IFBldGVyIEdpZXR6LCBDRU8NCj4+DQo+PiBEQUFTSSBJbnRlcm5hdGlvbmFsIEdtYkggICAgICAg IA0KPj4gRXVyb3BhcGxhdHogMyAgICAgICAgICAgICAgICAgICANCj4+IEQtNzIwNzIgVMO8Ymlu Z2VuICAgICAgICAgICAgICAgIA0KPj4gR2VybWFueSAgICAgICAgICAgICAgICAgICAgDQo+Pg0K Pj4gcGhvbmU6ICs0OSA3MDcxIDQwNzEwOS0wDQo+PiBmYXg6ICAgKzQ5IDcwNzEgNDA3MTA5LTkg IA0KPj4gZW1haWw6IHBldGVyLmdpZXR6QGRhYXNpLmRlDQo+PiB3ZWI6ICAgd3d3LmRhYXNpLmRl DQo+Pg0KPj4gU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBUw7xiaW5nZW4NCj4+IFJlZ2lzdGVyZ2Vy aWNodDogQW10c2dlcmljaHQgU3R1dHRnYXJ0LCBIUkIgMzgyMTc1DQo+PiBHZXNjaMOkZnRzbGVp dHVuZzogUGV0ZXIgR2lldHoNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNjaW0gbWFpbGluZyBsaXN0DQo+PiBzY2ltQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2NpbSBtYWls aW5nIGxpc3QNCj4gc2NpbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NjaW0NCg0KDQotLSANCg0KUGV0ZXIgR2lldHosIENFTw0KDQpEQUFTSSBJbnRl cm5hdGlvbmFsIEdtYkggICAgICAgIA0KRXVyb3BhcGxhdHogMyAgICAgICAgICAgICAgICAgICAN CkQtNzIwNzIgVMO8YmluZ2VuICAgICAgICAgICAgICAgIA0KR2VybWFueSAgICAgICAgICAgICAg ICAgICAgDQoNCnBob25lOiArNDkgNzA3MSA0MDcxMDktMA0KZmF4OiAgICs0OSA3MDcxIDQwNzEw OS05ICANCmVtYWlsOiBwZXRlci5naWV0ekBkYWFzaS5kZQ0Kd2ViOiAgIHd3dy5kYWFzaS5kZQ0K DQpTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IFTDvGJpbmdlbg0KUmVnaXN0ZXJnZXJpY2h0OiBBbXRz Z2VyaWNodCBTdHV0dGdhcnQsIEhSQiAzODIxNzUNCkdlc2Now6RmdHNsZWl0dW5nOiBQZXRlciBH aWV0eg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltDQo= From phil.hunt@oracle.com Tue Oct 8 10:52:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777BC21E827B for ; Tue, 8 Oct 2013 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhMNXeUzQ+TI for ; Tue, 8 Oct 2013 10:52:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D2C8A21E8274 for ; Tue, 8 Oct 2013 10:51:57 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r98HpljM015355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 17:51:48 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98HpkdG016706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 17:51:47 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r98Hpk8o023729; Tue, 8 Oct 2013 17:51:46 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Oct 2013 10:51:46 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> Date: Tue, 8 Oct 2013 10:51:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> To: Steve Moyer X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim@ietf.org, Peter Gietz Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:52:19 -0000 Steve, You hit one one of the major problems (type and primary flag). LDAP has = no way to handle this. Lack of order makes it further complex. The proposal I have seen most is to do things like extend LDAP schema = and create an LDAP attribute per type. Eg. for telephone number, the = value with type of "home" goes to "hometelephonenumber" and so on. Aside form requiring ongoing re-configuration of the SCIM to LDAP = mapping, it also means constantly extending LDAP schema--> HUGE change = management headaches. \ I think once deployers understand these costs, they are going to find = the economy of having a single database supporting SCIM on top of LDAP = as being very negative in practice. Another way is to encode the values. So, the value for home = telephonenumber becomes for example: "home:123-456-7890". Or you use = hashing to do the same thing so telephonenumber;home is 123-456-7890. =20= The problem here, is that existing LDAP clients are impacted. =20 While hashing is probably the best solution, complex values like address = take us into new territories of complexity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-08, at 10:39 AM, Steve Moyer wrote: > I agree with both of you (aren't I just diplomatic today), the = business logic for translating a SCIM user to an inetOrgPerson and back = is important, and the other thread I started today (Filter ambiguity) = will be impacted by both the LDAP mapping and the business rules for the = resources being mapped. For the mapping itself, I'd agree that we = should start with the table Phil has provided in section 2.2.3.4. = (Attribute Name Mapping). The only error I see in that table is that = region is not a synonym for locality and should be address.region and = mapped to the LDAP "st" attribute. There are some other attributes that = aren't mapped the same way we're doing things, but that's why I = restarted the discussion! >=20 > I'm actually more concerned (at this point) with how to store the = "type" and "primary flag" for each multi-valued attribute, and how to = guarantee the correct ordering of attributes that make up an address (so = that the proper parts are kept together). LDAP doesn't natively = guarantee the storage order of attributes or even that the returned = order matches the insertion order. We're using the proposed = specification for "Ordered Entries and Values in LDAP" = (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep things = aligned. In our current system, we're using the postalAddress to store = the "type" and "primary flag" along with the formatted value (yes, this = breaks LDAP clients in some cases, but our intention is to move people = away from direct LDAP access and onto the SCIM RESTful services. >=20 > I'd be happy to work with you in whatever manner seems easiest ... We = have custom user extensions that we know won't match the group's = consensus for LDAP mapping, but we'd like to migrate the attributes that = make sense to be compatible. >=20 > Steve >=20 > P.S. For those following along, Phil's document is here: = https://www.ietf.org/id/draft-hunt-scim-directory-01.txt >=20 > ----- Original Message ----- > From: "Peter Gietz" > To: "Phil Hunt" > Cc: scim@ietf.org, "Steve Moyer" > Sent: Tuesday, October 8, 2013 12:38:52 PM > Subject: Re: [scim] #45: LDAP mapping >=20 > Am 08.10.2013 18:33, schrieb Phil Hunt: >> Peter, >>=20 >> I think we need to talk through the use cases for LDAP mapping. >=20 > Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of > the next scim telcos? >=20 > Cheers, >=20 > Peter >=20 >=20 >>=20 >> The reason that this is important, is I hear a lot of people saying = "why can't I simply implement a SCIM API on top of my LDAP server?". = Without bi-directional mapping, you can't make a SCIM server based on an = LDAP platform. This is an important limitation to understand. The = reason I wrote the directory draft was to point out you have to move to = an underlying data model that supports complex attributes (a SCIM = Directory). Once you have that, it becomes possible to provide LDAP on = top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP = Directory. >>=20 >> Keeping in mind that our WG focus is actually "provisioning" and not = "directory services", it is however possible to support LDAP in a = provisioning only way: >>=20 >> 1. As an endpoint, where a SCIM centric entity pushes provisioning = requests to an LDAP endpoint. >> 2. Where a directory is used to push "limited" attributes to a SCIM = SP. >>=20 >> These can only work as long as the client does not expect = read-after-write to produce the same JSON. >>=20 >> The challenge for such a mapping is the amount of variability that = results, particularly with dealing with how to handle = mullti-valued/typed data. This generates per-deployment and = per-transaction variability that causes errors. For example what should = a server do when a multi-value type appears which has no mapping (which = is static)? For example, a mapping for home address and work address is = defined, but what happens when "other" address value appears? >>=20 >> If we could talk through the use cases, we may be able to come up = with a document structure that works (which might well be what you = propose). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>=20 >>> Hi Steve, >>>=20 >>> Thanks a lot for this which sort of comes just in time, since = working on >>> that is on the agenda for this week. >>>=20 >>> Of course it will make sense to collaborate on this. How should we = start >>> that. Shall I do a first draft, which uses part of Phil's document, = and >>> you will comment on it, or do you also have something already on = which >>> we can build on? >>>=20 >>> We also will have to be clear about the scope of the document. I = would >>> prefer first to do a schema only document and leave other = scim-directory >>> things to a second document, which could reuse other parts of Phil's >>> document but which also could include a LDAP Error to HTTP error = mapping. >>>=20 >>> @Steve, Phil, all: Does this make sense to you? >>>=20 >>> Peter >>>=20 >>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>> Peter et al, >>>>=20 >>>> There are a couple of us on the list who have preliminary mappings = between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: = [scim] #45: LDAP mapping). Since we've been through some of that pain, = would it make sense to collaborate on creating this mapping? >>>>=20 >>>> Steve >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> --=20 >>>=20 >>> Peter Gietz, CEO >>>=20 >>> DAASI International GmbH =20 >>> Europaplatz 3 =20 >>> D-72072 T=FCbingen =20 >>> Germany =20 >>>=20 >>> phone: +49 7071 407109-0 >>> fax: +49 7071 407109-9 =20 >>> email: peter.gietz@daasi.de >>> web: www.daasi.de >>>=20 >>> Sitz der Gesellschaft: T=FCbingen >>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>> Gesch=E4ftsleitung: Peter Gietz >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=FCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=FCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=E4ftsleitung: Peter Gietz >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Tue Oct 8 12:25:36 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03CF21F9EF2 for ; Tue, 8 Oct 2013 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFsq+u4NZbtE for ; Tue, 8 Oct 2013 12:25:11 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id 32ABF21F9ED4 for ; Tue, 8 Oct 2013 12:24:39 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r98JOApW2637966; Tue, 8 Oct 2013 15:24:10 -0400 Date: Tue, 8 Oct 2013 15:24:09 -0400 (EDT) From: Steve Moyer To: Phil Hunt Message-ID: <1599059877.1119632.1381260249964.JavaMail.zimbra@psu.edu> In-Reply-To: <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> 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.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: #45: LDAP mapping Thread-Index: nq1GoquVQ/nu0mpPdD8WtzCm56Yslw== X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org, Peter Gietz Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 19:25:36 -0000 I spoke too soon related to the "Ordered Entries and Values in LDAP" ... Ou= r operations team says it's installed on our server (OpenLDAP) and it's eve= n applied to some attributes, but when I asked him to apply it to the list = of attributes comprising an address (like the constraint overlay), he let m= e know that this was a schema extension. To use this for SCIM, we'd have t= o (in essence) extend the inetOrgPerson into a scimPerson and redefine the = attributes we wanted to order. I've seen a couple instances where it was recommended that SCIM add supplem= ental information to an inetOrgPerson, but I don't think we want to redefin= e the core attributes of inetOrgPerson. Steve ----- Original Message ----- From: "Phil Hunt" To: "Steve Moyer" Cc: "Peter Gietz" , scim@ietf.org Sent: Tuesday, October 8, 2013 1:51:44 PM Subject: Re: [scim] #45: LDAP mapping Steve, You hit one one of the major problems (type and primary flag). LDAP has no= way to handle this. Lack of order makes it further complex. The proposal I have seen most is to do things like extend LDAP schema and c= reate an LDAP attribute per type. Eg. for telephone number, the value with= type of "home" goes to "hometelephonenumber" and so on. Aside form requiring ongoing re-configuration of the SCIM to LDAP mapping, = it also means constantly extending LDAP schema--> HUGE change management he= adaches. \ I think once deployers understand these costs, they are going to find the e= conomy of having a single database supporting SCIM on top of LDAP as being = very negative in practice. Another way is to encode the values. So, the value for home telephonenumbe= r becomes for example: "home:123-456-7890". Or you use hashing to do the= same thing so telephonenumber;home is 123-456-7890. =20 The problem here, is that existing LDAP clients are impacted. =20 While hashing is probably the best solution, complex values like address ta= ke us into new territories of complexity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-08, at 10:39 AM, Steve Moyer wrote: > I agree with both of you (aren't I just diplomatic today), the business l= ogic for translating a SCIM user to an inetOrgPerson and back is important,= and the other thread I started today (Filter ambiguity) will be impacted b= y both the LDAP mapping and the business rules for the resources being mapp= ed. For the mapping itself, I'd agree that we should start with the table = Phil has provided in section 2.2.3.4. (Attribute Name Mapping). The only e= rror I see in that table is that region is not a synonym for locality and s= hould be address.region and mapped to the LDAP "st" attribute. There are s= ome other attributes that aren't mapped the same way we're doing things, bu= t that's why I restarted the discussion! >=20 > I'm actually more concerned (at this point) with how to store the "type" = and "primary flag" for each multi-valued attribute, and how to guarantee th= e correct ordering of attributes that make up an address (so that the prope= r parts are kept together). LDAP doesn't natively guarantee the storage or= der of attributes or even that the returned order matches the insertion ord= er. We're using the proposed specification for "Ordered Entries and Values= in LDAP" (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep t= hings aligned. In our current system, we're using the postalAddress to sto= re the "type" and "primary flag" along with the formatted value (yes, this = breaks LDAP clients in some cases, but our intention is to move people away= from direct LDAP access and onto the SCIM RESTful services. >=20 > I'd be happy to work with you in whatever manner seems easiest ... We hav= e custom user extensions that we know won't match the group's consensus for= LDAP mapping, but we'd like to migrate the attributes that make sense to b= e compatible. >=20 > Steve >=20 > P.S. For those following along, Phil's document is here: https://www.iet= f.org/id/draft-hunt-scim-directory-01.txt >=20 > ----- Original Message ----- > From: "Peter Gietz" > To: "Phil Hunt" > Cc: scim@ietf.org, "Steve Moyer" > Sent: Tuesday, October 8, 2013 12:38:52 PM > Subject: Re: [scim] #45: LDAP mapping >=20 > Am 08.10.2013 18:33, schrieb Phil Hunt: >> Peter, >>=20 >> I think we need to talk through the use cases for LDAP mapping. >=20 > Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of > the next scim telcos? >=20 > Cheers, >=20 > Peter >=20 >=20 >>=20 >> The reason that this is important, is I hear a lot of people saying "why= can't I simply implement a SCIM API on top of my LDAP server?". Without b= i-directional mapping, you can't make a SCIM server based on an LDAP platfo= rm. This is an important limitation to understand. The reason I wrote the= directory draft was to point out you have to move to an underlying data mo= del that supports complex attributes (a SCIM Directory). Once you have tha= t, it becomes possible to provide LDAP on top of a SCIM Directory rather th= en a SCIM API sitting on top of an LDAP Directory. >>=20 >> Keeping in mind that our WG focus is actually "provisioning" and not "di= rectory services", it is however possible to support LDAP in a provisioning= only way: >>=20 >> 1. As an endpoint, where a SCIM centric entity pushes provisioning requ= ests to an LDAP endpoint. >> 2. Where a directory is used to push "limited" attributes to a SCIM SP. >>=20 >> These can only work as long as the client does not expect read-after-wri= te to produce the same JSON. >>=20 >> The challenge for such a mapping is the amount of variability that resul= ts, particularly with dealing with how to handle mullti-valued/typed data. = This generates per-deployment and per-transaction variability that causes = errors. For example what should a server do when a multi-value type appears= which has no mapping (which is static)? For example, a mapping for home a= ddress and work address is defined, but what happens when "other" address v= alue appears? >>=20 >> If we could talk through the use cases, we may be able to come up with a= document structure that works (which might well be what you propose). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>=20 >>> Hi Steve, >>>=20 >>> Thanks a lot for this which sort of comes just in time, since working o= n >>> that is on the agenda for this week. >>>=20 >>> Of course it will make sense to collaborate on this. How should we star= t >>> that. Shall I do a first draft, which uses part of Phil's document, and >>> you will comment on it, or do you also have something already on which >>> we can build on? >>>=20 >>> We also will have to be clear about the scope of the document. I would >>> prefer first to do a schema only document and leave other scim-director= y >>> things to a second document, which could reuse other parts of Phil's >>> document but which also could include a LDAP Error to HTTP error mappin= g. >>>=20 >>> @Steve, Phil, all: Does this make sense to you? >>>=20 >>> Peter >>>=20 >>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>> Peter et al, >>>>=20 >>>> There are a couple of us on the list who have preliminary mappings bet= ween SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] = #45: LDAP mapping). Since we've been through some of that pain, would it m= ake sense to collaborate on creating this mapping? >>>>=20 >>>> Steve >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> --=20 >>>=20 >>> Peter Gietz, CEO >>>=20 >>> DAASI International GmbH =20 >>> Europaplatz 3 =20 >>> D-72072 T=C3=BCbingen =20 >>> Germany =20 >>>=20 >>> phone: +49 7071 407109-0 >>> fax: +49 7071 407109-9 =20 >>> email: peter.gietz@daasi.de >>> web: www.daasi.de >>>=20 >>> Sitz der Gesellschaft: T=C3=BCbingen >>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>> Gesch=C3=A4ftsleitung: Peter Gietz >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=C3=BCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=C3=BCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=C3=A4ftsleitung: Peter Gietz >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From likepeng@huawei.com Wed Oct 9 00:29:14 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ABD21E80DE for ; Wed, 9 Oct 2013 00:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qli9XijSOWbY for ; Wed, 9 Oct 2013 00:29:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 46D6821E80D3 for ; Wed, 9 Oct 2013 00:29:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYU05189; Wed, 09 Oct 2013 07:29:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:28:45 +0100 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 08:29:08 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.35]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 15:28:59 +0800 From: Likepeng To: "scim@ietf.org" Thread-Topic: [scim] I-D Action: draft-ietf-scim-use-cases-00.txt Thread-Index: AQHOpWWGbcyKcGlsvEi3e4VIGmVj9JnsNb2w Date: Wed, 9 Oct 2013 07:28:59 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252A93787@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [scim] Fw: I-D Action: draft-ietf-scim-use-cases-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:29:14 -0000 SGVsbG8gYWxsLA0KDQpJbiBCZXJsaW4gRjJGIG1lZXRpbmcsIHRoZSBXRyBhZG9wdGVkIHRoZSB1 c2UgY2FzZSBkb2N1bWVudC4NCg0KSSB3b3VsZCBsaWtlIHRvIGFzayBwZW9wbGUgdG8gcmV2aWV3 IHRoZSBkcmFmdCwgYW5kIGdpdmUgdXMgZmVlZGJhY2ssIHNvIHdlIGNhbiBpbXByb3ZlIHRoZSBk cmFmdC4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCENCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHNjaW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCrei y83KsbzkOiAyMDEzxOo41MIzMMjVIDE3OjQ0DQrK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0Ks63LzTogc2NpbUBpZXRmLm9yZw0K1vfM4jogW3NjaW1dIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtc2NpbS11c2UtY2FzZXMtMDAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFN5c3RlbSBmb3IgQ3Jvc3MtZG9tYWluIElk ZW50aXR5IE1hbmFnZW1lbnQgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KCVRpdGxlICAg ICAgICAgICA6IFNDSU0gVXNlIENhc2VzDQoJQXV0aG9yKHMpICAgICAgIDogUGhpbCBIdW50DQog ICAgICAgICAgICAgICAgICAgICAgICAgIEJodW1pcCBLaGFzbmFiaXNoDQogICAgICAgICAgICAg ICAgICAgICAgICAgIEFudGhvbnkgTmFkYWxpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBL ZXBlbmcgTEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgWmFjaGFyeSBaZWx0c2FuDQoJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0wMC50eHQNCglQYWdlcyAg ICAgICAgICAgOiAxNw0KCURhdGUgICAgICAgICAgICA6IDIwMTMtMDgtMjkNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2Vz IG9mIFN5c3RlbSBmb3INCiAgIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lN KS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2NpbS11c2Ut Y2FzZXMNCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNjaW0tdXNlLWNhc2VzLTAwDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg== From swm16@psu.edu Wed Oct 9 06:04:34 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812C411E8183 for ; Wed, 9 Oct 2013 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bHQUvVZtfNs for ; Wed, 9 Oct 2013 06:04:28 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id EE41511E8178 for ; Wed, 9 Oct 2013 06:04:09 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r99D45El3203142 for ; Wed, 9 Oct 2013 09:04:05 -0400 Date: Wed, 9 Oct 2013 09:04:05 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <336599185.1928897.1381323845138.JavaMail.zimbra@psu.edu> In-Reply-To: <444064247.1896470.1381322917474.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: Filter syntax for attributes in extensions Thread-Index: m3YScvCG1vHNGprbWOattLUQL/APSQ== X-Virus-Scanned: by amavisd-new Subject: [scim] Filter syntax for attributes in extensions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 13:04:34 -0000 SCIM extensions are now defined using a top level JSON object that has a URN name and sub-attributes as defined by the extension's schema. The API and schema specifications include one extension for attributes needed for an enterprise user. When searching for users based on extension attributes, the use of URNs as attribute names leads to ugly filter "clauses". If we're looking for enterprise users whose manager is "John Smith", one criteria the filter string will include will be: urn:scim:schemas:extension:enterprise:2.0:User.manager.displayName eq "John Smith" Is there something we can do to make this more readable? Can we allow abbreviations for filter attributes so long as they're unambiguous for the producer's schema? (In this case, manager.displayName might be all we'd need). I've got some university specific values in an extension and while the lexer/parser has no problem using the longer form, it's a bit ugly for humans that come in contact with it. Thanks, Steve From phil.hunt@oracle.com Wed Oct 9 09:22:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D3911E81BE for ; Wed, 9 Oct 2013 09:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.418 X-Spam-Level: X-Spam-Status: No, score=-5.418 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak8l5RPYQ1ik for ; Wed, 9 Oct 2013 09:21:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5A921F83E2 for ; Wed, 9 Oct 2013 09:21:26 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r99GLOLB013764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Oct 2013 16:21:25 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 r99GLOT3027620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 16:21:24 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r99GLOLd006626; Wed, 9 Oct 2013 16:21:24 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Oct 2013 09:21:23 -0700 References: <336599185.1928897.1381323845138.JavaMail.zimbra@psu.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <336599185.1928897.1381323845138.JavaMail.zimbra@psu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Wed, 9 Oct 2013 09:21:20 -0700 To: Steve Moyer X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] Filter syntax for attributes in extensions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:22:10 -0000 My understanding is you only have to use the full uri if displayName is ambi= guous.=20 Phil > On Oct 9, 2013, at 6:04, Steve Moyer wrote: >=20 > SCIM extensions are now defined using a top level JSON object that has a U= RN name and sub-attributes as defined by the extension's schema. The API an= d schema specifications include one extension for attributes needed for an e= nterprise user. When searching for users based on extension attributes, the= use of URNs as attribute names leads to ugly filter "clauses". If we're lo= oking for enterprise users whose manager is "John Smith", one criteria the f= ilter string will include will be: >=20 > urn:scim:schemas:extension:enterprise:2.0:User.manager.displayName eq "Joh= n Smith" >=20 > Is there something we can do to make this more readable? Can we allow abb= reviations for filter attributes so long as they're unambiguous for the prod= ucer's schema? (In this case, manager.displayName might be all we'd need). = I've got some university specific values in an extension and while the lexe= r/parser has no problem using the longer form, it's a bit ugly for humans th= at come in contact with it. >=20 > Thanks, >=20 > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Wed Oct 9 09:53:18 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8D11E81C6 for ; Wed, 9 Oct 2013 09:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C918B10BEJ4n for ; Wed, 9 Oct 2013 09:53:13 -0700 (PDT) Received: from tr22g10.aset.psu.edu (tr22g10.aset.psu.edu [146.186.149.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6522121F9D12 for ; Wed, 9 Oct 2013 09:53:13 -0700 (PDT) Received: from ucs9.ait.psu.edu (ucs9.ait.psu.edu [128.118.73.28]) by tr22g10.aset.psu.edu (8.14.3/8.14.3) with ESMTP id r99GrCnh3219614; Wed, 9 Oct 2013 12:53:12 -0400 Date: Wed, 9 Oct 2013 12:53:12 -0400 (EDT) From: Steve Moyer To: Phil Hunt Message-ID: <1241632928.2416282.1381337592354.JavaMail.zimbra@psu.edu> In-Reply-To: References: <336599185.1928897.1381323845138.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: Filter syntax for attributes in extensions Thread-Index: VunKxO+GM/+cEkbGLgJcVrXxK70vAA== X-Virus-Scanned: by amavisd-new Cc: scim@ietf.org Subject: Re: [scim] Filter syntax for attributes in extensions X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 16:53:18 -0000 I know that section 3.2. (Multi-valued Attributes) of the API specification states: "The attribute's significant value; e.g., the e-mail address, phone number, etc. Attributes that define a "value" sub-attribute MAY be alternately represented as a collection of primitive types." But the manager sub-attribute is not a primitive type within the enterprise user extension. Can you point me to a reference in the specification that describes how attribute names can be shortened? My current lexer/parser will pass either shortened or full names for attributes, but if we're going to allow shortening other types of attribute names (e.g. if the rule is anything that's not ambiguous is allowed), I'm going to need to decide where to convert synonyms to their optimal forms (in the lexer/parser or in the code that converts the expression tree to a LDAP query). Either way it's a pretty big change! Thanks, Steve ----- Original Message ----- From: "Phil Hunt" To: "Steve Moyer" Cc: scim@ietf.org Sent: Wednesday, October 9, 2013 12:21:20 PM Subject: Re: [scim] Filter syntax for attributes in extensions My understanding is you only have to use the full uri if displayName is ambiguous. Phil > On Oct 9, 2013, at 6:04, Steve Moyer wrote: > > SCIM extensions are now defined using a top level JSON object that has a URN name and sub-attributes as defined by the extension's schema. The API and schema specifications include one extension for attributes needed for an enterprise user. When searching for users based on extension attributes, the use of URNs as attribute names leads to ugly filter "clauses". If we're looking for enterprise users whose manager is "John Smith", one criteria the filter string will include will be: > > urn:scim:schemas:extension:enterprise:2.0:User.manager.displayName eq "John Smith" > > Is there something we can do to make this more readable? Can we allow abbreviations for filter attributes so long as they're unambiguous for the producer's schema? (In this case, manager.displayName might be all we'd need). I've got some university specific values in an extension and while the lexer/parser has no problem using the longer form, it's a bit ugly for humans that come in contact with it. > > Thanks, > > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From moransar@cisco.com Wed Oct 9 12:41:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95921E8195 for ; Wed, 9 Oct 2013 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFd9ANHA79XK for ; Wed, 9 Oct 2013 12:41:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5443E21F9A2D for ; Wed, 9 Oct 2013 12:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1381347693; x=1382557293; h=from:to:subject:date:message-id:mime-version; bh=uL1pTuvOrNGOTCYq2Z0aSY4SPnEhnsSeOl2auGu/Zqs=; b=Cb8VusWlOFo64YRIykiq1TKildg/Ea7TAMP/piIqKRE+A8ql6DuqNOjH T9R6ZoPonmn5HlFwOK1yw+FiCJOsHoosQiuY0F1A6X84ktbosPCtyHKQI JnNXkP8BRLuNHSfPpFRdlSRC0xAVBbS1J9fYPV36h7r0REqx1P4clAR3a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAOWwVVKtJXG8/2dsb2JhbABagkNEgQrBN4EfFm0HgicBBGgGHQEMAR1WJwQbh36XM6FDjxSDV4EEA6oEgySCKg X-IronPort-AV: E=Sophos;i="4.90,1065,1371081600"; d="scan'208,217";a="270183070" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2013 19:41:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r99JfHKK028550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Oct 2013 19:41:17 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 14:41:17 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: Next SCIM WG call agenda - Oct. 16th @11AM Pacific Thread-Index: AQHOxSeFvQsz5BBtH0W9Da98VgaR2A== Date: Wed, 9 Oct 2013 19:41:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.81.205] Content-Type: multipart/alternative; boundary="_000_CA3B67220D628A4780D6FEB31F18A3E32ACA11D4xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [scim] Next SCIM WG call agenda - Oct. 16th @11AM Pacific X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:41:39 -0000 --_000_CA3B67220D628A4780D6FEB31F18A3E32ACA11D4xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Just a reminder that the next SCIM WG call is scheduled for Oct. 16th at 11= AM Pacific time. The agenda for that meeting is to continue going through = the backlog of the issues from tracker. For this meeting we will set aside = time specifically to discuss issue #50 as we planned in last week's call. And a further reminder on behalf of Barry, that we should be addressing the= se issues on the mailing list, and using the conference calls to address po= ints that haven't gotten resolution on the list. *Please* work on resolvin= g the issues on the list first, and make the most of the high-bandwidth con= ference-call time. Cheers, Morteza --_000_CA3B67220D628A4780D6FEB31F18A3E32ACA11D4xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2DA16429CA1E694DB92391BA5DD9C219@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

Just a reminder that the next SCIM WG= call is scheduled for Oct. 16th at 11AM Pacific time.  The agenda for= that meeting is to continue going through the backlog of the issues from t= racker. For this meeting we will set aside time specifically to discuss issue #50 as we planned in last week's call.<= /div>

And a further reminder on behalf of Barr= y, that we should be addressing these issues on the mailing list, and = using the conference calls to address points that haven't gotten resol= ution on the list.  *Please* work on resolving the issues on the list first, and make the most of the high-bandwidth= conference-call time.


Cheers,
Morteza
--_000_CA3B67220D628A4780D6FEB31F18A3E32ACA11D4xmbrcdx08ciscoc_-- From peter.gietz@daasi.de Thu Oct 10 05:16:42 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872B21F96EF for ; Thu, 10 Oct 2013 05:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3DsVh2qeO9u for ; Thu, 10 Oct 2013 05:16:38 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id A188C21F9468 for ; Thu, 10 Oct 2013 05:16:37 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 0D2634005F2; Thu, 10 Oct 2013 14:16:33 +0200 (CEST) Received: from [192.168.100.210] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 88D384003BB; Thu, 10 Oct 2013 14:16:30 +0200 (CEST) Message-ID: <52569AA0.9000009@daasi.de> Date: Thu, 10 Oct 2013 14:16:32 +0200 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Phil Hunt References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <5DC5EC3E-6770-4BEA-99E5-185A6E6CB142@oracle.com> In-Reply-To: <5DC5EC3E-6770-4BEA-99E5-185A6E6CB142@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: scim@ietf.org, Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:16:42 -0000 Am 08.10.2013 18:52, schrieb Phil Hunt: > I think we should start on this list. > > The first question to ask is which use-case solution does the WG expect: > > 1. SCIM on a LDAP Directory (in order to have a single identity store), > 2. LDAP as a SCIM provisioning endpoint", or > 3. LDAP on a SCIM Directory (in order to have a single identity store)? > > I think once we have consensus on the above, our efforts will be much more scoped for the actual mapping. > > I think 2 and 3 are possible, but not 1. FWIW, it goes without saying that 2 is technically what is in the WG mandate. I mention the others, because people keep talking about #1 as it seems the least disruptive approach to SCIM adoption (which it isn't). Now I see what you mean. If we find a way to do the mapping bidirectional without information loss (which is needed for #3 as well), I cannot really find, why use-case #1 should not be possible. Of course, only dealing with #2 would make our life much easier. Peter > > After that, we could start the list and get the chairs to book a separate call (there is a mandatory announcement period these days I think). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2013-10-08, at 9:38 AM, Peter Gietz wrote: > >> Am 08.10.2013 18:33, schrieb Phil Hunt: >>> Peter, >>> >>> I think we need to talk through the use cases for LDAP mapping. >> Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of >> the next scim telcos? >> >> Cheers, >> >> Peter >> >> >>> The reason that this is important, is I hear a lot of people saying "why can't I simply implement a SCIM API on top of my LDAP server?". Without bi-directional mapping, you can't make a SCIM server based on an LDAP platform. This is an important limitation to understand. The reason I wrote the directory draft was to point out you have to move to an underlying data model that supports complex attributes (a SCIM Directory). Once you have that, it becomes possible to provide LDAP on top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP Directory. >>> >>> Keeping in mind that our WG focus is actually "provisioning" and not "directory services", it is however possible to support LDAP in a provisioning only way: >>> >>> 1. As an endpoint, where a SCIM centric entity pushes provisioning requests to an LDAP endpoint. >>> 2. Where a directory is used to push "limited" attributes to a SCIM SP. >>> >>> These can only work as long as the client does not expect read-after-write to produce the same JSON. >>> >>> The challenge for such a mapping is the amount of variability that results, particularly with dealing with how to handle mullti-valued/typed data. This generates per-deployment and per-transaction variability that causes errors. For example what should a server do when a multi-value type appears which has no mapping (which is static)? For example, a mapping for home address and work address is defined, but what happens when "other" address value appears? >>> >>> If we could talk through the use cases, we may be able to come up with a document structure that works (which might well be what you propose). >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>> >>>> Hi Steve, >>>> >>>> Thanks a lot for this which sort of comes just in time, since working on >>>> that is on the agenda for this week. >>>> >>>> Of course it will make sense to collaborate on this. How should we start >>>> that. Shall I do a first draft, which uses part of Phil's document, and >>>> you will comment on it, or do you also have something already on which >>>> we can build on? >>>> >>>> We also will have to be clear about the scope of the document. I would >>>> prefer first to do a schema only document and leave other scim-directory >>>> things to a second document, which could reuse other parts of Phil's >>>> document but which also could include a LDAP Error to HTTP error mapping. >>>> >>>> @Steve, Phil, all: Does this make sense to you? >>>> >>>> Peter >>>> >>>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>>> Peter et al, >>>>> >>>>> There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping). Since we've been through some of that pain, would it make sense to collaborate on creating this mapping? >>>>> >>>>> Steve >>>>> >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> -- >>>> >>>> Peter Gietz, CEO >>>> >>>> DAASI International GmbH >>>> Europaplatz 3 >>>> D-72072 Tübingen >>>> Germany >>>> >>>> phone: +49 7071 407109-0 >>>> fax: +49 7071 407109-9 >>>> email: peter.gietz@daasi.de >>>> web: www.daasi.de >>>> >>>> Sitz der Gesellschaft: Tübingen >>>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>>> Geschäftsleitung: Peter Gietz >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> >> Peter Gietz, CEO >> >> DAASI International GmbH >> Europaplatz 3 >> D-72072 Tübingen >> Germany >> >> phone: +49 7071 407109-0 >> fax: +49 7071 407109-9 >> email: peter.gietz@daasi.de >> web: www.daasi.de >> >> Sitz der Gesellschaft: Tübingen >> Registergericht: Amtsgericht Stuttgart, HRB 382175 >> Geschäftsleitung: Peter Gietz >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From peter.gietz@daasi.de Thu Oct 10 05:17:33 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397B21F9468 for ; Thu, 10 Oct 2013 05:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugir14T6-HZK for ; Thu, 10 Oct 2013 05:17:28 -0700 (PDT) Received: from mailserver.daasi.de (mailserver.daasi.de [178.63.152.251]) by ietfa.amsl.com (Postfix) with ESMTP id C51A921F991E for ; Thu, 10 Oct 2013 05:17:21 -0700 (PDT) Received: by mailserver.daasi.de (Postfix, from userid 1001) id 4EDB9400F62; Thu, 10 Oct 2013 14:17:20 +0200 (CEST) Received: from [192.168.100.210] (fw.daasi.de [85.220.140.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailserver.daasi.de (Postfix) with ESMTPS id 344B64003BB; Thu, 10 Oct 2013 14:17:19 +0200 (CEST) Message-ID: <52569AD0.3040402@daasi.de> Date: Thu, 10 Oct 2013 14:17:20 +0200 From: Peter Gietz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Phil Hunt References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> In-Reply-To: <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: scim@ietf.org, Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:17:33 -0000 Am 08.10.2013 19:51, schrieb Phil Hunt: > Steve, > > You hit one one of the major problems (type and primary flag). LDAP has no way to handle this. Lack of order makes it further complex. > > The proposal I have seen most is to do things like extend LDAP schema and create an LDAP attribute per type. Eg. for telephone number, the value with type of "home" goes to "hometelephonenumber" and so on. > > Aside form requiring ongoing re-configuration of the SCIM to LDAP mapping, it also means constantly extending LDAP schema--> HUGE change management headaches. \ > > I think once deployers understand these costs, they are going to find the economy of having a single database supporting SCIM on top of LDAP as being very negative in practice. > > Another way is to encode the values. So, the value for home telephonenumber becomes for example: "home:123-456-7890". Or you use hashing to do the same thing so telephonenumber;home is 123-456-7890. When starting to think about this, I thought that such Attribute Options (as specified in RFC 4512 par. 2.5.2) could be a way forward. > > The problem here, is that existing LDAP clients are impacted. Since every LDAPv3 conforming client should be able to deal with Attribute Options (i.e. should at least be able to ignore them ), I don't see the impact. Since we all seem to agree that inetOrgPerson alone will not be sufficient for the mapping, there will have to be some new LDAP schema for SCIM and we could well use Attribute Options where necessary. > > While hashing is probably the best solution, agreed assuming you mean Attribute Options when saying hashing > complex values like address take us into new territories of complexity. yes that will be the hard stuff. Peter > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On 2013-10-08, at 10:39 AM, Steve Moyer wrote: > >> I agree with both of you (aren't I just diplomatic today), the business logic for translating a SCIM user to an inetOrgPerson and back is important, and the other thread I started today (Filter ambiguity) will be impacted by both the LDAP mapping and the business rules for the resources being mapped. For the mapping itself, I'd agree that we should start with the table Phil has provided in section 2.2.3.4. (Attribute Name Mapping). The only error I see in that table is that region is not a synonym for locality and should be address.region and mapped to the LDAP "st" attribute. There are some other attributes that aren't mapped the same way we're doing things, but that's why I restarted the discussion! >> >> I'm actually more concerned (at this point) with how to store the "type" and "primary flag" for each multi-valued attribute, and how to guarantee the correct ordering of attributes that make up an address (so that the proper parts are kept together). LDAP doesn't natively guarantee the storage order of attributes or even that the returned order matches the insertion order. We're using the proposed specification for "Ordered Entries and Values in LDAP" (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep things aligned. In our current system, we're using the postalAddress to store the "type" and "primary flag" along with the formatted value (yes, this breaks LDAP clients in some cases, but our intention is to move people away from direct LDAP access and onto the SCIM RESTful services. >> >> I'd be happy to work with you in whatever manner seems easiest ... We have custom user extensions that we know won't match the group's consensus for LDAP mapping, but we'd like to migrate the attributes that make sense to be compatible. >> >> Steve >> >> P.S. For those following along, Phil's document is here: https://www.ietf.org/id/draft-hunt-scim-directory-01.txt >> >> ----- Original Message ----- >> From: "Peter Gietz" >> To: "Phil Hunt" >> Cc: scim@ietf.org, "Steve Moyer" >> Sent: Tuesday, October 8, 2013 12:38:52 PM >> Subject: Re: [scim] #45: LDAP mapping >> >> Am 08.10.2013 18:33, schrieb Phil Hunt: >>> Peter, >>> >>> I think we need to talk through the use cases for LDAP mapping. >> Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of >> the next scim telcos? >> >> Cheers, >> >> Peter >> >> >>> The reason that this is important, is I hear a lot of people saying "why can't I simply implement a SCIM API on top of my LDAP server?". Without bi-directional mapping, you can't make a SCIM server based on an LDAP platform. This is an important limitation to understand. The reason I wrote the directory draft was to point out you have to move to an underlying data model that supports complex attributes (a SCIM Directory). Once you have that, it becomes possible to provide LDAP on top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP Directory. >>> >>> Keeping in mind that our WG focus is actually "provisioning" and not "directory services", it is however possible to support LDAP in a provisioning only way: >>> >>> 1. As an endpoint, where a SCIM centric entity pushes provisioning requests to an LDAP endpoint. >>> 2. Where a directory is used to push "limited" attributes to a SCIM SP. >>> >>> These can only work as long as the client does not expect read-after-write to produce the same JSON. >>> >>> The challenge for such a mapping is the amount of variability that results, particularly with dealing with how to handle mullti-valued/typed data. This generates per-deployment and per-transaction variability that causes errors. For example what should a server do when a multi-value type appears which has no mapping (which is static)? For example, a mapping for home address and work address is defined, but what happens when "other" address value appears? >>> >>> If we could talk through the use cases, we may be able to come up with a document structure that works (which might well be what you propose). >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>> >>>> Hi Steve, >>>> >>>> Thanks a lot for this which sort of comes just in time, since working on >>>> that is on the agenda for this week. >>>> >>>> Of course it will make sense to collaborate on this. How should we start >>>> that. Shall I do a first draft, which uses part of Phil's document, and >>>> you will comment on it, or do you also have something already on which >>>> we can build on? >>>> >>>> We also will have to be clear about the scope of the document. I would >>>> prefer first to do a schema only document and leave other scim-directory >>>> things to a second document, which could reuse other parts of Phil's >>>> document but which also could include a LDAP Error to HTTP error mapping. >>>> >>>> @Steve, Phil, all: Does this make sense to you? >>>> >>>> Peter >>>> >>>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>>> Peter et al, >>>>> >>>>> There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping). Since we've been through some of that pain, would it make sense to collaborate on creating this mapping? >>>>> >>>>> Steve >>>>> >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> -- >>>> >>>> Peter Gietz, CEO >>>> >>>> DAASI International GmbH >>>> Europaplatz 3 >>>> D-72072 Tübingen >>>> Germany >>>> >>>> phone: +49 7071 407109-0 >>>> fax: +49 7071 407109-9 >>>> email: peter.gietz@daasi.de >>>> web: www.daasi.de >>>> >>>> Sitz der Gesellschaft: Tübingen >>>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>>> Geschäftsleitung: Peter Gietz >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> >> Peter Gietz, CEO >> >> DAASI International GmbH >> Europaplatz 3 >> D-72072 Tübingen >> Germany >> >> phone: +49 7071 407109-0 >> fax: +49 7071 407109-9 >> email: peter.gietz@daasi.de >> web: www.daasi.de >> >> Sitz der Gesellschaft: Tübingen >> Registergericht: Amtsgericht Stuttgart, HRB 382175 >> Geschäftsleitung: Peter Gietz >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz From phil.hunt@oracle.com Thu Oct 10 08:43:11 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260B011E81DE for ; Thu, 10 Oct 2013 08:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjhGRT-Tss8f for ; Thu, 10 Oct 2013 08:43:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8911E81DC for ; Thu, 10 Oct 2013 08:43:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9AFh1Hp030199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Oct 2013 15:43:02 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 r9AFh0nH025010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 15:43:01 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9AFh0Hu002985; Thu, 10 Oct 2013 15:43:00 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Oct 2013 08:43:00 -0700 References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> <52569AD0.3040402@daasi.de> Mime-Version: 1.0 (1.0) In-Reply-To: <52569AD0.3040402@daasi.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <71CFACDA-7569-453C-83C1-D187C2744FA7@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Thu, 10 Oct 2013 08:42:58 -0700 To: Peter Gietz X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:43:11 -0000 Yes. Thanks forgot the name.=20 Phil > On Oct 10, 2013, at 5:17, Peter Gietz wrote: >=20 >=20 > Am 08.10.2013 19:51, schrieb Phil Hunt: >> Steve, >>=20 >> You hit one one of the major problems (type and primary flag). LDAP has n= o way to handle this. Lack of order makes it further complex. >>=20 >> The proposal I have seen most is to do things like extend LDAP schema and= create an LDAP attribute per type. Eg. for telephone number, the value wit= h type of "home" goes to "hometelephonenumber" and so on. >>=20 >> Aside form requiring ongoing re-configuration of the SCIM to LDAP mapping= , it also means constantly extending LDAP schema--> HUGE change management h= eadaches. \ >>=20 >> I think once deployers understand these costs, they are going to find the= economy of having a single database supporting SCIM on top of LDAP as being= very negative in practice. >>=20 >> Another way is to encode the values. So, the value for home telephonenum= ber becomes for example: "home:123-456-7890". Or you use hashing to do th= e same thing so telephonenumber;home is 123-456-7890. =20 > When starting to think about this, I thought that such Attribute Options > (as specified in RFC 4512 par. 2.5.2) could be a way forward. >=20 >=20 >>=20 >> The problem here, is that existing LDAP clients are impacted. =20 >=20 > Since every LDAPv3 conforming client should be able to deal with > Attribute Options (i.e. should at least be able to ignore them ), I > don't see the impact. >=20 > Since we all seem to agree that inetOrgPerson alone will not be > sufficient for the mapping, there will have to be some new LDAP schema > for SCIM and we could well use Attribute Options where necessary. >=20 >=20 >=20 >>=20 >> While hashing is probably the best solution, > agreed assuming you mean Attribute Options when saying hashing >> complex values like address take us into new territories of complexity. >=20 > yes that will be the hard stuff. >=20 > Peter >=20 >=20 >=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On 2013-10-08, at 10:39 AM, Steve Moyer wrote: >>>=20 >>> I agree with both of you (aren't I just diplomatic today), the business l= ogic for translating a SCIM user to an inetOrgPerson and back is important, a= nd the other thread I started today (Filter ambiguity) will be impacted by b= oth the LDAP mapping and the business rules for the resources being mapped. = For the mapping itself, I'd agree that we should start with the table Phil h= as provided in section 2.2.3.4. (Attribute Name Mapping). The only error I s= ee in that table is that region is not a synonym for locality and should be a= ddress.region and mapped to the LDAP "st" attribute. There are some other a= ttributes that aren't mapped the same way we're doing things, but that's why= I restarted the discussion! >>>=20 >>> I'm actually more concerned (at this point) with how to store the "type"= and "primary flag" for each multi-valued attribute, and how to guarantee th= e correct ordering of attributes that make up an address (so that the proper= parts are kept together). LDAP doesn't natively guarantee the storage orde= r of attributes or even that the returned order matches the insertion order.= We're using the proposed specification for "Ordered Entries and Values in L= DAP" (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep things a= ligned. In our current system, we're using the postalAddress to store the "= type" and "primary flag" along with the formatted value (yes, this breaks LD= AP clients in some cases, but our intention is to move people away from dire= ct LDAP access and onto the SCIM RESTful services. >>>=20 >>> I'd be happy to work with you in whatever manner seems easiest ... We ha= ve custom user extensions that we know won't match the group's consensus for= LDAP mapping, but we'd like to migrate the attributes that make sense to be= compatible. >>>=20 >>> Steve >>>=20 >>> P.S. For those following along, Phil's document is here: https://www.ie= tf.org/id/draft-hunt-scim-directory-01.txt >>>=20 >>> ----- Original Message ----- >>> From: "Peter Gietz" >>> To: "Phil Hunt" >>> Cc: scim@ietf.org, "Steve Moyer" >>> Sent: Tuesday, October 8, 2013 12:38:52 PM >>> Subject: Re: [scim] #45: LDAP mapping >>>=20 >>> Am 08.10.2013 18:33, schrieb Phil Hunt: >>>> Peter, >>>>=20 >>>> I think we need to talk through the use cases for LDAP mapping. >>> Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of >>> the next scim telcos? >>>=20 >>> Cheers, >>>=20 >>> Peter >>>=20 >>>=20 >>>> The reason that this is important, is I hear a lot of people saying "wh= y can't I simply implement a SCIM API on top of my LDAP server?". Without b= i-directional mapping, you can't make a SCIM server based on an LDAP platfor= m. This is an important limitation to understand. The reason I wrote the d= irectory draft was to point out you have to move to an underlying data model= that supports complex attributes (a SCIM Directory). Once you have that, i= t becomes possible to provide LDAP on top of a SCIM Directory rather then a S= CIM API sitting on top of an LDAP Directory. >>>>=20 >>>> Keeping in mind that our WG focus is actually "provisioning" and not "d= irectory services", it is however possible to support LDAP in a provisioning= only way: >>>>=20 >>>> 1. As an endpoint, where a SCIM centric entity pushes provisioning req= uests to an LDAP endpoint. >>>> 2. Where a directory is used to push "limited" attributes to a SCIM SP= . >>>>=20 >>>> These can only work as long as the client does not expect read-after-wr= ite to produce the same JSON. >>>>=20 >>>> The challenge for such a mapping is the amount of variability that resu= lts, particularly with dealing with how to handle mullti-valued/typed data. = This generates per-deployment and per-transaction variability that causes e= rrors. For example what should a server do when a multi-value type appears w= hich has no mapping (which is static)? For example, a mapping for home addr= ess and work address is defined, but what happens when "other" address value= appears? >>>>=20 >>>> If we could talk through the use cases, we may be able to come up with a= document structure that works (which might well be what you propose). >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>>>>=20 >>>>> Hi Steve, >>>>>=20 >>>>> Thanks a lot for this which sort of comes just in time, since working o= n >>>>> that is on the agenda for this week. >>>>>=20 >>>>> Of course it will make sense to collaborate on this. How should we sta= rt >>>>> that. Shall I do a first draft, which uses part of Phil's document, an= d >>>>> you will comment on it, or do you also have something already on which= >>>>> we can build on? >>>>>=20 >>>>> We also will have to be clear about the scope of the document. I would= >>>>> prefer first to do a schema only document and leave other scim-directo= ry >>>>> things to a second document, which could reuse other parts of Phil's >>>>> document but which also could include a LDAP Error to HTTP error mappi= ng. >>>>>=20 >>>>> @Steve, Phil, all: Does this make sense to you? >>>>>=20 >>>>> Peter >>>>>=20 >>>>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>>>> Peter et al, >>>>>>=20 >>>>>> There are a couple of us on the list who have preliminary mappings be= tween SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #= 45: LDAP mapping). Since we've been through some of that pain, would it mak= e sense to collaborate on creating this mapping? >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>> --=20 >>>>>=20 >>>>> Peter Gietz, CEO >>>>>=20 >>>>> DAASI International GmbH =20 >>>>> Europaplatz 3 =20 >>>>> D-72072 T=C3=BCbingen =20 >>>>> Germany =20 >>>>>=20 >>>>> phone: +49 7071 407109-0 >>>>> fax: +49 7071 407109-9 =20 >>>>> email: peter.gietz@daasi.de >>>>> web: www.daasi.de >>>>>=20 >>>>> Sitz der Gesellschaft: T=C3=BCbingen >>>>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>>>> Gesch=C3=A4ftsleitung: Peter Gietz >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> --=20 >>>=20 >>> Peter Gietz, CEO >>>=20 >>> DAASI International GmbH =20 >>> Europaplatz 3 =20 >>> D-72072 T=C3=BCbingen =20 >>> Germany =20 >>>=20 >>> phone: +49 7071 407109-0 >>> fax: +49 7071 407109-9 =20 >>> email: peter.gietz@daasi.de >>> web: www.daasi.de >>>=20 >>> Sitz der Gesellschaft: T=C3=BCbingen >>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>> Gesch=C3=A4ftsleitung: Peter Gietz >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=C3=BCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=C3=BCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=C3=A4ftsleitung: Peter Gietz >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Thu Oct 10 08:46:56 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528121F9BDB for ; Thu, 10 Oct 2013 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.364 X-Spam-Level: X-Spam-Status: No, score=-5.364 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IzpEqDmgRpu for ; Thu, 10 Oct 2013 08:46:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A00F921F8445 for ; Thu, 10 Oct 2013 08:46:50 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9AFkkdc016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Oct 2013 15:46:47 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 r9AFkjXm013146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 15:46:45 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9AFki5d006464; Thu, 10 Oct 2013 15:46:44 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Oct 2013 08:46:44 -0700 References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <5DC5EC3E-6770-4BEA-99E5-185A6E6CB142@oracle.com> <52569AA0.9000009@daasi.de> Mime-Version: 1.0 (1.0) In-Reply-To: <52569AA0.9000009@daasi.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7CBD1C72-20EB-4F59-B069-B7C16E1FAA8B@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Thu, 10 Oct 2013 08:46:43 -0700 To: Peter Gietz X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" , Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:46:56 -0000 Re #3, the assumption is the data store can handle complex attrs and type va= lues. In the other scenarios data is thown away to match ldap's limited sche= ma.=20 FWIW - does it make sense to even map more than one telephone number if ldap= clients won't be upgraded to see them? I have come to the conclusion the ldap directory and cloud directory are ver= y very different. Only provisioning will exist between them. Now try to tell= that to customers. :-) Phil > On Oct 10, 2013, at 5:16, Peter Gietz wrote: >=20 > Am 08.10.2013 18:52, schrieb Phil Hunt: >> I think we should start on this list. >>=20 >> The first question to ask is which use-case solution does the WG expect: >>=20 >> 1. SCIM on a LDAP Directory (in order to have a single identity store), >> 2. LDAP as a SCIM provisioning endpoint", or >> 3. LDAP on a SCIM Directory (in order to have a single identity store)? >>=20 >> I think once we have consensus on the above, our efforts will be much mor= e scoped for the actual mapping. =20 >>=20 >> I think 2 and 3 are possible, but not 1. FWIW, it goes without saying th= at 2 is technically what is in the WG mandate. I mention the others, becaus= e people keep talking about #1 as it seems the least disruptive approach to S= CIM adoption (which it isn't). >=20 > Now I see what you mean. >=20 > If we find a way to do the mapping bidirectional without information > loss (which is needed for #3 as well), I cannot really find, why > use-case #1 should not be possible. >=20 > Of course, only dealing with #2 would make our life much easier. >=20 > Peter >=20 >>=20 >> After that, we could start the list and get the chairs to book a separate= call (there is a mandatory announcement period these days I think). >=20 >=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On 2013-10-08, at 9:38 AM, Peter Gietz wrote: >>>=20 >>> Am 08.10.2013 18:33, schrieb Phil Hunt: >>>> Peter, >>>>=20 >>>> I think we need to talk through the use cases for LDAP mapping. >>> Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of >>> the next scim telcos? >>>=20 >>> Cheers, >>>=20 >>> Peter >>>=20 >>>=20 >>>> The reason that this is important, is I hear a lot of people saying "wh= y can't I simply implement a SCIM API on top of my LDAP server?". Without b= i-directional mapping, you can't make a SCIM server based on an LDAP platfor= m. This is an important limitation to understand. The reason I wrote the d= irectory draft was to point out you have to move to an underlying data model= that supports complex attributes (a SCIM Directory). Once you have that, i= t becomes possible to provide LDAP on top of a SCIM Directory rather then a S= CIM API sitting on top of an LDAP Directory. >>>>=20 >>>> Keeping in mind that our WG focus is actually "provisioning" and not "d= irectory services", it is however possible to support LDAP in a provisioning= only way: >>>>=20 >>>> 1. As an endpoint, where a SCIM centric entity pushes provisioning req= uests to an LDAP endpoint. >>>> 2. Where a directory is used to push "limited" attributes to a SCIM SP= . >>>>=20 >>>> These can only work as long as the client does not expect read-after-wr= ite to produce the same JSON. >>>>=20 >>>> The challenge for such a mapping is the amount of variability that resu= lts, particularly with dealing with how to handle mullti-valued/typed data. = This generates per-deployment and per-transaction variability that causes e= rrors. For example what should a server do when a multi-value type appears w= hich has no mapping (which is static)? For example, a mapping for home addr= ess and work address is defined, but what happens when "other" address value= appears? >>>>=20 >>>> If we could talk through the use cases, we may be able to come up with a= document structure that works (which might well be what you propose). >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On 2013-10-08, at 9:03 AM, Peter Gietz wrote: >>>>>=20 >>>>> Hi Steve, >>>>>=20 >>>>> Thanks a lot for this which sort of comes just in time, since working o= n >>>>> that is on the agenda for this week. >>>>>=20 >>>>> Of course it will make sense to collaborate on this. How should we sta= rt >>>>> that. Shall I do a first draft, which uses part of Phil's document, an= d >>>>> you will comment on it, or do you also have something already on which= >>>>> we can build on? >>>>>=20 >>>>> We also will have to be clear about the scope of the document. I would= >>>>> prefer first to do a schema only document and leave other scim-directo= ry >>>>> things to a second document, which could reuse other parts of Phil's >>>>> document but which also could include a LDAP Error to HTTP error mappi= ng. >>>>>=20 >>>>> @Steve, Phil, all: Does this make sense to you? >>>>>=20 >>>>> Peter >>>>>=20 >>>>> Am 08.10.2013 17:31, schrieb Steve Moyer: >>>>>> Peter et al, >>>>>>=20 >>>>>> There are a couple of us on the list who have preliminary mappings be= tween SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #= 45: LDAP mapping). Since we've been through some of that pain, would it mak= e sense to collaborate on creating this mapping? >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>> --=20 >>>>>=20 >>>>> Peter Gietz, CEO >>>>>=20 >>>>> DAASI International GmbH =20 >>>>> Europaplatz 3 =20 >>>>> D-72072 T=C3=BCbingen =20 >>>>> Germany =20 >>>>>=20 >>>>> phone: +49 7071 407109-0 >>>>> fax: +49 7071 407109-9 =20 >>>>> email: peter.gietz@daasi.de >>>>> web: www.daasi.de >>>>>=20 >>>>> Sitz der Gesellschaft: T=C3=BCbingen >>>>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>>>> Gesch=C3=A4ftsleitung: Peter Gietz >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> --=20 >>>=20 >>> Peter Gietz, CEO >>>=20 >>> DAASI International GmbH =20 >>> Europaplatz 3 =20 >>> D-72072 T=C3=BCbingen =20 >>> Germany =20 >>>=20 >>> phone: +49 7071 407109-0 >>> fax: +49 7071 407109-9 =20 >>> email: peter.gietz@daasi.de >>> web: www.daasi.de >>>=20 >>> Sitz der Gesellschaft: T=C3=BCbingen >>> Registergericht: Amtsgericht Stuttgart, HRB 382175 >>> Gesch=C3=A4ftsleitung: Peter Gietz >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 >=20 > Peter Gietz, CEO >=20 > DAASI International GmbH =20 > Europaplatz 3 =20 > D-72072 T=C3=BCbingen =20 > Germany =20 >=20 > phone: +49 7071 407109-0 > fax: +49 7071 407109-9 =20 > email: peter.gietz@daasi.de > web: www.daasi.de >=20 > Sitz der Gesellschaft: T=C3=BCbingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Gesch=C3=A4ftsleitung: Peter Gietz >=20 >=20 From pradtke@stanford.edu Thu Oct 10 09:19:31 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0F11E8196 for ; Thu, 10 Oct 2013 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Per7AmjkWar for ; Thu, 10 Oct 2013 09:19:25 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 33F6F21F9ED2 for ; Thu, 10 Oct 2013 09:19:25 -0700 (PDT) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D9E403411D3; Thu, 10 Oct 2013 09:19:24 -0700 (PDT) Received: from polml-pradtke.stanford.edu (POLML-pradtke.Stanford.EDU [171.64.18.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 9DB7F341170; Thu, 10 Oct 2013 09:19:23 -0700 (PDT) Message-ID: <5256D3AE.3030302@stanford.edu> Date: Thu, 10 Oct 2013 09:19:58 -0700 From: Patrick Radtke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Gietz References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> <52569AD0.3040402@daasi.de> In-Reply-To: <52569AD0.3040402@daasi.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scim@ietf.org, Steve Moyer , Phil Hunt Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:19:31 -0000 On 10/10/13 5:17 AM, Peter Gietz wrote: >> >The problem here, is that existing LDAP clients are impacted. > Since every LDAPv3 conforming client should be able to deal with > Attribute Options (i.e. should at least be able to ignore them ), I > don't see the impact. Existing clients ignoring attribute options which may be its own problem. For example if my LDAP mail entry was mail;x-scim-type-work;x-scim-primary: pradtke@stanford.edu then Outlook (at least the last time I tested in 2006) wouldn't display my email address in the address book, since there is not a "mail" attribute with no options. We ended up putting all the primary data in attributes with no options, and just using options for the extra data. That seemed to keep regular clients happy. -Patrick From phil.hunt@oracle.com Thu Oct 10 09:21:16 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6111E8174 for ; Thu, 10 Oct 2013 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUAUxyx8xMbY for ; Thu, 10 Oct 2013 09:21:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E38A321F9ED2 for ; Thu, 10 Oct 2013 09:21:10 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9AGL6cM011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Oct 2013 16:21:07 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 r9AGL432023244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 16:21:05 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9AGL4LD023239; Thu, 10 Oct 2013 16:21:04 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Oct 2013 09:21:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5256D3AE.3030302@stanford.edu> Date: Thu, 10 Oct 2013 09:21:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <524914307.638849.1381246294034.JavaMail.zimbra@psu.edu> <52542CEA.2010103@daasi.de> <5254351C.2060005@daasi.de> <377326531.894439.1381253950416.JavaMail.zimbra@psu.edu> <0B20A1A3-470B-471F-AC53-259FD6CEE492@oracle.com> <52569AD0.3040402@daasi.de> <5256D3AE.3030302@stanford.edu> To: Patrick Radtke X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org, Peter Gietz , Steve Moyer Subject: Re: [scim] #45: LDAP mapping X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:21:16 -0000 Agreed.. So the bigger problem is that LDAP clients are unlikely to = adapt to any mapping of the data. Any mapping we make must be = transparent to existing clients. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-10, at 9:19 AM, Patrick Radtke wrote: > On 10/10/13 5:17 AM, Peter Gietz wrote: >>> >The problem here, is that existing LDAP clients are impacted. >> Since every LDAPv3 conforming client should be able to deal with >> Attribute Options (i.e. should at least be able to ignore them ), I >> don't see the impact. >=20 > Existing clients ignoring attribute options which may be its own = problem. For example if my LDAP mail entry was >=20 > mail;x-scim-type-work;x-scim-primary: pradtke@stanford.edu >=20 > then Outlook (at least the last time I tested in 2006) wouldn't = display my email address in the address book, since there is not a = "mail" attribute with no options. >=20 > We ended up putting all the primary data in attributes with no = options, and just using options for the extra data. That seemed to keep = regular clients happy. >=20 > -Patrick >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Oct 16 14:20:43 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B0C11E82F6 for ; Wed, 16 Oct 2013 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2d0+CU7WgNe for ; Wed, 16 Oct 2013 14:20:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id A400D11E82DE for ; Wed, 16 Oct 2013 14:20:37 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 16 Oct 2013 21:20:29 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Wed, 16 Oct 2013 21:20:29 +0000 From: Kelly Grizzle To: "scim@ietf.org" Thread-Topic: [scim] #2: Add pagination capability to plural Resource attributes Thread-Index: AQHNj915W2qHdwsLukaJKa6OHTsyNZnj6kEAgBZgl5A= Date: Wed, 16 Oct 2013 21:20:28 +0000 Message-ID: <74f68bbfec8248798a976dfd0cb7cfd8@BN1PR04MB392.namprd04.prod.outlook.com> References: <062.d017355f67119a11f17037e9648b6c73@tools.ietf.org> <077.abb808069ceda9b379423aae2aca861e@tools.ietf.org> In-Reply-To: <077.abb808069ceda9b379423aae2aca861e@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 06A9651B0057B206A96668 x-originating-ip: [10.255.156.132] x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(80976001)(33646001)(85306002)(59766001)(77982001)(69226001)(81342001)(54316002)(81542001)(76482001)(79102001)(56776001)(74316001)(4396001)(47446002)(74662001)(31966008)(74366001)(63696002)(81816001)(46102001)(81686001)(77096001)(49866001)(50986001)(47976001)(74706001)(47736001)(76796001)(76576001)(76786001)(56816003)(19580405001)(83322001)(19580395003)(74876001)(74502001)(54356001)(53806001)(80022001)(65816001)(83072001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:10.255.156.132; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 21:20:43 -0000 RG9lcyBhbnlvbmUgaGF2ZSBhbnkgcHJvYmxlbXMgd2l0aCBkZWZhdWx0aW5nIHRoZSBHcm91cC5t ZW1iZXJzIGF0dHJpYnV0ZSBhcyBiZWluZyByZXR1cm5lZCBieSBkZWZhdWx0PyAgQW55IG9iamVj dGlvbnMgdG8gY2xvc2luZyB0aGlzIHRpY2tldCB3aXRoIHRoZSBjaGFuZ2Ugc3VnZ2VzdGVkIGlu IHRpY2tldCAjMTA/DQoNCi0tS2VsbHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2NpbSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytzY2ltQHRvb2xzLmlldGYub3Jn XSANClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwMiwgMjAxMyAxMDozNSBBTQ0KVG86IGRyYWZ0 LWlldGYtc2NpbS1hcGlAdG9vbHMuaWV0Zi5vcmc7IEtlbGx5IEdyaXp6bGUNCkNjOiBzY2ltQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NjaW1dICMyOiBBZGQgcGFnaW5hdGlvbiBjYXBhYmlsaXR5 IHRvIHBsdXJhbCBSZXNvdXJjZSBhdHRyaWJ1dGVzDQoNCiMyOiBBZGQgcGFnaW5hdGlvbiBjYXBh YmlsaXR5IHRvIHBsdXJhbCBSZXNvdXJjZSBhdHRyaWJ1dGVzDQoNCg0KQ29tbWVudCAoYnkga2Vs bHkuZ3JpenpsZUBzYWlscG9pbnQuY29tKToNCg0KIEdlbmVyYWwgY29uc2Vuc3VzIHNvIGZhciBo YXMgYmVlbiB0aGF0IHBhZ2luYXRpbmcgb24gcGx1cmFsIHJlc291cmNlICBhdHRyaWJ1dGVzIHdv dWxkIG92ZXItY29tcGxpY2F0ZSB0aGluZ3MuICBUaGUgd29ycnkgYWJvdXQgbGFyZ2UgZ3JvdXBz ICBjb3VsZCBiZSBhbGxldmlhdGVkIGJ5IGltcGxlbWVudGluZyBhIHN1Z2dlc3RlZCBjaGFuZ2Ug aW4gdGlja2V0ICMxMCB3aGVyZSAgZWFjaCBzY2hlbWEgYXR0cmlidXRlIGNhbiBkZXNpZ25hdGUg d2hlbiBpdCBpcyByZXR1cm5lZDoNCg0KICJyZXR1cm5lZCI9ImFsd2F5cyJ8Im5ldmVyInwiZGVm YXVsdCJ8InJlcXVlc3QiDQoNCiBGb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIEkgc3VnZ2Vz dCB0aGF0IEdyb3VwLm1lbWJlcnMgcmVtYWlucyBhcyAgImRlZmF1bHQiLCBidXQgU1AncyBjYW4g b3B0aW9uYWxseSBjaGFuZ2UgdGhpcyB0byAicmVxdWVzdCIgaWYgaXQgaXMgIHByb2JsZW1hdGlj Lg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0N CiBSZXBvcnRlcjogICAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1zY2lt LWFwaUB0b29scy5pZXRmLm9yZw0KICBtZWxpbmRhLnNob3JlQGdtYWlsLmNvbXwgICAgICBTdGF0 dXM6ICBuZXcNCiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICB8ICAgTWlsZXN0b25lOg0KIFByaW9y aXR5OiAgbWFqb3IgICAgICAgIHwgICAgIFZlcnNpb246DQpDb21wb25lbnQ6ICBhcGkgICAgICAg ICAgfCAgUmVzb2x1dGlvbjoNCiBTZXZlcml0eTogIC0gICAgICAgICAgICB8DQogS2V5d29yZHM6 ICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvc2Np bS90cmFjL3RpY2tldC8yI2NvbW1lbnQ6MT4NCnNjaW0gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9z Y2ltLz4NCg0K From kelly.grizzle@sailpoint.com Wed Oct 16 14:28:41 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF1211E81D7 for ; Wed, 16 Oct 2013 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obDXN0gkRpvI for ; Wed, 16 Oct 2013 14:28:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id DFA9011E8186 for ; Wed, 16 Oct 2013 14:28:33 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 16 Oct 2013 21:28:31 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Wed, 16 Oct 2013 21:28:31 +0000 From: Kelly Grizzle To: "draft-ietf-scim-api@tools.ietf.org" , "bjorn.aannestad@unboundid.com" , "leifj@mnt.se" Thread-Topic: [scim] #24: Add the negation operator to the Filtering section Thread-Index: AQHNt3Y/SL4QeP03t025863FnaiH5Jn5y06AgAAy/jA= Date: Wed, 16 Oct 2013 21:28:30 +0000 Message-ID: <84c7aec90b6143a0a980344d02318e70@BN1PR04MB392.namprd04.prod.outlook.com> References: <068.5cc87a1db7cac18bb18e957ed8f861e3@tools.ietf.org> <083.6960e7142ad6eab84c9617f6cc0ed55c@tools.ietf.org> In-Reply-To: <083.6960e7142ad6eab84c9617f6cc0ed55c@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 06B0BE900057B206B0BFDD x-originating-ip: [10.255.156.132] x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(13464003)(47976001)(76796001)(76576001)(33646001)(81816001)(76786001)(74366001)(51856001)(4396001)(19580395003)(83322001)(19580405001)(47736001)(49866001)(53806001)(50986001)(46102001)(54356001)(80976001)(77096001)(56816003)(83072001)(80022001)(74316001)(63696002)(65816001)(31966008)(47446002)(74502001)(74706001)(76482001)(59766001)(74662001)(77982001)(56776001)(54316002)(85306002)(81542001)(81342001)(69226001)(81686001)(79102001)(74876001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:10.255.156.132; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] #24: Add the negation operator to the Filtering section X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 21:28:41 -0000 KzEgZm9yIHRoZSBwcm9wb3NlZCBjaGFuZ2VzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBzY2ltIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK3NjaW1AdG9vbHMuaWV0 Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE2LCAyMDEzIDE6MjYgUE0NClRvOiBk cmFmdC1pZXRmLXNjaW0tYXBpQHRvb2xzLmlldGYub3JnOyBiam9ybi5hYW5uZXN0YWRAdW5ib3Vu ZGlkLmNvbTsgbGVpZmpAbW50LnNlDQpDYzogc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtz Y2ltXSAjMjQ6IEFkZCB0aGUgbmVnYXRpb24gb3BlcmF0b3IgdG8gdGhlIEZpbHRlcmluZyBzZWN0 aW9uDQoNCiMyNDogQWRkIHRoZSBuZWdhdGlvbiBvcGVyYXRvciB0byB0aGUgRmlsdGVyaW5nIHNl Y3Rpb24NCg0KDQpDb21tZW50IChieSBsZWlmakBtbnQuc2UpOg0KDQogQW55IGNvbW1lbnRzIG9u IHRoaXMgaXNzdWU/IERvIHdlIGhhdmUgY29uc2Vuc3VzPw0KDQotLSANCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgT3duZXI6 ICBkcmFmdC1pZXRmLXNjaW0tDQogIGJqb3JuLmFhbm5lc3RhZEB1bmJvdW5kaWQuY29tICAgICAg fCAgYXBpQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgICAgICAg ICAgfCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAg ICAgIHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBhcGkgICAgICAgICAgICAgICAgICAgICAg fCAgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIC0gICAgICAgICAgICAgICAgICAgICAgICB8ICBS ZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvc2NpbS90cmFjL3RpY2tldC8yNCNjb21tZW50OjI+DQpzY2ltIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvc2NpbS8+DQoNCg== From t.rossner@tarent.de Thu Oct 17 00:08:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29B21F992A for ; Thu, 17 Oct 2013 00:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVXWBhlrAWDW for ; Thu, 17 Oct 2013 00:08:48 -0700 (PDT) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 855DB11E8101 for ; Thu, 17 Oct 2013 00:08:16 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id mz12so647884bkb.41 for ; Thu, 17 Oct 2013 00:08:14 -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=NA+GNbxH55W9S52jBrpgqzpaIJyHxT1/E8d/OOhbqIo=; b=l8HegzubOi7LjVA+ys3QI8WoCAyOQ0CVA2wkDMwqLobKlGNes0yP7Dkl6svbOkZ+26 e5HcvoMqxVBDyparRz6cHDF74eJBY47U6w1qn7vuERKaZhOxCbSyrpD0K38d3zNALiC6 /Zj0O/57W6XBnBDgWtzU8xlavfkMS9uIaR4A/o+1X0aEjhGQw2G8XAqciHZKrozfm2T/ DFk4dAaCq8KEjVWheaSCobWkmS53OCeRp3Je38edWJJio4BZN8CVgxmFshODdlDkXyTx Il2pz1RJ5nCBEEmr7FydSAiCnoOP6vjUYwZ6rh5544FbL/LXAlMv/fDiYbQjGUrknh4y zoRw== X-Gm-Message-State: ALoCoQklvQgTXlzai8c76XzrVSizv59U9vK4zfYxqAbwt+FB6mfTr1JRVQqTfWIHaksWlHO8VP0l X-Received: by 10.205.78.5 with SMTP id zk5mr5778781bkb.25.1381993694006; Thu, 17 Oct 2013 00:08:14 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id z6sm49411096bkn.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 00:08:12 -0700 (PDT) Message-ID: <525F8CD4.4010206@tarent.de> Date: Thu, 17 Oct 2013 09:08:04 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <062.d017355f67119a11f17037e9648b6c73@tools.ietf.org> <077.abb808069ceda9b379423aae2aca861e@tools.ietf.org> <74f68bbfec8248798a976dfd0cb7cfd8@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <74f68bbfec8248798a976dfd0cb7cfd8@BN1PR04MB392.namprd04.prod.outlook.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:08:55 -0000 The "returned" option seems to me very reasonable and a good solution to avoid collecting all complex attributes on a standard request of the the Users resource, while we should stay with all the fields (that are returned today) in the default setting. Though I would like to understand in this context the "index" option when it comes to that password field (as mentioned in ticket #47). Is it intended by SCIM to have something like an "authenticate user" function by performing a GET /Users?filter=id eq "someID" AND password eq "somePassword" request? The index option - without digging into details - seems to overcomplicate things and could cause interop problems. Thorsten Am 16.10.2013 23:20, schrieb Kelly Grizzle: > Does anyone have any problems with defaulting the Group.members attribute as being returned by default? Any objections to closing this ticket with the change suggested in ticket #10? > > --Kelly > > > -----Original Message----- > From: scim issue tracker [mailto:trac+scim@tools.ietf.org] > Sent: Wednesday, October 02, 2013 10:35 AM > To: draft-ietf-scim-api@tools.ietf.org; Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes > > #2: Add pagination capability to plural Resource attributes > > > Comment (by kelly.grizzle@sailpoint.com): > > General consensus so far has been that paginating on plural resource attributes would over-complicate things. The worry about large groups could be alleviated by implementing a suggested change in ticket #10 where each schema attribute can designate when it is returned: > > "returned"="always"|"never"|"default"|"request" > > For backwards compatibility, I suggest that Group.members remains as "default", but SP's can optionally change this to "request" if it is problematic. > From t.rossner@tarent.de Thu Oct 17 03:45:53 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3C11E8103 for ; Thu, 17 Oct 2013 03:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-UwM5RDDMyv for ; Thu, 17 Oct 2013 03:45:48 -0700 (PDT) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id AFFA411E8177 for ; Thu, 17 Oct 2013 03:45:38 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so761536bkh.11 for ; Thu, 17 Oct 2013 03:45:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=6EBfQC7e6PBjiCJmqNMhpmZPCTM9CpUEdOawnyVgX4c=; b=Eb/+Ye5VVOZY0bxGb/+km2K0SXOwBX5K2bJ8/7kG1CYsgKkggHbMnjoDZqLrsq/nbq fwI9AKfdwSBGcWIiQcZ7olzdWGE0QMv/Qtayl0B9ARr45A0jwYg18j77kaAl7lu3LEgD MdjgSSwXp6B5MiX9u5eaR1QnHrHbtXQGroTGAcOc17hAf6mRymqKksiNsDf4zauIo6ag bnEJj0WgZYujUEQAVckdgDbx6sLpp5K48Zs13bV3tYVpgJE3Q1yD+Wh1sB+OjMqgHCm1 QB4+Mdvq4qk20UjSsv/QG/9jiBNoxKYBCp8JvUb7zIlovd82uZ6KkciLlpSdGMuZnzLe NuzQ== X-Gm-Message-State: ALoCoQmDOQWgouQcC4tH+HGZkjDFRUFrz8EiCLX5XH1OvK6VuY65zdOxnSnxLeXx0mEkVH776jx/ X-Received: by 10.204.201.71 with SMTP id ez7mr150239bkb.61.1382006721249; Thu, 17 Oct 2013 03:45:21 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id a4sm50000439bko.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 03:45:20 -0700 (PDT) Message-ID: <525FBFB7.7020408@tarent.de> Date: Thu, 17 Oct 2013 12:45:11 +0200 From: =?ISO-8859-15?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [scim] Discussing the ticket queue: #1 & general handling X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:45:53 -0000 Hello everybody, the first ticket in the IETF tracker for SCIM (http://trac.tools.ietf.org/wg/scim/trac/ticket/1) has been there for 13 months. Nobody answered on the 11 months old comment that asked for positive feedback to the enhancement. Can the ticket be closed? Or is there a process to follow? Thanks Thorsten From t.rossner@tarent.de Thu Oct 17 03:58:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA06011E81BA for ; Thu, 17 Oct 2013 03:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSBNYXymTsTP for ; Thu, 17 Oct 2013 03:58:03 -0700 (PDT) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 860B311E825E for ; Thu, 17 Oct 2013 03:58:02 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id mz12so744919bkb.41 for ; Thu, 17 Oct 2013 03:58:01 -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=QRTqHQxqdLdHNtjMZr15KRlrhF+ORi/3Aj0/yK7VTNI=; b=e3qgje3LChAdSQtuddhgkFeQpca8zAKLo99d0xZ96AdiTnBMIafWfdhsOu7qx6J3Lh YkIjc7VWFgv6d1cMzo9Qg2Z08YAAdbd15uR/wRLFwtoURaTppMd+htazlD0gs7a12Lfn ecJD/hGXJrhpEF7CpjFcCoTBHNl69LLLYgoDgS8bt6U1JT0GiDG27tN70mmvzyzLMgv7 qQLZx3wFTqGPhqRbyaZdsabeounIE/mLuNVCT05C8Mhlzg7qrkzbVCsYhmRvaqm0RjAv NdRWuyC28Poq2udagM4eUxex5zVpHJi/ZA/JW5matIjsB6QvZ2rlmXu17IKEkrqOhWUV q0Aw== X-Gm-Message-State: ALoCoQkIV6k4dkGNSJOMRvTvxqPGhw2TOWjUq5WN8OAVwNneXi4cOiZmRJbXjimpMovflrTrVKfm X-Received: by 10.205.14.69 with SMTP id pp5mr6716682bkb.14.1382007481536; Thu, 17 Oct 2013 03:58:01 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id on10sm50035689bkb.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 03:58:00 -0700 (PDT) Message-ID: <525FC2AF.5060002@tarent.de> Date: Thu, 17 Oct 2013 12:57:51 +0200 From: =?ISO-8859-15?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [scim] Ticket #3 - Exclude Attributes explicitly X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:58:09 -0000 Hi all from my perspective the ticket covers a very reasonable enhancement, as long as it is a "SHOULD" in the standard. It would not add complexity to simple SCIM implementations, while clients that send a requests to a server that does not support the attribute exclusion still should retrieve data they can work with... if they do not perform some sort of strict schema validation against a stripped-down schema. What do you think? Thanks Thorsten From leifj@mnt.se Thu Oct 17 04:03:14 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6AE11E8167 for ; Thu, 17 Oct 2013 04:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoExDsoytS8A for ; Thu, 17 Oct 2013 04:03:10 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8C11E8115 for ; Thu, 17 Oct 2013 04:03:09 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id b15so769533eek.14 for ; Thu, 17 Oct 2013 04:03:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q7mLBEr9h5SWfG3rly6xa95fVsw5MaU6tirWIxqx6AE=; b=BgP+N54cAFUpphUJMuqYmxIiMwVoq3/na7EiHfCmQqQxr3/KhW+ymDnZClwlwL2BbE pPvvTAZKW0MXujnwcxKfwX3K/uzgR/KDXUeAXUhhbpTC0jBt3eY8Jyw/mhYClsBB2PJ6 63ciQ4+I01u56wiQB1OlEp3e/klZvFeSZtPEj9u978kWkUwq+Q1CVXWkUeESoo8Xvz+7 uxbvD+ynyGb3eWq9wgSCvOeImp6FQ0ybCO4K17Vq+5IchhWgvcrp5q15Fh7ckpA7lj/h DE6BMiTlkBvKgGGFkaysK8PL9kCgaBodqapfwm7xN/3DL8PR2T8+XdHG1wnE/SvYqzbt iTRg== X-Gm-Message-State: ALoCoQlG8NiklQxE6P0gHwr2PlZ04y+CD6MPSlaRtxV888RWqPwQ4aZlwZESDKjNkzm2vpLhqHXj X-Received: by 10.14.198.197 with SMTP id v45mr12080949een.52.1382007788883; Thu, 17 Oct 2013 04:03:08 -0700 (PDT) Received: from ?IPv6:2001:948:6:2:f8f5:3a94:fe19:44? ([2001:948:6:2:f8f5:3a94:fe19:44]) by mx.google.com with ESMTPSA id a43sm191460817eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 04:03:08 -0700 (PDT) Message-ID: <525FC3EB.6020608@mnt.se> Date: Thu, 17 Oct 2013 13:03:07 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <525FBFB7.7020408@tarent.de> In-Reply-To: <525FBFB7.7020408@tarent.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [scim] Discussing the ticket queue: #1 & general handling X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 11:03:14 -0000 On 10/17/2013 12:45 PM, Thorsten Roßner wrote: > Hello everybody, > > the first ticket in the IETF tracker for SCIM > (http://trac.tools.ietf.org/wg/scim/trac/ticket/1) has been there for 13 > months. Nobody answered on the 11 months old comment that asked for > positive feedback to the enhancement. Can the ticket be closed? Or is > there a process to follow? > > Thanks > Thorsten > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim The process is that if you have suggestions you post a comment (like you just did) with a suggestion for how to resolve the ticket. Hopefully that starts the discussion going! From t.rossner@tarent.de Thu Oct 17 04:16:36 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB2811E8102 for ; Thu, 17 Oct 2013 04:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwl9Sga8Coqr for ; Thu, 17 Oct 2013 04:16:31 -0700 (PDT) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id DDF5611E8135 for ; Thu, 17 Oct 2013 04:16:30 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id na10so783225bkb.0 for ; Thu, 17 Oct 2013 04:16: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:references:in-reply-to:content-type :content-transfer-encoding; bh=Agz+cugUeXLHdf2ogv2oa9LJquu1QZ7wTMe9ol9FsXI=; b=F/OrLGtlDnoavyjLRebqijkyc5FjydcvBEri14vk96pdqTt8Vega38/ruMVxXDYBya H8k15qE3Nsbs+Em5j5gv92T6xwfWxSzo0ApYd5VKTrU0XdO1vOHJR75B/M/yNi5OQOaA i/XgnUVzfLWsTV1DJJXQzZGdFOkT11vGxIPWivkfFSFMKS0Zqy+ty2eVvdeLsBKgb/Q1 dsx9pE/tqIZEypfzSWGd7TWOIpS7/udSUx9xDIE2s4oUDy8n9Y0ru/0cQIsYQBxliXfl nCZ5WQyi2Z6KhABDOou6E7msrGjsg2o4y7IqIA8CZlN46ZIhPVUJDMz4YFcYXQB8gU8K 3oTQ== X-Gm-Message-State: ALoCoQmc0aOTNb9peLXVGgvlhQr64gNqZjwImKj7gIp+oHUNMUg+7JR+TvLLfhnOOd6lmrcdoyIG X-Received: by 10.204.229.76 with SMTP id jh12mr1120442bkb.44.1382008582743; Thu, 17 Oct 2013 04:16:22 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id a4sm50086101bko.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 04:16:21 -0700 (PDT) Message-ID: <525FC6FC.8080505@tarent.de> Date: Thu, 17 Oct 2013 13:16:12 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <525FBFB7.7020408@tarent.de> <525FC3EB.6020608@mnt.se> In-Reply-To: <525FC3EB.6020608@mnt.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [scim] Discussing the ticket queue: #1 & general handling X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 11:16:36 -0000 Thanks for the quick reply. To make my point of view more explict: I do not see the need for the enhancement. I would vote for a "won't fix" and closing the ticket. Cheers Thorsten Am 17.10.2013 13:03, schrieb Leif Johansson: > On 10/17/2013 12:45 PM, Thorsten Roßner wrote: >> Hello everybody, >> >> the first ticket in the IETF tracker for SCIM >> (http://trac.tools.ietf.org/wg/scim/trac/ticket/1) has been there for 13 >> months. Nobody answered on the 11 months old comment that asked for >> positive feedback to the enhancement. Can the ticket be closed? Or is >> there a process to follow? >> >> Thanks >> Thorsten >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > The process is that if you have suggestions you post a comment (like you > just did) with a suggestion for how to resolve the ticket. Hopefully > that starts the discussion going! > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Thu Oct 17 04:53:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FDA11E81B8 for ; Thu, 17 Oct 2013 04:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFIc8C5ZSfXc for ; Thu, 17 Oct 2013 04:53:12 -0700 (PDT) Received: from tr21g12.aset.psu.edu (tr21g12.aset.psu.edu [146.186.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 59BDB11E81BE for ; Thu, 17 Oct 2013 04:53:03 -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 r9HBr2Og3530804 for ; Thu, 17 Oct 2013 07:53:02 -0400 Date: Thu, 17 Oct 2013 07:53:02 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <471124233.11978321.1382010782674.JavaMail.zimbra@psu.edu> In-Reply-To: <490656657.11975513.1382010562418.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [209.158.7.249] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Linux)/8.0.4_GA_5737) Thread-Topic: Add TTY or TDD to canonical types for phoneNumbers. Thread-Index: K7j2PbGQgSGwCm9o8dYQ+uSFb85P8A== X-Virus-Scanned: by amavisd-new Subject: [scim] Add TTY or TDD to canonical types for phoneNumbers. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 11:53:19 -0000 I'd like to propose we add either "tdd" or "tty" (see https://en.wikipedia.org/wiki/Telecommunications_device_for_the_deaf) to the list of canonical types for phoneNumbers. While these devices are rare (and you could thus argue the type of "other" is appropriate), specialized equipment is required to communicate with a person using a TDD. One of our use cases is to send emergency alerts to users, so it's imperative that we known when a TDD is being used. Steve From leifj@mnt.se Thu Oct 17 05:09:20 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8FE21F9948 for ; Thu, 17 Oct 2013 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZN4StcjyCKV for ; Thu, 17 Oct 2013 05:09:16 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7CB21F9A99 for ; Thu, 17 Oct 2013 05:09:13 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so1003748eek.20 for ; Thu, 17 Oct 2013 05:09:12 -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=atU+rarnbzYJ44mPJXv5PDiaLzXTdpUBMQCs8tgBdIg=; b=QPytIgfwtwMEHCyxe7qE1/hvUh0i/tjjtFTqAzKIPEtMy0ByNahsUM620fhwfczArf elLRO24YgH3jx5ghexS1lFJ+FZ6iewUlr3utcxfcGuXK/w1vSI1+mvIBj///GTlMBjR5 3jSH21h8/o2DZnExSHC3EDZo/OOgqsLhmmclcqkXUYsQSTZEm6itQJ3oRPE2HsMdOvPe mhSwY+ho13OGF/AmOCjPKeJjRjTh3WgIQbAVEjTC/eoSQHMj9oQ0G5VVSNumZo6a2VT7 o3+dSedyjr+oF4cvYS/dmODXc3c1KO8GUtlhPWyazoABYHDs3mii7ioo2qMok7nF2Nlk vLJw== X-Gm-Message-State: ALoCoQlvY2w3p0b29H8q6k18IoKeKnL9RenTcnr63IQkGmvQGkUzfsrs/fIsEtoYEj6lOoFkNtbL X-Received: by 10.14.174.131 with SMTP id x3mr12307678eel.25.1382011752385; Thu, 17 Oct 2013 05:09:12 -0700 (PDT) Received: from ?IPv6:2001:948:6:2:f8f5:3a94:fe19:44? ([2001:948:6:2:f8f5:3a94:fe19:44]) by mx.google.com with ESMTPSA id r48sm192187834eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 05:09:11 -0700 (PDT) Message-ID: <525FD366.100@mnt.se> Date: Thu, 17 Oct 2013 14:09:10 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <525FBFB7.7020408@tarent.de> <525FC3EB.6020608@mnt.se> <525FC6FC.8080505@tarent.de> In-Reply-To: <525FC6FC.8080505@tarent.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [scim] Discussing the ticket queue: #1 & general handling X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:09:21 -0000 On 10/17/2013 01:16 PM, Thorsten Roßner wrote: > Thanks for the quick reply. > > To make my point of view more explict: I do not see the need for the > enhancement. I would vote for a "won't fix" and closing the ticket. > > Cheers > Thorsten > > > Am 17.10.2013 13:03, schrieb Leif Johansson: >> On 10/17/2013 12:45 PM, Thorsten Roßner wrote: >>> Hello everybody, >>> >>> the first ticket in the IETF tracker for SCIM >>> (http://trac.tools.ietf.org/wg/scim/trac/ticket/1) has been there for 13 >>> months. Nobody answered on the 11 months old comment that asked for >>> positive feedback to the enhancement. Can the ticket be closed? Or is >>> there a process to follow? >>> >>> Thanks >>> Thorsten >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> The process is that if you have suggestions you post a comment (like you >> just did) with a suggestion for how to resolve the ticket. Hopefully >> that starts the discussion going! >> _______________________________________________ >> 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 Can you visit the trac-site and add that as a comment? That way we can keep track of things... From t.rossner@tarent.de Thu Oct 17 05:58:16 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA811E81B4 for ; Thu, 17 Oct 2013 05:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrvFmr2D961a for ; Thu, 17 Oct 2013 05:57:44 -0700 (PDT) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 62AA621F9F80 for ; Thu, 17 Oct 2013 05:56:57 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id mz13so803299bkb.16 for ; Thu, 17 Oct 2013 05:56:56 -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=5B6N218PfmQXOj8lJnlKrHkciYxI54bJqetQv05ahJY=; b=AzJizadh29ke6u+3BAe0vbwmC2uf7ge2pSnNCR6IMkV7f3Lme+NryaX9ls5w4TaRzr 38Q8Q66U4RHJuxK2eX+BsG2O6OThlbd18O5gI9IzcYo77d4ipuyjtInAEfEObWYkFSXO HMEqbNSjQ0wFXzXJFsufC1JYeL0mvXlueJGfRExsbsj/sjiPP9TvMLW7hx0UqDqI/io7 pJ/tu/K4mxkquKeWbbdjdmkPj7DOtAwB+hCv6q/ypLofCcL5JEEs8XRBgPT7Dfrz+qS7 j4yAST4iV+h2Kys/phWrqYe2YzVgE2E7MbZjhnPUG0ohNqC53eFfqAZNtINVSNletdjf dQGw== X-Gm-Message-State: ALoCoQmaXCSN+PPfSUE/6m+WgtMLBvAdVyaVxWVksVLDvPKRImiKIpn78H21zE+QM9NQDbqnJixQ X-Received: by 10.204.69.202 with SMTP id a10mr1611596bkj.36.1382014615981; Thu, 17 Oct 2013 05:56:55 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id on10sm50368585bkb.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 05:56:54 -0700 (PDT) Message-ID: <525FDE8D.5060105@tarent.de> Date: Thu, 17 Oct 2013 14:56:45 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <471124233.11978321.1382010782674.JavaMail.zimbra@psu.edu> In-Reply-To: <471124233.11978321.1382010782674.JavaMail.zimbra@psu.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Add TTY or TDD to canonical types for phoneNumbers. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:58:16 -0000 As the canonical value for phonenumber type is an information about "where will reach the person" rather than "on what kind of device" your request seems to me very use case specific. You could either use an extension or make use of the flexibility the standard allows in canonical values: " Additionally, when Canonical Values are specified Service Providers SHOULD conform to those values if appropriate, but MAY provide alternate String values to represent additional values." From: http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-3.1.1 Cheers Thorsten Am 17.10.2013 13:53, schrieb Steve Moyer: > I'd like to propose we add either "tdd" or "tty" (see https://en.wikipedia.org/wiki/Telecommunications_device_for_the_deaf) to the list of canonical types for phoneNumbers. While these devices are rare (and you could thus argue the type of "other" is appropriate), specialized equipment is required to communicate with a person using a TDD. One of our use cases is to send emergency alerts to users, so it's imperative that we known when a TDD is being used. > > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From swm16@psu.edu Thu Oct 17 07:37:28 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0421F9E43 for ; Thu, 17 Oct 2013 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOMsHFjhLDPf for ; Thu, 17 Oct 2013 07:37:22 -0700 (PDT) Received: from tr21g10.aset.psu.edu (tr21g10.aset.psu.edu [146.186.149.132]) by ietfa.amsl.com (Postfix) with ESMTP id 78EC221F91AB for ; Thu, 17 Oct 2013 07:37:22 -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 r9HEbKod3354760; Thu, 17 Oct 2013 10:37:20 -0400 Date: Thu, 17 Oct 2013 10:37:20 -0400 (EDT) From: Steve Moyer To: scim@ietf.org Message-ID: <2091506392.12322044.1382020640039.JavaMail.zimbra@psu.edu> In-Reply-To: <2128664988.12208546.1382018260502.JavaMail.zimbra@psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.118.58.157] X-Mailer: Zimbra 8.0.4_GA_5739 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: Add TTY or TDD to canonical types for phoneNumbers. Thread-Index: 7kcsTVOG771AzviBw3xbjt8d0NvCow== X-Virus-Scanned: by amavisd-new Cc: t.rossner@tarent.de Subject: Re: [scim] Add TTY or TDD to canonical types for phoneNumbers. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Steve Moyer List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 14:37:28 -0000 I think a more proper definition for the "phoneNumber" field's type would be: "A numerical address that specifies an end-point connected to the public telephony infrastructure". Thorsten wrote: "As the canonical value for phonenumber type is an information about "where will reach the person" rather than "on what kind of device"" But there are actually problems with the existing set of phoneNumber types ... fax, for instance, also describes "on what kind of device". I've thrown together the following table to highlight some of the oddities (I've tried to put implied characteristics in parenthesis): +------------------------------+-------------+--------------------+---------+ |Canonical types (phoneNumber) | what | where | how | +------------------------------+-------------+--------------------+---------+ | fax | fax | ? | (modem) | | home | (telephone) | home | (voice) | | mobile | (telephone) | (current location) | voice | | | (telephone) | (current location) | text | | other | ? | ? | ? | | pager | pager | ? | (text) | | work | (telephone) | work | (voice) | +------------------------------+-------------+--------------------+---------+ There's a lot of ambiguity in what each "type" really means, and if varies from "where the device is", "what the device is" and "how can I reach the end-point. If your boss has two "phoneNumber" objects with the type "fax" as part of his User attributes, and he tells you "That document has to be signed today or you're fired - send it to my home fax machine immediately", what do you do? My "emergency alerts" use case could be considered a special case, and I have no issue creating extensions as needed (we've already done it for other attributes) or adding producer specific values for type. I would however submit that the general use case of "notify a user" is pretty common (reviewing the use-case document is on my to-do list and I'll give more specifics then). For those of us in the U.S., the ADA (http://www.ada.gov/) governs what steps we've got to take to adapt our services for those with disabilities. Most of us are familiar with the section 508 rules for making website's available to the blind, but our organization has other guidelines we have to follow related to telephony. I'll let other comment for a few days, and develop whatever extensions I need to make this work, but I think the specification should at least address the implied operation of each phoneNumber type as shown in the table above. I'll shut up now ... what do others think? Steve From kelly.grizzle@sailpoint.com Thu Oct 17 08:30:20 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4773F11E8257 for ; Thu, 17 Oct 2013 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxGUzB8LnRQQ for ; Thu, 17 Oct 2013 08:30:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0511E8266 for ; Thu, 17 Oct 2013 08:30:11 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 17 Oct 2013 15:30:09 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Thu, 17 Oct 2013 15:30:08 +0000 From: Kelly Grizzle To: scim issue tracker , "draft-ietf-scim-core-schema@tools.ietf.org" , "t.rossner@osiam.org" Thread-Topic: [scim] #1: Consider roles within groups Thread-Index: AQHOyzavpZ7sUKH3sk+GkwXvnKEN1Zn5BQRw Date: Thu, 17 Oct 2013 15:30:08 +0000 Message-ID: <04cd952cca9c414faab8cf5f810136be@BN1PR04MB392.namprd04.prod.outlook.com> References: <062.70023207719b196d596d26bc0af91d1e@tools.ietf.org> <077.ef823189383c089fadc887b9b0c2e224@tools.ietf.org> In-Reply-To: <077.ef823189383c089fadc887b9b0c2e224@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0A8F07860057C40A8F08D3 x-originating-ip: [72.182.10.254] x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(13464003)(47976001)(81816001)(76576001)(33646001)(76786001)(76796001)(74366001)(4396001)(51856001)(19580395003)(19580405001)(83322001)(50986001)(53806001)(47736001)(49866001)(46102001)(80976001)(54356001)(56816003)(77096001)(83072001)(80022001)(74316001)(63696002)(66066001)(65816001)(31966008)(47446002)(74502001)(74706001)(76482001)(59766001)(74662001)(77982001)(56776001)(54316002)(85306002)(81542001)(81342001)(69226001)(81686001)(79102001)(74876001)(17413003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:72.182.10.254; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] #1: Consider roles within groups X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:30:20 -0000 KzEgZm9yIGNsb3NpbmcgYXMgIndvbid0IGZpeCIuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHNjaW0gaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrc2NpbUB0b29scy5p ZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywgMjAxMyA3OjQ1IEFNDQpUbzog ZHJhZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hQHRvb2xzLmlldGYub3JnOyBLZWxseSBHcml6emxl OyB0LnJvc3NuZXJAb3NpYW0ub3JnDQpDYzogc2NpbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtz Y2ltXSAjMTogQ29uc2lkZXIgcm9sZXMgd2l0aGluIGdyb3Vwcw0KDQojMTogQ29uc2lkZXIgcm9s ZXMgd2l0aGluIGdyb3Vwcw0KDQoNCkNvbW1lbnQgKGJ5IHQucm9zc25lckBvc2lhbS5vcmcpOg0K DQogQXMgdGhlcmUgd2FzIG5vIHBvc2l0aXZlIGZlZWRiYWNrIGluIHRoZSBsYXN0IDExIG1vbnRo cyB0byBhZGQgdGhlICBlbmhhbmNlbWVudCB0byB0aGUgc3RhbmRhcmQgSSB0aGluayB3ZSBzaG91 bGQgY2xvc2UgdGhlIHRpY2tldCB3aXRoICJ3b24ndCAgZml4IiBzdGF0dXMuIEVzcGVjaWFsbHkg LSBhcyBtZW50aW9uZWQgYnkgS2VsbHkgLSBhbiBleHRlbnNpb24gY291bGQgc3RpbGwgIHNhdGlz ZnkgdGhlIG1lbnRpb25lZCByZXF1aXJlbWVudC4NCg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICB8 ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1zY2ltLWNvcmUtDQogIG1lbGluZGEuc2hvcmVAZ21h aWwuY29tfCAgc2NoZW1hQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBlbmhhbmNlbWVudCAg fCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgIHwgICBNaWxlc3Rv bmU6DQpDb21wb25lbnQ6ICBjb3JlLXNjaGVtYSAgfCAgICAgVmVyc2lvbjoNCiBTZXZlcml0eTog IC0gICAgICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAgICAgIHwN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCg0KVGlja2V0 IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NjaW0vdHJhYy90aWNrZXQvMSNj b21tZW50OjI+DQpzY2ltIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2NpbS8+DQoNCg== From phil.hunt@oracle.com Thu Oct 17 09:50:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2103621F9C53 for ; Thu, 17 Oct 2013 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.65 X-Spam-Level: X-Spam-Status: No, score=-5.65 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYvnZDsMoY6I for ; Thu, 17 Oct 2013 09:50:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E379A11E81A2 for ; Thu, 17 Oct 2013 09:50:27 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9HGoQCC020295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Oct 2013 16:50:27 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 r9HGoOQI018425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 16:50:25 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9HGoOA7028048; Thu, 17 Oct 2013 16:50:24 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Oct 2013 09:50:24 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <525F8CD4.4010206@tarent.de> Date: Thu, 17 Oct 2013 09:50:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A129F9E-2671-466E-BD17-79C99E7B7D68@oracle.com> References: <062.d017355f67119a11f17037e9648b6c73@tools.ietf.org> <077.abb808069ceda9b379423aae2aca861e@tools.ietf.org> <74f68bbfec8248798a976dfd0cb7cfd8@BN1PR04MB392.namprd04.prod.outlook.com> <525F8CD4.4010206@tarent.de> To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim@ietf.org Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:50:35 -0000 Regarding password. No it wouldn't make sense for SCIM to have an = authentication function. HTTP already has these mechanisms. = Authentication should involve much more than simple value match for an = attribute. For example most HTTP servers have some sort of access = policy which intercepts requests and forces authentication. Once = authenticated, a session context is established. That context should = already be available to the SCIM service. You may be thinking of LDAP which is analogous to HTTP. (IOW LDAP is = not working at the same level as a REST service). My feeling is that passwords should probably be treated as write-only = (the actual value is stored as a hash). I think it is reasonable to = permit a exact match compare operation which is more likely used for = password management (e.g. values in a possible passwordHistory set of = values). It could be used as a "poor-man's" authenticator, but in = general my feeling is this is a bad practice. It may also be reasonable for an access management to be able to call = the SCIM service provider in a privileged way to be able to confirm = password matches using a GET as you suggest below. Rather then SCIM = providing an authentication "function", SCIM simply acts as an identity = data provider (not unlike a SQL database). The difference is that the = client is making the authentication decisions, not the SCIM SP. The = authentication system may also use SCIM to check other items like login = attempts and other things, not to mention comparing other authentication = factors. That said, all of this is currently out of scope -- though = I'm open to working on proposing some standard schema here. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-17, at 12:08 AM, Thorsten Ro=DFner = wrote: > The "returned" option seems to me very reasonable and a good solution = to > avoid collecting all complex attributes on a standard request of the = the > Users resource, while we should stay with all the fields (that are > returned today) in the default setting. >=20 > Though I would like to understand in this context the "index" option > when it comes to that password field (as mentioned in ticket #47). Is = it > intended by SCIM to have something like an "authenticate user" = function > by performing a >=20 > GET /Users?filter=3Did eq "someID" AND password eq "somePassword" >=20 > request? >=20 > The index option - without digging into details - seems to > overcomplicate things and could cause interop problems. >=20 > Thorsten >=20 > Am 16.10.2013 23:20, schrieb Kelly Grizzle: >> Does anyone have any problems with defaulting the Group.members = attribute as being returned by default? Any objections to closing this = ticket with the change suggested in ticket #10? >>=20 >> --Kelly >>=20 >>=20 >> -----Original Message----- >> From: scim issue tracker [mailto:trac+scim@tools.ietf.org]=20 >> Sent: Wednesday, October 02, 2013 10:35 AM >> To: draft-ietf-scim-api@tools.ietf.org; Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] #2: Add pagination capability to plural Resource = attributes >>=20 >> #2: Add pagination capability to plural Resource attributes >>=20 >>=20 >> Comment (by kelly.grizzle@sailpoint.com): >>=20 >> General consensus so far has been that paginating on plural resource = attributes would over-complicate things. The worry about large groups = could be alleviated by implementing a suggested change in ticket #10 = where each schema attribute can designate when it is returned: >>=20 >> "returned"=3D"always"|"never"|"default"|"request" >>=20 >> For backwards compatibility, I suggest that Group.members remains as = "default", but SP's can optionally change this to "request" if it is = problematic. >>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Thu Oct 17 09:52:28 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641B621F9B5A for ; Thu, 17 Oct 2013 09:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jno8CIx5OKdJ for ; Thu, 17 Oct 2013 09:52:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E286411E8274 for ; Thu, 17 Oct 2013 09:52:12 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9HGqC3V017706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Oct 2013 16:52:12 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 r9HGqAh9017271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 16:52:11 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9HGqA74004724; Thu, 17 Oct 2013 16:52:10 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Oct 2013 09:52:10 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <525FC2AF.5060002@tarent.de> Date: Thu, 17 Oct 2013 09:52:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <525FC2AF.5060002@tarent.de> To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim@ietf.org Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:52:28 -0000 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-17, at 3:57 AM, Thorsten Ro=DFner = wrote: > Hi all >=20 > from my perspective the ticket covers a very reasonable enhancement, = as > long as it is a "SHOULD" in the standard. >=20 > It would not add complexity to simple SCIM implementations, while > clients that send a requests to a server that does not support the > attribute exclusion still should retrieve data they can work with... = if > they do not perform some sort of strict schema validation against a > stripped-down schema. >=20 > What do you think? >=20 > Thanks > Thorsten > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Thu Oct 17 09:54:47 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835721F960E for ; Thu, 17 Oct 2013 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9UA5dFhIsB2 for ; Thu, 17 Oct 2013 09:54:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAC021F9C72 for ; Thu, 17 Oct 2013 09:54:37 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9HGsZXa020118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Oct 2013 16:54:36 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 r9HGsXx7010800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Oct 2013 16:54:34 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9HGsXie022543; Thu, 17 Oct 2013 16:54:33 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Oct 2013 09:54:33 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <525FD366.100@mnt.se> Date: Thu, 17 Oct 2013 09:54:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43433F13-6840-4CF0-818C-A12C4DF69B11@oracle.com> References: <525FBFB7.7020408@tarent.de> <525FC3EB.6020608@mnt.se> <525FC6FC.8080505@tarent.de> <525FD366.100@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim@ietf.org Subject: Re: [scim] Discussing the ticket queue: #1 & general handling X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:54:47 -0000 I must admit, I don't have much interest. It may be related to Ticket = #11 though. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-17, at 5:09 AM, Leif Johansson wrote: > On 10/17/2013 01:16 PM, Thorsten Ro=DFner wrote: >> Thanks for the quick reply. >>=20 >> To make my point of view more explict: I do not see the need for the >> enhancement. I would vote for a "won't fix" and closing the ticket. >>=20 >> Cheers >> Thorsten >>=20 >>=20 >> Am 17.10.2013 13:03, schrieb Leif Johansson: >>> On 10/17/2013 12:45 PM, Thorsten Ro=DFner wrote: >>>> Hello everybody, >>>>=20 >>>> the first ticket in the IETF tracker for SCIM >>>> (http://trac.tools.ietf.org/wg/scim/trac/ticket/1) has been there = for 13 >>>> months. Nobody answered on the 11 months old comment that asked for >>>> positive feedback to the enhancement. Can the ticket be closed? Or = is >>>> there a process to follow? >>>>=20 >>>> Thanks >>>> Thorsten >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> The process is that if you have suggestions you post a comment (like = you >>> just did) with a suggestion for how to resolve the ticket. Hopefully >>> that starts the discussion going! >>> _______________________________________________ >>> 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 > Can you visit the trac-site and add that as a comment? That way we can > keep track of things... > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Thu Oct 17 10:07:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8BD21F9B0D for ; Thu, 17 Oct 2013 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve8XgVVysMoj for ; Thu, 17 Oct 2013 10:07:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3D21F9B25 for ; Thu, 17 Oct 2013 10:07:25 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 17 Oct 2013 17:07:22 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Thu, 17 Oct 2013 17:07:21 +0000 From: Kelly Grizzle To: Phil Hunt , =?iso-8859-1?Q?Thorsten_Ro=DFner?= Thread-Topic: [scim] Ticket #3 - Exclude Attributes explicitly Thread-Index: AQHOyyfHImcsoDIeCUmmvJ7DScvz3Zn5HCCAgAAEO7A= Date: Thu, 17 Oct 2013 17:07:21 +0000 Message-ID: <114ba48e23474f57a433facb4790c80a@BN1PR04MB392.namprd04.prod.outlook.com> References: <525FC2AF.5060002@tarent.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0AE80AD20057CA0AE80C1F x-originating-ip: [173.226.147.242] x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(13464003)(199002)(189002)(377454003)(53754006)(377424004)(51704005)(74706001)(76482001)(85306002)(81542001)(81342001)(74662001)(77982001)(59766001)(54316002)(56776001)(80022001)(83072001)(74316001)(31966008)(74502001)(47446002)(63696002)(66066001)(65816001)(79102001)(74876001)(15975445006)(69226001)(81686001)(76786001)(76796001)(76576001)(81816001)(33646001)(74366001)(15974865002)(47976001)(54356001)(80976001)(56816003)(77096001)(19580395003)(83322001)(19580405001)(4396001)(51856001)(50986001)(46102001)(47736001)(49866001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:173.226.147.242; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:07:35 -0000 +1 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Thursday, October 17, 2013 11:52 AM To: Thorsten Ro=DFner Cc: scim@ietf.org Subject: Re: [scim] Ticket #3 - Exclude Attributes explicitly +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-17, at 3:57 AM, Thorsten Ro=DFner wrote: > Hi all >=20 > from my perspective the ticket covers a very reasonable enhancement,=20 > as long as it is a "SHOULD" in the standard. >=20 > It would not add complexity to simple SCIM implementations, while=20 > clients that send a requests to a server that does not support the=20 > attribute exclusion still should retrieve data they can work with...=20 > if they do not perform some sort of strict schema validation against a=20 > stripped-down schema. >=20 > What do you think? >=20 > Thanks > Thorsten > _______________________________________________ > 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 phil.hunt@oracle.com Thu Oct 17 10:12:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A911E828E for ; Thu, 17 Oct 2013 10:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfC4zlbfIAw5 for ; Thu, 17 Oct 2013 10:12:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA73211E82B1 for ; Thu, 17 Oct 2013 10:12:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9HHCaAw007227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 Oct 2013 17:12:37 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 r9HHCawt011021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Oct 2013 17:12:36 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9HHCa1l015587 for ; Thu, 17 Oct 2013 17:12:36 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Oct 2013 10:12:35 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_9CE573A2-AD4C-435D-911F-A32F14CE2F45" Message-Id: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> Date: Thu, 17 Oct 2013 10:12:34 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:12:55 -0000 --Apple-Mail=_9CE573A2-AD4C-435D-911F-A32F14CE2F45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In a patch operation, there may actually be multiple sub-operations that = occur to complete a patch. For example, the patch may specify that all = of the current members of a group must be removed and replaced with a = new set of values. If the server has an error and only partially removes the members, what = is the expected result? 1. Treat patches as atomic and roll-back to previous state and return = an error 2. Return the partially updated group with an error message (the patch = may not be completed) 3. Return a partially updated group with all operations attempted (adds = are added but deletes may not be complete) I recognize that some implementations may find #1 to be very difficult. = However, I think passing partial results may only create bigger problems = for the client. =20 I notice that Bulk has some discussion on failonerror. But I think this = applies to specific SCIM operations being treated as pass/fail atomic = operations each rather than allowing partial errors within a PATCH = within a bulk. Can anybody clarify the intent here? Should we log a ticket? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_9CE573A2-AD4C-435D-911F-A32F14CE2F45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
= --Apple-Mail=_9CE573A2-AD4C-435D-911F-A32F14CE2F45-- From t.rossner@tarent.de Fri Oct 18 00:39:05 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2521F9F1B for ; Fri, 18 Oct 2013 00:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQnJ-NHnzdiC for ; Fri, 18 Oct 2013 00:38:56 -0700 (PDT) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id AF90A21F9E76 for ; Fri, 18 Oct 2013 00:38:55 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id k11so1705529eaj.14 for ; Fri, 18 Oct 2013 00:38: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7kXP629ed4c7c8EtC+k/XzmDq+zmFENlY7HljEDonUU=; b=nF2s9R+RGlg2kJvXJGMTAL9EZFWl0VlIW48n5rWnaD6LicOSjkJqBcDlzBszUHvnBq ITJf88/NJmj9htYkB8yN7KwrUG7U08kDXw4iTYSZmgQlt3m8ujBun9ck0aGaDpXAVx5d eWqAKpzo3p9QXh7lFjAUwR/VvhouoMbF4J9qqASlnR1l2MsTX/oSFH7sY57rXfGIG9Zj E8/HmFBuvqeBfB/TqZ0eT1koN84hzwRF0cLG7DB57GC+cp91lop5E3jZqG6+DLEosLiG +/vNR5F/JV4meNmlJZtPZotGJl2bQFFJ94L7RlQlgiAJ3dpCo6wcnvZwMAw9K47dj6Gl /XjA== X-Gm-Message-State: ALoCoQnYNxUTkIpR2cReIZvhGuViioBt0amtmzHHGJxKACJrNn7/DvO67Qy4WkAuuAKlqW5G1MRm X-Received: by 10.204.234.8 with SMTP id ka8mr242784bkb.5.1382081934142; Fri, 18 Oct 2013 00:38:54 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id pk7sm136540bkb.2.2013.10.18.00.38.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 00:38:53 -0700 (PDT) Message-ID: <5260E583.3020307@tarent.de> Date: Fri, 18 Oct 2013 09:38:43 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Phil Hunt References: <062.d017355f67119a11f17037e9648b6c73@tools.ietf.org> <077.abb808069ceda9b379423aae2aca861e@tools.ietf.org> <74f68bbfec8248798a976dfd0cb7cfd8@BN1PR04MB392.namprd04.prod.outlook.com> <525F8CD4.4010206@tarent.de> <5A129F9E-2671-466E-BD17-79C99E7B7D68@oracle.com> In-Reply-To: <5A129F9E-2671-466E-BD17-79C99E7B7D68@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 07:39:05 -0000 Am 17.10.2013 18:50, schrieb Phil Hunt: > Regarding password. No it wouldn't make sense for SCIM to have an authentication function. I agree. > My feeling is that passwords should probably be treated as write-only (the actual value is stored as a hash). I think it is reasonable to permit a exact match compare operation which is more likely used for password management (e.g. values in a possible passwordHistory set of values). It could be used as a "poor-man's" authenticator, but in general my feeling is this is a bad practice. I also agree. I see the need that we add the explicit information that the password attribute can only be searched with the "eq" parameter to the Draft. I'm still not in favor of having a generic "index" option on each field. > It may also be reasonable for an access management to be able to call the SCIM service provider in a privileged way to be able to confirm password matches using a GET as you suggest below. But this priviledged way would be against SCIM specification as of today (password: "This value MUST never be returned by a Service Provider in any form.")? Thorsten From t.rossner@tarent.de Fri Oct 18 00:59:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4821F9F5B for ; Fri, 18 Oct 2013 00:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXS2jVVBhSXL for ; Fri, 18 Oct 2013 00:59:05 -0700 (PDT) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id D97F921F9FB5 for ; Fri, 18 Oct 2013 00:58:59 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so1711529eae.37 for ; Fri, 18 Oct 2013 00:58:58 -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=59BsbjcKwg6q/xkqulp7fyOIYoKnSSQsIEoQmGHWchE=; b=hLx7KzMWohusMvUZ72U+SyIMFuEKwtukDJT1Ojcg1sY2UJsQkQ6PhNq/dfdNSwTOqM j/+WhPTI6Arpq08RQx3iksIB587lK1+6FBFbviLxYuWQ8YL0XEernsqPgdk8svz478PZ AoWQj2mr7oyWXBthpTzPH1iy1JxTlFZDreDzhrr25TPzi1pXFTUMv869Z0oWfHzlXAUu TGV9qvPLcpQPmxM/G8i+SspLZV6K1M/O3BStQicaaoqintzKmygs5TaHroSHpjR6wZgc YRsycgvraDWG69/EwUuWRIhih1bZAwdVzoj4UKJjOVvDgHxJDbUPZgu6IVsOZOF3+DaJ tSmw== X-Gm-Message-State: ALoCoQnsqt3qJxVBAjdEEqezIlzab+lzwtB0dT6/7caJQ7pMdzDb+CBUpuXEqRpPesdfd5/Eds26 X-Received: by 10.204.121.201 with SMTP id i9mr254506bkr.13.1382083137970; Fri, 18 Oct 2013 00:58:57 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id pk7sm167865bkb.2.2013.10.18.00.58.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 00:58:57 -0700 (PDT) Message-ID: <5260EA37.9010002@tarent.de> Date: Fri, 18 Oct 2013 09:58:47 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <2091506392.12322044.1382020640039.JavaMail.zimbra@psu.edu> In-Reply-To: <2091506392.12322044.1382020640039.JavaMail.zimbra@psu.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Add TTY or TDD to canonical types for phoneNumbers. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 07:59:10 -0000 Am 17.10.2013 16:37, schrieb Steve Moyer: > I think a more proper definition for the "phoneNumber" field's type would be: > "A numerical address that specifies an end-point connected to the public telephony infrastructure". As a non native speaker this sounds to me more like a definition for the "phoneNumber" field not for the phoneNumber's type field? > But there are actually problems with the existing set of phoneNumber types ... fax, for instance, also describes "on what kind of device". I've thrown together the following table to highlight some of the oddities (I've tried to put implied characteristics in parenthesis): > > +------------------------------+-------------+--------------------+---------+ > |Canonical types (phoneNumber) | what | where | how | > +------------------------------+-------------+--------------------+---------+ > | fax | fax | ? | (modem) | > | home | (telephone) | home | (voice) | > | mobile | (telephone) | (current location) | voice | > | | (telephone) | (current location) | text | > | other | ? | ? | ? | > | pager | pager | ? | (text) | > | work | (telephone) | work | (voice) | > +------------------------------+-------------+--------------------+---------+ I agree that for the "fax" option it would be helpful to have a differentiation between work-fax and private-fax, but I don't think we should get into full details for all cases. That would cause us to have work-mobile / private-mobile, work-pager / private-pager etc. We might even have to differentiate if a mobile device is able to receive MMS beside text messages or if your landline phone can receive text messages as well. IMHO the SCIM standard should stick to the 80 side of the pareto principle. >From what I understood from your usecase just adding your custom types should be an easy way to solve the problem? Thorsten > > There's a lot of ambiguity in what each "type" really means, and if varies from "where the device is", "what the device is" and "how can I reach the end-point. If your boss has two "phoneNumber" objects with the type "fax" as part of his User attributes, and he tells you "That document has to be signed today or you're fired - send it to my home fax machine immediately", what do you do? > > My "emergency alerts" use case could be considered a special case, and I have no issue creating extensions as needed (we've already done it for other attributes) or adding producer specific values for type. I would however submit that the general use case of "notify a user" is pretty common (reviewing the use-case document is on my to-do list and I'll give more specifics then). For those of us in the U.S., the ADA (http://www.ada.gov/) governs what steps we've got to take to adapt our services for those with disabilities. Most of us are familiar with the section 508 rules for making website's available to the blind, but our organization has other guidelines we have to follow related to telephony. > > I'll let other comment for a few days, and develop whatever extensions I need to make this work, but I think the specification should at least address the implied operation of each phoneNumber type as shown in the table above. I'll shut up now ... what do others think? > > Steve > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From t.rossner@tarent.de Fri Oct 18 01:51:49 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5821F9C46 for ; Fri, 18 Oct 2013 01:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLLGG4yUpXYc for ; Fri, 18 Oct 2013 01:51:43 -0700 (PDT) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5821F8E2D for ; Fri, 18 Oct 2013 01:51:38 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so1766947eaj.13 for ; Fri, 18 Oct 2013 01:51:37 -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; bh=cqgy/YnK5Zl7Bc+m4FN3T2VzQZ1paSYSIVexuEvO5Rs=; b=Qywvc4ZqH7QfpSbBMhU84/5/0Qp++3jmhvhDsfuzZvXlUffRvkHJkKPYozPwX7EWiZ MxVC3ZE18CTUNvtSYCvIDefOLnu26iYzz3FOThrDq1wYug6dGZorM11a1LpxIcfjPgHZ dwtOFtRObxDXX9rmoXVMbG5tmCfGpOFHzyhM7GHk7mxMw3O/3AurWJKu0FQUWZiUpnLT rGLZsd5EuvSqDDpjLy04BTNuw78tBx7EOoenLPCK6g+gVeXbDRpWW3jyAyLoe3AGSR6P WRXP0/Dpw80oT2/WBmnBf47N562vwProrXCQEN9mSa4tlok62K/YaRlOakVsgtveAAEm JMAQ== X-Gm-Message-State: ALoCoQmBc8rby+5dGxu1gY6oXYIrCvg3G6G0GRs0FiXzDRW8qEFBt3+Aq42ACHRxhv9cpMQabXNa X-Received: by 10.204.71.133 with SMTP id h5mr290488bkj.0.1382086297616; Fri, 18 Oct 2013 01:51:37 -0700 (PDT) Received: from [172.26.15.200] (fb-n15-11.unbelievable-machine.net. [94.198.62.204]) by mx.google.com with ESMTPSA id zl3sm243677bkb.4.2013.10.18.01.51.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 01:51:36 -0700 (PDT) Message-ID: <5260F68F.9010005@tarent.de> Date: Fri, 18 Oct 2013 10:51:27 +0200 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: scim@ietf.org References: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> In-Reply-To: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------080402080806050301050403" Subject: Re: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 08:51:49 -0000 This is a multi-part message in MIME format. --------------080402080806050301050403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As long as the response clearly states which atomic operations failed / have not been conducted I am also in favor of #2 or #3. I even would prefer #3 over #2 then. Thorsten Am 17.10.2013 19:12, schrieb Phil Hunt: > If the server has an error and only partially removes the members, > what is the expected result? > > 1. Treat patches as atomic and roll-back to previous state and return > an error > 2. Return the partially updated group with an error message (the > patch may not be completed) > 3. Return a partially updated group with all operations attempted > (adds are added but deletes may not be complete) > --------------080402080806050301050403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As long as the response clearly states which atomic operations failed / have not been conducted I am also in favor of #2 or #3. I even would prefer #3 over #2 then.

Thorsten

Am 17.10.2013 19:12, schrieb Phil Hunt:
If the server has an error and only partially removes the members, what is the expected result?

1.  Treat patches as atomic and roll-back to previous state and return an error
2.  Return the partially updated group with an error message (the patch may not be completed)
3.  Return a partially updated group with all operations attempted (adds are added but deletes may not be complete)


--------------080402080806050301050403-- From kelly.grizzle@sailpoint.com Fri Oct 18 10:14:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA14211E832B for ; Fri, 18 Oct 2013 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLG2zanvlbLa for ; Fri, 18 Oct 2013 10:14:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 301A011E8291 for ; Fri, 18 Oct 2013 10:14:48 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 18 Oct 2013 17:14:41 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Fri, 18 Oct 2013 17:14:41 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= , "scim@ietf.org" Thread-Topic: [scim] Error handling in PATCH (and BULK) Thread-Index: AQHOy1wlt4aoZYgmcEODlLsKL+6Egpn6J72AgACL/pA= Date: Fri, 18 Oct 2013 17:14:40 +0000 Message-ID: <14be763ae6614ad19f06954c6640dff0@BN1PR04MB392.namprd04.prod.outlook.com> References: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> <5260F68F.9010005@tarent.de> In-Reply-To: <5260F68F.9010005@tarent.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 10151A190057EA10151B66 x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(76482001)(77982001)(74662001)(59766001)(74706001)(81542001)(81342001)(15202345003)(54316002)(56776001)(85306002)(74316001)(63696002)(19300405004)(83072001)(80022001)(74502001)(47446002)(65816001)(31966008)(79102001)(15975445006)(74876001)(69226001)(81686001)(76786001)(76796001)(76576001)(81816001)(74366001)(33646001)(47976001)(4396001)(54356001)(77096001)(56816003)(19580405001)(47736001)(16236675002)(53806001)(50986001)(51856001)(19580395003)(83322001)(80976001)(49866001)(46102001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_14be763ae6614ad19f06954c6640dff0BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:14:55 -0000 --_000_14be763ae6614ad19f06954c6640dff0BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I recognize that some implementations may find #1 to be very difficult. = However, I think > passing partial results may only create bigger problems for the client. +1. This will make things much easier from the client perspective. > Bulk has some discussion on failonerror. But I think this applies to spe= cific SCIM operations > being treated as pass/fail atomic operations each rather than allowing pa= rtial errors within a > PATCH within a bulk. Correct. The multiple error handling in Bulk deals with each operation, no= t within a PATCH operation. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Tho= rsten Ro=DFner Sent: Friday, October 18, 2013 3:51 AM To: scim@ietf.org Subject: Re: [scim] Error handling in PATCH (and BULK) As long as the response clearly states which atomic operations failed / hav= e not been conducted I am also in favor of #2 or #3. I even would prefer #3= over #2 then. Thorsten Am 17.10.2013 19:12, schrieb Phil Hunt: If the server has an error and only partially removes the members, what is = the expected result? 1. Treat patches as atomic and roll-back to previous state and return an e= rror 2. Return the partially updated group with an error message (the patch may= not be completed) 3. Return a partially updated group with all operations attempted (adds ar= e added but deletes may not be complete) --_000_14be763ae6614ad19f06954c6640dff0BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> I recognize that some implementations may find #1 to be very difficu= lt.  However, I think

> passing partial results may only create bigger = problems for the client.  

 

+1.  This will make things much easier from= the client perspective.

 

 

> Bulk has some discussion on failonerror.  = But I think this applies to specific SCIM operations

> being treated as pass/fail atomic operations ea= ch rather than allowing partial errors within a

> PATCH within a bulk.

 <= /p>

Correct.  The multiple error handling in Bulk d= eals with each operation, not within a PATCH operation.

 <= /p>

--Kelly

 <= /p>

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Thorsten Ro=DFner
Sent: Friday, October 18, 2013 3:51 AM
To: scim@ietf.org
Subject: Re: [scim] Error handling in PATCH (and BULK)

 

As long as the response clearly states which atomic = operations failed / have not been conducted I am also in favor of #2 or #3.= I even would prefer #3 over #2 then.

Thorsten

Am 17.10.2013 19:12, schrieb Phil Hunt:

If the server has an error and only partially remove= s the members, what is the expected result?

 

1.  Treat patches as atomic and roll-back to pr= evious state and return an error

2.  Return the partially updated group with an = error message (the patch may not be completed)

3.  Return a partially updated group with all o= perations attempted (adds are added but deletes may not be complete)

 

 

--_000_14be763ae6614ad19f06954c6640dff0BN1PR04MB392namprd04pro_-- From phil.hunt@oracle.com Fri Oct 18 10:16:20 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB111E8291 for ; Fri, 18 Oct 2013 10:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35hUVuOO6om4 for ; Fri, 18 Oct 2013 10:16:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAD711E81CB for ; Fri, 18 Oct 2013 10:16:15 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9IHGDhe010103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Oct 2013 17:16:14 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9IHGCUm003531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Oct 2013 17:16:12 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9IHGCKQ003088; Fri, 18 Oct 2013 17:16:12 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Oct 2013 10:16:11 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6EF0FBFC-8BC3-4BE2-93E6-6CC31F372812" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <14be763ae6614ad19f06954c6640dff0@BN1PR04MB392.namprd04.prod.outlook.com> Date: Fri, 18 Oct 2013 10:16:10 -0700 Message-Id: References: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> <5260F68F.9010005@tarent.de> <14be763ae6614ad19f06954c6640dff0@BN1PR04MB392.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: =?iso-8859-1?Q?Thorsten_Ro=DFner?= , "scim@ietf.org" Subject: Re: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:16:20 -0000 --Apple-Mail=_6EF0FBFC-8BC3-4BE2-93E6-6CC31F372812 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Just to be clear. I am favouring #1 which is I think what Kelly is = indicating correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-18, at 10:14 AM, Kelly Grizzle = wrote: > > I recognize that some implementations may find #1 to be very = difficult. However, I think > > passing partial results may only create bigger problems for the = client. =20 > =20 > +1. This will make things much easier from the client perspective. > =20 > =20 > > Bulk has some discussion on failonerror. But I think this applies = to specific SCIM operations > > being treated as pass/fail atomic operations each rather than = allowing partial errors within a > > PATCH within a bulk. > =20 > Correct. The multiple error handling in Bulk deals with each = operation, not within a PATCH operation. > =20 > --Kelly > =20 > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Thorsten Ro=DFner > Sent: Friday, October 18, 2013 3:51 AM > To: scim@ietf.org > Subject: Re: [scim] Error handling in PATCH (and BULK) > =20 > As long as the response clearly states which atomic operations failed = / have not been conducted I am also in favor of #2 or #3. I even would = prefer #3 over #2 then. >=20 > Thorsten >=20 > Am 17.10.2013 19:12, schrieb Phil Hunt: > If the server has an error and only partially removes the members, = what is the expected result? > =20 > 1. Treat patches as atomic and roll-back to previous state and return = an error > 2. Return the partially updated group with an error message (the = patch may not be completed) > 3. Return a partially updated group with all operations attempted = (adds are added but deletes may not be complete) > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_6EF0FBFC-8BC3-4BE2-93E6-6CC31F372812 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Just = to be clear.  I am favouring #1 which is I think what Kelly is = indicating correct?


On 2013-10-18, at 10:14 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

> I recognize that some implementations = may find #1 to be very difficult.  However, I = think
> passing partial = results may only create bigger problems for the client. =  
+1.  This = will make things much easier from the client = perspective.
> Bulk has = some discussion on failonerror.  But I think this applies to = specific SCIM operations
> = being treated as pass/fail atomic operations each rather than allowing = partial errors within a
> = PATCH within a bulk.
 
 
--Kelly
 
 
From: scim-bounces@ietf.org = [mailto:scim-bounces@ietf.org] On Behalf Of Thorsten = Ro=DFner
Sent: Friday, October 18, 2013 = 3:51 AM
To: scim@ietf.org
Subject: Re: [scim] Error handling = in PATCH (and BULK)
 
As long as the response clearly states which atomic operations = failed / have not been conducted I am also in favor of #2 or #3. I even = would prefer #3 over #2 then.

Thorsten

Am 17.10.2013 = 19:12, schrieb Phil Hunt:
If the server has an error and only partially removes the = members, what is the expected result?
 
1.  Treat patches as atomic and roll-back to = previous state and return an error
2.  Return the partially updated group with an = error message (the patch may not be = completed)
3. =  Return a partially updated group with all operations attempted = (adds are added but deletes may not be = complete)
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_6EF0FBFC-8BC3-4BE2-93E6-6CC31F372812-- From kelly.grizzle@sailpoint.com Fri Oct 18 10:17:29 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F27211E8311 for ; Fri, 18 Oct 2013 10:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxYKNzdbieuI for ; Fri, 18 Oct 2013 10:17:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6433E11E8320 for ; Fri, 18 Oct 2013 10:17:24 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 18 Oct 2013 17:17:22 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.76]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.6]) with mapi id 15.00.0785.001; Fri, 18 Oct 2013 17:17:22 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Error handling in PATCH (and BULK) Thread-Index: AQHOy1wlt4aoZYgmcEODlLsKL+6Egpn6J72AgACL/pCAAAEHAIAAAEZw Date: Fri, 18 Oct 2013 17:17:21 +0000 Message-ID: <317ac52a53d740099f64fcb31e835152@BN1PR04MB392.namprd04.prod.outlook.com> References: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> <5260F68F.9010005@tarent.de> <14be763ae6614ad19f06954c6640dff0@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 10178E6D0057EA10178FBA x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(199002)(189002)(377424004)(377454003)(76482001)(77982001)(74662001)(59766001)(74706001)(81542001)(81342001)(15202345003)(54316002)(56776001)(85306002)(74316001)(63696002)(19300405004)(83072001)(80022001)(74502001)(47446002)(65816001)(31966008)(79102001)(15975445006)(74876001)(69226001)(81686001)(76786001)(76796001)(76576001)(81816001)(16601075003)(74366001)(33646001)(47976001)(4396001)(54356001)(77096001)(56816003)(19580405001)(47736001)(16236675002)(53806001)(50986001)(51856001)(19580395003)(83322001)(19609705001)(80976001)(49866001)(46102001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_317ac52a53d740099f64fcb31e835152BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: =?iso-8859-1?Q?Thorsten_Ro=DFner?= , "scim@ietf.org" Subject: Re: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:17:29 -0000 --_000_317ac52a53d740099f64fcb31e835152BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct. I am +1 for #1. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Friday, October 18, 2013 12:16 PM To: Kelly Grizzle Cc: Thorsten Ro=DFner; scim@ietf.org Subject: Re: [scim] Error handling in PATCH (and BULK) Just to be clear. I am favouring #1 which is I think what Kelly is indicat= ing correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-18, at 10:14 AM, Kelly Grizzle > wrote: > I recognize that some implementations may find #1 to be very difficult. = However, I think > passing partial results may only create bigger problems for the client. +1. This will make things much easier from the client perspective. > Bulk has some discussion on failonerror. But I think this applies to spe= cific SCIM operations > being treated as pass/fail atomic operations each rather than allowing pa= rtial errors within a > PATCH within a bulk. Correct. The multiple error handling in Bulk deals with each operation, no= t within a PATCH operation. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Thorsten Ro=DFner Sent: Friday, October 18, 2013 3:51 AM To: scim@ietf.org Subject: Re: [scim] Error handling in PATCH (and BULK) As long as the response clearly states which atomic operations failed / hav= e not been conducted I am also in favor of #2 or #3. I even would prefer #3= over #2 then. Thorsten Am 17.10.2013 19:12, schrieb Phil Hunt: If the server has an error and only partially removes the members, what is = the expected result? 1. Treat patches as atomic and roll-back to previous state and return an e= rror 2. Return the partially updated group with an error message (the patch may= not be completed) 3. Return a partially updated group with all operations attempted (adds ar= e added but deletes may not be complete) _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_317ac52a53d740099f64fcb31e835152BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Correct.  I am += 1 for #1.

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Friday, October 18, 2013 12:16 PM
To: Kelly Grizzle
Cc: Thorsten Ro=DFner; scim@ietf.org
Subject: Re: [scim] Error handling in PATCH (and BULK)

 

Just to be clear.  I am favouring #1 which is I= think what Kelly is indicating correct?

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

On 2013-10-18, at 10:14 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com>= ; wrote:



> I recogn= ize that some implementations may find #1 to be very difficult.  Howev= er, I think

> passing partial results may only create bigger = problems for the client.  

 

+1.  This will make things much easier from= the client perspective.

 

 

> Bulk has some discussion on failonerror.  = But I think this applies to specific SCIM operations

> being treated as pass/fail atomic operations ea= ch rather than allowing partial errors within a

> PATCH within a bulk.

 <= /p>

Correct.  The multiple error handling in Bulk d= eals with each operation, not within a PATCH operation.

 <= /p>

--Kelly

 <= /p>

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Thorsten Ro=DFner
Sent: Friday, Octo= ber 18, 2013 3:51 AM
To: scim@ietf.org
Subject: Re: [scim= ] Error handling in PATCH (and BULK)

 

As long as the response clearly states which atomic = operations failed / have not been conducted I am also in favor of #2 or #3.= I even would prefer #3 over #2 then.

Thorsten

Am 17.10.2013 19:12, schrieb Phil Hunt:

If the server has an error and only partially remove= s the members, what is the expected result?

 

1.  Treat patches as atomic and roll-back to pr= evious state and return an error

2.  Return the partially updated group with an = error message (the patch may not be completed)

3.  Return a partially updated group with all o= perations attempted (adds are added but deletes may not be complete)

 

 

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

 

--_000_317ac52a53d740099f64fcb31e835152BN1PR04MB392namprd04pro_-- From mdiodati@pingidentity.com Fri Oct 18 12:56:40 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4111E8311 for ; Fri, 18 Oct 2013 12:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrESFYSeW3nQ for ; Fri, 18 Oct 2013 12:56:36 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 566A111E826C for ; Fri, 18 Oct 2013 12:56:34 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUmGSbtQeKuRg1mrlLyYMD18RmZLVJweX@postini.com; Fri, 18 Oct 2013 12:56:34 PDT Received: by mail-ie0-f171.google.com with SMTP id tp5so7217197ieb.2 for ; Fri, 18 Oct 2013 12:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=e7Xwruxq2sAy7Wp4xfS35HUZFVM/gpYwDtavzR/giR4=; b=CeDWMDSTVl6TesIe/kiiKqE547Ok8hMjdb911x5pFMVA+3YzHr/3AqSog+hQM2JMmt ZQrLlA+/mBpOvKktezGJPnEG3A9OMRZaZu6jLdcRqMr27rN89kKLRJeL5laXx42czzQi CcXv7qHogmTxHNxiUCtU7P7F9/CdLM6p6TQJX2DkrkBkS6GCJVnTMNIV31ndXHsvBKK4 lW4Zaki6Ht14BiM/DAYe+aHuxc+EChrT0ihbdlwKtfcpJk04jA/UFGJMZcQEDbaz6n0y wJeDpa5VROOuR/J2PaMz7Mk+aLDihYUlKz+aJJEGik+VPMxcjU0HpZLX9vLg9flOpMEF AEPQ== X-Gm-Message-State: ALoCoQl5GyPsdHYNd+yi3mrQiWvWIwVmt4jddY7nTZbNWnLSH1HJMjy2M10E76oyDV9Mre/3ViitrpRVz7AdeyCnfbKzgqgJCMfBTsoDOE9OS86Rkw1sDtykmz2S3W2SFMSiY/zS+0D9wMrfi5YHpQ2AuiipWOw06Q== X-Received: by 10.50.61.241 with SMTP id t17mr826163igr.28.1382126187202; Fri, 18 Oct 2013 12:56:27 -0700 (PDT) X-Received: by 10.50.61.241 with SMTP id t17mr826151igr.28.1382126187014; Fri, 18 Oct 2013 12:56:27 -0700 (PDT) From: Mark Diodati References: <628CD5E4-B445-4C25-9EF7-166BF8AA53CC@oracle.com> <5260F68F.9010005@tarent.de> <14be763ae6614ad19f06954c6640dff0@BN1PR04MB392.namprd04.prod.outlook.com> <317ac52a53d740099f64fcb31e835152@BN1PR04MB392.namprd04.prod.outlook.com> In-Reply-To: <317ac52a53d740099f64fcb31e835152@BN1PR04MB392.namprd04.prod.outlook.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 thread-index: AQGVPEUjMS3i9s/IcZDikIDcgwH9FQHSit3yApbrd/8CTBlD+wFLFSuymi36jYA= Date: Fri, 18 Oct 2013 13:56:26 -0600 Message-ID: <29619f0a82ab3472a4670ee550b77631@mail.gmail.com> To: Kelly Grizzle , Phil Hunt Content-Type: multipart/alternative; boundary=047d7bdca968699fa004e90954be Cc: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= , scim@ietf.org Subject: Re: [scim] Error handling in PATCH (and BULK) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:56:40 -0000 --047d7bdca968699fa004e90954be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ++1 *From:* Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] *Sent:* Friday, October 18, 2013 11:17 AM *To:* Phil Hunt *Cc:* Thorsten Ro=DFner; scim@ietf.org *Subject:* Re: [scim] Error handling in PATCH (and BULK) Correct. I am +1 for #1. *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] *Sent:* Friday, October 18, 2013 12:16 PM *To:* Kelly Grizzle *Cc:* Thorsten Ro=DFner; scim@ietf.org *Subject:* Re: [scim] Error handling in PATCH (and BULK) Just to be clear. I am favouring #1 which is I think what Kelly is indicating correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-18, at 10:14 AM, Kelly Grizzle wrote: > I recognize that some implementations may find #1 to be very difficult. However, I think > passing partial results may only create bigger problems for the client. +1. This will make things much easier from the client perspective. > Bulk has some discussion on failonerror. But I think this applies to specific SCIM operations > being treated as pass/fail atomic operations each rather than allowing partial errors within a > PATCH within a bulk. Correct. The multiple error handling in Bulk deals with each operation, not within a PATCH operation. --Kelly *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf Of *Thorsten Ro=DFner *Sent:* Friday, October 18, 2013 3:51 AM *To:* scim@ietf.org *Subject:* Re: [scim] Error handling in PATCH (and BULK) As long as the response clearly states which atomic operations failed / have not been conducted I am also in favor of #2 or #3. I even would prefer #3 over #2 then. Thorsten Am 17.10.2013 19:12, schrieb Phil Hunt: If the server has an error and only partially removes the members, what is the expected result? 1. Treat patches as atomic and roll-back to previous state and return an error 2. Return the partially updated group with an error message (the patch may not be completed) 3. Return a partially updated group with all operations attempted (adds are added but deletes may not be complete) _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --047d7bdca968699fa004e90954be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

++1

=A0

From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Friday, October 18, 2013 11:17 AM
To: Phil Hunt
<= b>Cc: Thorsten Ro=DFner; scim@ietf.org=
Subject: Re: [scim] Error handling in PATCH (and BULK)

=A0

Correct.=A0 I am +1 for #1.

=A0

From: Phil Hunt [mailto:phil.hunt@o= racle.com]
Sent: Friday, October 18, 2013 12:16 PM
To: Kelly Grizzle<= br>Cc: Thorsten Ro=DFner; scim@ietf= .org
Subject: Re: [scim] Error handling in PATCH (and BULK)

=A0

Just to be= clear. =A0I am favouring #1 which is I think what Kelly is indicating corr= ect?

=A0

Phil

=

=A0

@independentid<= /span>

phil.hunt@oracle.com

<= /div>

=A0

On 2013-10-18, at 10:14 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:




>=A0I recognize that some implementations may find #1 to be very= difficult. =A0However, I think

> passing partial results may only cre= ate bigger problems for the client. =A0

=A0

+1.=A0 This will make things muc= h easier from the client perspective.

=A0

= =A0

> Bulk has some discussion on f= ailonerror. =A0But I think this applies to specific SCIM operations

> being treated as pass/fail atomic operations each rather than allowing= partial errors within a

> PATCH wi= thin a bulk.

Correct.=A0 The multiple error handling i= n Bulk deals with each operation, not within a PATCH operation.

=A0

--Kelly

=A0

=A0

From:= =A0scim-bounces@ietf.org = [mailto:scim-bounces@ietf.org]=A0= On Behalf Of=A0Thorsten Ro= =DFner
Sent:=A0Friday, October= 18, 2013 3:51 AM
To:=A0scim@ietf.org
Subject:=A0Re: [scim] Error handling in = PATCH (and BULK)

=A0

As long as the response clearly states which atomic operat= ions failed / have not been conducted I am also in favor of #2 or #3. I eve= n would prefer #3 over #2 then.

Thorsten

Am 17.10.2013 19:12, schrieb Phil Hunt:

=

If the server has an error and only partially removes the = members, what is the expected result?

=A0

<= p class=3D"MsoNormal">1. =A0Treat patches as atomic and roll-back to previo= us state and return an error

2. =A0Return the partially updated group with an error message (the patch= may not be completed)

3. =A0Return a partially updat= ed group with all operations attempted (adds are added but deletes may not = be complete)

=A0

=A0

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

=A0=

--047d7bdca968699fa004e90954be-- From leifj@mnt.se Fri Oct 25 06:40:13 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9BD11E8256 for ; Fri, 25 Oct 2013 06:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2jjHdQXOxtz for ; Fri, 25 Oct 2013 06:40:05 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9682B11E82CA for ; Fri, 25 Oct 2013 06:39:58 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id b47so490317eek.2 for ; Fri, 25 Oct 2013 06:39:57 -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=wocD3HW6Xrwbq1Xjm/rmHbiRWnMvtwiL1qrlz84jnG4=; b=DRyvAFpyrr7qr0S+graOc0mVwJNZmzDFp64tB0svSiNOcv2MxL1C5k9t+L1XkzB4fA xrpcEVszciAbWYOuFhLbstBZ88iRgyvIezQuZ62K6joyxqykZtP6hjRyqxJSfWBToXIm C3jt9s+2jOdi3r0GQMw4xV9VVZfsVeQaPBKAp55SW0lVcvgG7T9flxxCLNFgtWGIhS2V xvoGYyIO+5OqZk/CEu56pHv028F/Wv0CaRQLdpO3vlB1+p1PuiI7xkQeQSe2+jKKjYjx EvYhlCNPPlYsuVvGiFCzhrzp96Nt33sB0YUpQ/ULeg5izWGXlNt+eloidnxVeHng5zah zxwg== X-Gm-Message-State: ALoCoQkRCSWYpst7aefF6i2vto2ITuTd/f3w/NcTTwPfw7UOfIlLm6/DIuC7r2mgloNlsOfhEBYD X-Received: by 10.15.35.67 with SMTP id f43mr59885eev.100.1382708397770; Fri, 25 Oct 2013 06:39:57 -0700 (PDT) Received: from ?IPv6:2a01:3f0:1:5:1dc9:4939:e5c:8a0c? ([2a01:3f0:1:5:1dc9:4939:e5c:8a0c]) by mx.google.com with ESMTPSA id f49sm18080488eec.7.2013.10.25.06.39.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 06:39:56 -0700 (PDT) Message-ID: <526A74AB.8000603@mnt.se> Date: Fri, 25 Oct 2013 15:39:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] draft agenda for Vancouver X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:40:14 -0000 Folks, Here is a draft agenda for Vancouver. On the interrim confcalls we've talked about spending most of our time on closing trac issues. Please suggest any other agenda items! Cheers Leif & Morteza Agenda for SCIM IETF88 This time we'll spend most of our time working on the open issue trackers! - Note Well & Agenda Bashing (5min) - Issue Tracker Progress (115min) From phil.hunt@oracle.com Mon Oct 28 10:55:28 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A586611E8290 for ; Mon, 28 Oct 2013 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIC6TDdDZut3 for ; Mon, 28 Oct 2013 10:55:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DB43F11E81A5 for ; Mon, 28 Oct 2013 10:55:20 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9SHtJna028822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 17:55:20 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 r9SHtIvH029411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 17:55:19 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SHtIPN015350 for ; Mon, 28 Oct 2013 17:55:18 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2013 10:55:18 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_7B57D5A5-65AA-4C82-99C0-F00FC88888C6" Message-Id: <6B6508C4-6A13-4A89-A6EE-4327C990081B@oracle.com> Date: Mon, 28 Oct 2013 10:55:53 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] extended objects and searching X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:55:28 -0000 --Apple-Mail=_7B57D5A5-65AA-4C82-99C0-F00FC88888C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kelly, At one point we had a discussion about extensions (e.g. EnterpriseUser). = In draft 02, it seems that meta.resourceType only points to the main = type of the object (e.g. User). Were we going to multi-valued so that = for example, a User with EnterpriseUser would be both "User" and = "EnterpriseUser"? The reason I ask, is we are looking for a way to = search for those Users that are EnterpriseUser objects. This is all related to Ticket 38... http://trac.tools.ietf.org/wg/scim/trac/ticket/38 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_7B57D5A5-65AA-4C82-99C0-F00FC88888C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This is all related = to Ticket 38...

= --Apple-Mail=_7B57D5A5-65AA-4C82-99C0-F00FC88888C6-- From phil.hunt@oracle.com Mon Oct 28 11:27:47 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD97021E80B8 for ; Mon, 28 Oct 2013 11:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNOfRkyTTGQ5 for ; Mon, 28 Oct 2013 11:27:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 855BE21E80A5 for ; Mon, 28 Oct 2013 11:27:09 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9SIR8oB023235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 18:27:09 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SIR7pN019185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 18:27:07 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SIR7uq022302 for ; Mon, 28 Oct 2013 18:27:07 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2013 11:27:06 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_76BC0264-173A-4B6A-85FA-16997FF371B1" Message-Id: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> Date: Mon, 28 Oct 2013 11:27:42 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:27:48 -0000 --Apple-Mail=_76BC0264-173A-4B6A-85FA-16997FF371B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In order to bring Ticket 10 ( = http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the = following is a new schema attribute (Section 11) definition which = defines when an attribute is returned on a query. It defines 4 modes. =20= returned - A value that indicates when an attribute's value is returned = in a SCIM GET operation or in response to a PUT, POST, or PATCH request. = Valid values are: always - The attribute is always returned regardless of the contents of = the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always = returned to identify the SCIM record. never - The attribute is never returned. This is typically used in = RESTful operations where the attribute supports only update operations. = An attribute with "returned" set to "never" MAY be used in a search = filter [[depending on index support]]. default - The attribute is returned in SCIM responses and is returned = when the GET "attributes" parameter [API Sec 3.2.3] is not specified. request - The attribute is returned in response to any SCIM PUT, POST, = or PATCH operations if the attribute was specified by the client (for = example, the attribute was modified). The attribute is returned in a = SCIM GET operation only if specified in the "attributes" parameter [API = Sec 3.2.3]. Please let me know if you agree, or if you have concerns. Note we may need more discussion on the default "returned" values for = some attributes. For now, I'll consult with Kelly and put together a = set of proposed defaults (e.g. "id" is "always").=20 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_76BC0264-173A-4B6A-85FA-16997FF371B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = order to bring Ticket 10 ( http://trac.too= ls.ietf.org/wg/scim/trac/ticket/10 ) to a close, the following is a = new schema attribute (Section 11) definition which defines when an = attribute is returned on a query. It defines 4 modes. =  

  • returned - A value =
that indicates when an attribute's value is returned in a SCIM GET =
operation or in response to a PUT, POST, or PATCH request. Valid values =
are:
    • always - The =
attribute is always returned regardless of the contents of the =
"attributes" parameter [API Sec 3.2.3]. For example, "id" is always =
returned to identify the SCIM record.
    • never - The attribute is never returned. This is typically used in =
RESTful operations where the attribute supports only update operations. =
An attribute with "returned" set to "never" MAY be used in a search =
filter [[depending on index support]].
    • default - The attribute is returned in SCIM =
responses and is returned when the GET "attributes" parameter [API Sec =
3.2.3] is not specified.
    • request - The attribute is returned in response to any SCIM PUT, =
POST, or PATCH operations if the attribute was specified by the client =
(for example, the attribute was modified). The attribute is returned in =
a SCIM GET operation only if specified in the "attributes" parameter =
[API Sec 3.2.3].

Please = let me know if you agree, or if you have = concerns.

Note we may need more discussion on = the default "returned" values for some attributes.  For now, I'll = consult with Kelly and put together a set of proposed defaults (e.g. = "id" is "always"). 

= --Apple-Mail=_76BC0264-173A-4B6A-85FA-16997FF371B1-- From phil.hunt@oracle.com Mon Oct 28 11:46:29 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAE821E80C0 for ; Mon, 28 Oct 2013 11:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvCY67xsCh7o for ; Mon, 28 Oct 2013 11:46:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C8D8A21E80BA for ; Mon, 28 Oct 2013 11:46:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9SIkFFo026828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 18:46:16 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 r9SIkEaR021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 18:46:15 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SIkEU5021352 for ; Mon, 28 Oct 2013 18:46:14 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2013 11:46:14 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D773C827-7D2D-4B97-9AE0-1DE63DC45DDC" Message-Id: Date: Mon, 28 Oct 2013 11:46:49 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:46:29 -0000 --Apple-Mail=_D773C827-7D2D-4B97-9AE0-1DE63DC45DDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - = http://trac.tools.ietf.org/wg/scim/trac/ticket/42 ): 3.2.2.1 Query Enpoints Resource Queries A query MAY be performed against any specific resource endpoint or = resource. For example: Resource (e.g. /Users/{userid}), Resource Type endpoint (e.g. /Users or /Groups) Root Queries A server MAY support queries at the server root (e.g. /) for the purpose = of returning resources of more than one resource type. A search against a server root indicates that ALL resources within the = server SHALL be included subject to filtering. For example, a filter = against 'meta.resourceType' could be used to restrict results to one or = more specific resource types. When processing search operations across endpoints that include more = than one SCIM resource type (e.g. a search from the server root = endpoint), filters MUST be processed in the same fashion as outlined in = Section 3.2.2.2. For filtered attributes that are not part of a = particular resource type, the service provider SHALL treat the attribute = as if there is no attribute value. For example, a presence or equality = filter for an undefined attribute evaluates as FALSE. Please confirm if you agree with this subtle change which makes root = searches optional to the server. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_D773C827-7D2D-4B97-9AE0-1DE63DC45DDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

http://trac.too= ls.ietf.org/wg/scim/trac/ticket/42 ):

3.2.2.1 = Query Enpoints

Resource Queries

A query MAY be performed against any specific = resource endpoint or resource. For example:

    Resource (e.g. = /Users/{userid}),
  • Resource = Type endpoint (e.g. /Users or /Groups)

Root Queries

A server MAY support queries at the = server root (e.g. /) for the purpose of returning resources of more than = one resource type.

A = search against a server root indicates that ALL resources within the = server SHALL be included subject to filtering. For example, a filter = against 'meta.resourceType' could be used to restrict results to one or = more specific resource types.

When processing search operations across = endpoints that include more than one SCIM resource type (e.g. a search = from the server root endpoint), filters MUST be processed in the same = fashion as outlined in Section 3.2.2.2. For filtered attributes that are = not part of a particular resource type, the service provider SHALL treat = the attribute as if there is no attribute value. For example, a presence = or equality filter for an undefined attribute evaluates as = FALSE.


= --Apple-Mail=_D773C827-7D2D-4B97-9AE0-1DE63DC45DDC-- From tonynad@microsoft.com Mon Oct 28 13:47:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EE011E80F7 for ; Mon, 28 Oct 2013 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmbVZBrPNsWc for ; Mon, 28 Oct 2013 13:47:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1033E11E829F for ; Mon, 28 Oct 2013 13:47:49 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 28 Oct 2013 20:47:48 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Mon, 28 Oct 2013 20:47:48 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Proposed resolution - root search optionality (ticket 42) Thread-Index: AQHO1A4JzImYtsAsEEOtCaTqVMVWXpoKlchQ Date: Mon, 28 Oct 2013 20:47:48 +0000 Message-ID: <609a469eb1de420d9a598fcc37c68962@BY2PR03MB189.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0013079544 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(31966008)(74502001)(76786001)(77096001)(76576001)(69226001)(74316001)(46102001)(51856001)(76482001)(47976001)(77982001)(59766001)(47446002)(74662001)(54356001)(79102001)(4396001)(87266001)(63696002)(33646001)(16601075003)(76796001)(56816003)(49866001)(54316002)(53806001)(47736001)(56776001)(16236675002)(81542001)(81342001)(65816001)(80022001)(15975445006)(19609705001)(15202345003)(74876001)(19580395003)(19580405001)(83322001)(74706001)(19300405004)(81686001)(81816001)(50986001)(85306002)(74366001)(80976001)(83072001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB189; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_609a469eb1de420d9a598fcc37c68962BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:47:55 -0000 --_000_609a469eb1de420d9a598fcc37c68962BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Monday, October 28, 2013 11:47 AM To: scim@ietf.org WG Subject: [scim] Proposed resolution - root search optionality (ticket 42) Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - ht= tp://trac.tools.ietf.org/wg/scim/trac/ticket/42 ): 3.2.2.1 Query Enpoints Resource Queries A query MAY be performed against any specific resource endpoint or resource= . For example: * Resource (e.g. /Users/{userid}), * Resource Type endpoint (e.g. /Users or /Groups) Root Queries A server MAY support queries at the server root (e.g. /) for the purpose of= returning resources of more than one resource type. A search against a server root indicates that ALL resources within the serv= er SHALL be included subject to filtering. For example, a filter against 'm= eta.resourceType' could be used to restrict results to one or more specific= resource types. When processing search operations across endpoints that include more than o= ne SCIM resource type (e.g. a search from the server root endpoint), filter= s MUST be processed in the same fashion as outlined in Section 3.2.2.2. For= filtered attributes that are not part of a particular resource type, the s= ervice provider SHALL treat the attribute as if there is no attribute value= . For example, a presence or equality filter for an undefined attribute eva= luates as FALSE. Please confirm if you agree with this subtle change which makes root search= es optional to the server. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_609a469eb1de420d9a598fcc37c68962BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 

From: scim-b= ounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:47 AM
To: scim@ietf.org WG
Subject: [scim] Proposed resolution - root search optionality (ticke= t 42)

 

Proposed tex= t. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - http://trac.t= ools.ietf.org/wg/scim/trac/ticket/42 ):

3.2.2.1 Query Enpoints

Resour= ce Queries

A query MAY be performed against any specific resou= rce endpoint or resource. For example:

  • Resour= ce (e.g. /Users/{userid}),
  • Resour= ce Type endpoint (e.g. /Users or /Groups)

Root Q= ueries

A server MAY support queries at the se= rver root (e.g. /) for the purpose of returning resources of more than one = resource type.

A search against a server root indicates that ALL r= esources within the server SHALL be included subject to filtering. For exam= ple, a filter against 'meta.resourceType' could be used to restrict results to one or more specific resource types.=

When processing search operations acro= ss endpoints that include more than one SCIM resource type (e.g. a search f= rom the server root endpoint), filters MUST be processed in the same fashion as outlined in Section 3.2.2.2. For filtered= attributes that are not part of a particular resource type, the service pr= ovider SHALL treat the attribute as if there is no attribute value. For exa= mple, a presence or equality filter for an undefined attribute evaluates as FALSE.

Pleas= e confirm if you agr= ee with this subtle change which makes root searches optional to the server= .

&nb= sp;

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 

--_000_609a469eb1de420d9a598fcc37c68962BY2PR03MB189namprd03pro_-- From tonynad@microsoft.com Mon Oct 28 13:51:17 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3D411E81E9 for ; Mon, 28 Oct 2013 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbvL-y8jQCAj for ; Mon, 28 Oct 2013 13:51:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id D1F1F11E81E6 for ; Mon, 28 Oct 2013 13:51:09 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB191.namprd03.prod.outlook.com (10.242.36.143) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 28 Oct 2013 20:51:01 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Mon, 28 Oct 2013 20:51:00 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) Thread-Index: AQHO1AtpuDGDJYGsgUaNIrUcKyDNAJoKlh7g Date: Mon, 28 Oct 2013 20:50:59 +0000 Message-ID: References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> In-Reply-To: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0013079544 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(19609705001)(81816001)(76576001)(80976001)(19580395003)(83322001)(19580405001)(85306002)(74366001)(74706001)(16601075003)(56816003)(53806001)(19300405004)(54356001)(74876001)(15202345003)(77096001)(87266001)(83072001)(46102001)(51856001)(74316001)(33646001)(81686001)(15975445006)(56776001)(16236675002)(77982001)(59766001)(79102001)(47446002)(74502001)(47736001)(47976001)(31966008)(81542001)(74662001)(76482001)(4396001)(50986001)(76796001)(76786001)(49866001)(81342001)(54316002)(80022001)(65816001)(63696002)(69226001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB191; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_c67e2b7a5a7245df8d3cb09d26a0a283BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:51:17 -0000 --_000_c67e2b7a5a7245df8d3cb09d26a0a283BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to see the discussion happen on the "default" returned before = closing on this text From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Monday, October 28, 2013 11:28 AM To: scim@ietf.org WG Subject: [scim] Ticket 10 - Ability to mark attributes as sensitive (when a= ttrs are returned) In order to bring Ticket 10 ( http://trac.tools.ietf.org/wg/scim/trac/ticke= t/10 ) to a close, the following is a new schema attribute (Section 11) def= inition which defines when an attribute is returned on a query. It defines = 4 modes. * returned - A value that indicates when an attribute's value is re= turned in a SCIM GET operation or in response to a PUT, POST, or PATCH requ= est. Valid values are: o always - The attribute is always returned regardless of the contents o= f the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always r= eturned to identify the SCIM record. o never - The attribute is never returned. This is typically used in RES= Tful operations where the attribute supports only update operations. An att= ribute with "returned" set to "never" MAY be used in a search filter [[depe= nding on index support]]. o default - The attribute is returned in SCIM responses and is returned = when the GET "attributes" parameter [API Sec 3.2.3] is not specified. o request - The attribute is returned in response to any SCIM PUT, POST,= or PATCH operations if the attribute was specified by the client (for exam= ple, the attribute was modified). The attribute is returned in a SCIM GET o= peration only if specified in the "attributes" parameter [API Sec 3.2.3]. Please let me know if you agree, or if you have concerns. Note we may need more discussion on the default "returned" values for some = attributes. For now, I'll consult with Kelly and put together a set of pro= posed defaults (e.g. "id" is "always"). Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_c67e2b7a5a7245df8d3cb09d26a0a283BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to see the d= iscussion happen on the “default” returned before closing on th= is text

 

From: scim-b= ounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:28 AM
To: scim@ietf.org WG
Subject: [scim] Ticket 10 - Ability to mark attributes as sensitive = (when attrs are returned)

 

In order to bring Ticket 10 ( http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the fol= lowing is a new schema attribute (Section 11) definition which defines when= an attribute is returned on a query. It defines 4 modes.  =

 

·o    always - The attribute is always returned regardless of the contents of=
 the "attributes" parameter [API Sec 3.2.3]. For example, "i=
d" is always returned to identify the SCIM record.
o    never - The attribute is never returned. This is typically used in REST=
ful operations where the attribute supports only update operations. An attr=
ibute with "returned" set to "never" MAY be used in a s=
earch filter [[depending on index support]].
o    default - The attribute is returned in SCIM responses and is returned w=
hen the GET "attributes" parameter [API Sec 3.2.3] is not specifi=
ed.
o    request - The attribute is returned in response to any SCIM PUT, POST, =
or PATCH operations if the attribute was specified by the client (for examp=
le, the attribute was modified). The attribute is returned in a SCIM GET op=
eration only if specified in the "attributes" parameter [API Sec =
3.2.3].

 

Please let me know if you agree, or if you have conc= erns.

 

Note we may need more discussion on the default &quo= t;returned" values for some attributes.  For now, I'll consult wi= th Kelly and put together a set of proposed defaults (e.g. "id" i= s "always"). 

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

--_000_c67e2b7a5a7245df8d3cb09d26a0a283BY2PR03MB189namprd03pro_-- From phil.hunt@oracle.com Mon Oct 28 14:01:01 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C5A11E826B for ; Mon, 28 Oct 2013 14:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVwu62aarOLr for ; Mon, 28 Oct 2013 14:00:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA811E81AC for ; Mon, 28 Oct 2013 14:00:53 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9SL0qmm024737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Oct 2013 21:00: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 r9SL0pro018563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 21:00:52 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SL0p7b018529; Mon, 28 Oct 2013 21:00:51 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2013 14:00:50 -0700 References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-E4FDFDBA-CDFE-45A9-9684-B05B547E48FC Content-Transfer-Encoding: 7bit Message-Id: <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Mon, 28 Oct 2013 14:00:47 -0700 To: Anthony Nadalin X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org WG" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 21:01:01 -0000 --Apple-Mail-E4FDFDBA-CDFE-45A9-9684-B05B547E48FC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tony I recommend we do that right after.=20 First do we agree on values for "returned"? Phil > On Oct 28, 2013, at 13:50, Anthony Nadalin wrote: >=20 > I would like to see the discussion happen on the =E2=80=9Cdefault=E2=80=9D= returned before closing on this text > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ph= il Hunt > Sent: Monday, October 28, 2013 11:28 AM > To: scim@ietf.org WG > Subject: [scim] Ticket 10 - Ability to mark attributes as sensitive (when a= ttrs are returned) > =20 > In order to bring Ticket 10 ( http://trac.tools.ietf.org/wg/scim/trac/tick= et/10 ) to a close, the following is a new schema attribute (Section 11) def= inition which defines when an attribute is returned on a query. It defines 4= modes. =20 > =20 > =C2=B7 returned - A value that indicates when an attribute's value= is returned in a SCIM GET operation or in response to a PUT, POST, or PATCH= request. Valid values are: > o always - The attribute is always returned regardless of the contents o= f the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always re= turned to identify the SCIM record. > o never - The attribute is never returned. This is typically used in RE= STful operations where the attribute supports only update operations. An att= ribute with "returned" set to "never" MAY be used in a search filter [[depen= ding on index support]]. > o default - The attribute is returned in SCIM responses and is returned= when the GET "attributes" parameter [API Sec 3.2.3] is not specified. > o request - The attribute is returned in response to any SCIM PUT, POST= , or PATCH operations if the attribute was specified by the client (for exam= ple, the attribute was modified). The attribute is returned in a SCIM GET op= eration only if specified in the "attributes" parameter [API Sec 3.2.3]. > =20 > Please let me know if you agree, or if you have concerns. > =20 > Note we may need more discussion on the default "returned" values for some= attributes. For now, I'll consult with Kelly and put together a set of pro= posed defaults (e.g. "id" is "always").=20 > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-E4FDFDBA-CDFE-45A9-9684-B05B547E48FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Tony I recommend we do that right afte= r. 

First do we agree on values for "returned"= ?

Phil

On Oct 28, 2013, at 13:50, Anthony Nadalin <<= a href=3D"mailto:tonynad@microsoft.com">tonynad@microsoft.com> wrote:=

=

I would like to see the dis= cussion happen on the =E2=80=9Cdefault=E2=80=9D returned before closing on t= his text

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:28 AM
To: scim@ietf.org WG
Subject: [scim] Ticket 10 - Ability to mark attributes as sensitive (= when attrs are returned)

 

In order to bring Ticket 10 ( http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the foll= owing is a new schema attribute (Section 11) definition which defines when a= n attribute is returned on a query. It defines 4 modes.  

 

<=
!--[if !supportLists]-->=C2=B7=
         returned - A value that indicates when an attribute's value is retur=
ned in a SCIM GET operation or in response to a PUT, POST, or PATCH request.=
 Valid values are:
=
o    always - The attribute is always returned regardless of the contents=
 of the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always r=
eturned to identify the SCIM record.
=
o    never - The attribute is never returned. This is typically used in R=
ESTful operations where the attribute supports only update operations. An at=
tribute with "returned" set to "never" MAY be used in a search filter [[depe=
nding on index support]].
=
o    default - The attribute is returned in SCIM responses and is returne=
d when the GET "attributes" parameter [API Sec 3.2.3] is not specified.=

=
o    request - The attribute is returned in response to any SCIM PUT, POS=
T, or PATCH operations if the attribute was specified by the client (for exa=
mple, the attribute was modified). The attribute is returned in a SCIM GET o=
peration only if specified in the "attributes" parameter [API Sec 3.2.3].

 

Please let me know if you agree, or if you have conce= rns.

 

Note we may need more discussion on the default "retu= rned" values for some attributes.  For now, I'll consult with Kelly and= put together a set of proposed defaults (e.g. "id" is "always"). =

 

 

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-E4FDFDBA-CDFE-45A9-9684-B05B547E48FC-- From phil.hunt@oracle.com Mon Oct 28 15:52:56 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1588911E810B for ; Mon, 28 Oct 2013 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eua+gKkDz59Y for ; Mon, 28 Oct 2013 15:52:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7111E8152 for ; Mon, 28 Oct 2013 15:52:46 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9SMqj1w004262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 22:52:45 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 r9SMqiV3019173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 22:52:45 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9SMqhR8023160 for ; Mon, 28 Oct 2013 22:52:43 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2013 15:52:43 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_F35CE22E-03E0-49F4-B6B2-2B99DCC7FE32" Message-Id: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> Date: Mon, 28 Oct 2013 15:53:20 -0700 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [scim] Proposal for attribute indexing X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:52:56 -0000 --Apple-Mail=_F35CE22E-03E0-49F4-B6B2-2B99DCC7FE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please indicate your approval or comments with the following proposal = for Ticket 47 ( http://trac.tools.ietf.org/wg/scim/trac/ticket/47 ) It is proposed that the following attribute is to be added to section 11 = of the scim-core-schema draft to aid discovery of available searches for = attributes: indexed - One or more keyword values indicating the type of filters that = MAY be used=20 with the attribute. Valid values are the filter operators defined in = section 3.2.2.2.=20 For example, "eq" indicates the attribute and operator value must be = identical for=20 a match. To further values are defined: * any - any filter may be used. * none - no filter operator may be used with this attribute. In section 9 of scim-core-schema, the service provider schema will have = a new attribute as follows: unindexedFilters - A Boolean value indicating whether searches filters = using unindexed=20 attributes are supported. Additionally the following text is included in section 3.2.2.2 of the = scim-api draft: For any filter for which there is no index available and unindexed = searching=20 is not available, the server SHALL evaluate the the filter term as not = matched. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_F35CE22E-03E0-49F4-B6B2-2B99DCC7FE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://trac.too= ls.ietf.org/wg/scim/trac/ticket/47 )

It is proposed that the following = attribute is to be added to section 11 of the scim-core-schema draft to = aid discovery of available searches for attributes:

indexed - One or more keyword values =
indicating the type of filters that MAY be used=20
with the attribute. Valid values are the filter operators defined in =
section 3.2.2.2.=20
For example, "eq" indicates the attribute and operator value must be =
identical for=20
a match. To further values are defined:
* any - any filter may be used.
* none - no filter operator may be used with this attribute.

In section 9 of scim-core-schema, the service provider schema = will have a new attribute as follows:

unindexedFilters - A Boolean value indicating =
whether searches filters using unindexed=20
attributes are supported.

Additionally the following text is included in section 3.2.2.2 = of the scim-api draft:

For any filter for which there is no index =
available and unindexed searching=20
is not available, the server SHALL evaluate the the filter term as not =
matched.
Phil

=

= --Apple-Mail=_F35CE22E-03E0-49F4-B6B2-2B99DCC7FE32-- From tonynad@microsoft.com Mon Oct 28 20:05:19 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F94A11E81A3 for ; Mon, 28 Oct 2013 20:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lodWm-0HRF1y for ; Mon, 28 Oct 2013 20:05:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE321F9E12 for ; Mon, 28 Oct 2013 20:04:59 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 29 Oct 2013 03:04:56 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Tue, 29 Oct 2013 03:04:50 +0000 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) Thread-Index: AQHO1CDRlcmt2BuZUEKTqZCf/t7GuJoK/vjA Date: Tue, 29 Oct 2013 03:04:49 +0000 Message-ID: <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> In-Reply-To: <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(31966008)(74502001)(76786001)(76576001)(77096001)(69226001)(74316001)(46102001)(51856001)(47976001)(59766001)(77982001)(47446002)(74662001)(54356001)(79102001)(4396001)(87266001)(63696002)(33646001)(53806001)(16601075003)(76796001)(56816003)(49866001)(54316002)(47736001)(56776001)(16236675002)(81542001)(81342001)(65816001)(80022001)(15975445006)(19609705001)(15202345003)(74876001)(19580395003)(19580405001)(83322001)(66066001)(74706001)(19300405004)(81686001)(81816001)(76482001)(50986001)(85306002)(74366001)(80976001)(83072001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB189; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:50.46.126.7; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7a7aa15ce1c941d8a72b628efefd501dBY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "scim@ietf.org WG" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 03:05:19 -0000 --_000_7a7aa15ce1c941d8a72b628efefd501dBY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50 OiBNb25kYXksIE9jdG9iZXIgMjgsIDIwMTMgMjowMSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0K Q2M6IHNjaW1AaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbc2NpbV0gVGlja2V0IDEwIC0gQWJp bGl0eSB0byBtYXJrIGF0dHJpYnV0ZXMgYXMgc2Vuc2l0aXZlICh3aGVuIGF0dHJzIGFyZSByZXR1 cm5lZCkNCg0KVG9ueSBJIHJlY29tbWVuZCB3ZSBkbyB0aGF0IHJpZ2h0IGFmdGVyLg0KDQpGaXJz dCBkbyB3ZSBhZ3JlZSBvbiB2YWx1ZXMgZm9yICJyZXR1cm5lZCI/DQoNClBoaWwNCg0KT24gT2N0 IDI4LCAyMDEzLCBhdCAxMzo1MCwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5j b208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSB3b3VsZCBsaWtlIHRv IHNlZSB0aGUgZGlzY3Vzc2lvbiBoYXBwZW4gb24gdGhlIOKAnGRlZmF1bHTigJ0gcmV0dXJuZWQg YmVmb3JlIGNsb3Npbmcgb24gdGhpcyB0ZXh0DQoNCkZyb206IHNjaW0tYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI4LCAy MDEzIDExOjI4IEFNDQpUbzogc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4gV0cN ClN1YmplY3Q6IFtzY2ltXSBUaWNrZXQgMTAgLSBBYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBh cyBzZW5zaXRpdmUgKHdoZW4gYXR0cnMgYXJlIHJldHVybmVkKQ0KDQpJbiBvcmRlciB0byBicmlu ZyBUaWNrZXQgMTAgKCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3RyYWMvdGlj a2V0LzEwICkgdG8gYSBjbG9zZSwgdGhlIGZvbGxvd2luZyBpcyBhIG5ldyBzY2hlbWEgYXR0cmli dXRlIChTZWN0aW9uIDExKSBkZWZpbml0aW9uIHdoaWNoIGRlZmluZXMgd2hlbiBhbiBhdHRyaWJ1 dGUgaXMgcmV0dXJuZWQgb24gYSBxdWVyeS4gSXQgZGVmaW5lcyA0IG1vZGVzLg0KDQoNCsK3ICAg ICAgICAgcmV0dXJuZWQgLSBBIHZhbHVlIHRoYXQgaW5kaWNhdGVzIHdoZW4gYW4gYXR0cmlidXRl J3MgdmFsdWUgaXMgcmV0dXJuZWQgaW4gYSBTQ0lNIEdFVCBvcGVyYXRpb24gb3IgaW4gcmVzcG9u c2UgdG8gYSBQVVQsIFBPU1QsIG9yIFBBVENIIHJlcXVlc3QuIFZhbGlkIHZhbHVlcyBhcmU6DQoN Cm8gICAgYWx3YXlzIC0gVGhlIGF0dHJpYnV0ZSBpcyBhbHdheXMgcmV0dXJuZWQgcmVnYXJkbGVz cyBvZiB0aGUgY29udGVudHMgb2YgdGhlICJhdHRyaWJ1dGVzIiBwYXJhbWV0ZXIgW0FQSSBTZWMg My4yLjNdLiBGb3IgZXhhbXBsZSwgImlkIiBpcyBhbHdheXMgcmV0dXJuZWQgdG8gaWRlbnRpZnkg dGhlIFNDSU0gcmVjb3JkLg0KDQpvICAgIG5ldmVyIC0gVGhlIGF0dHJpYnV0ZSBpcyBuZXZlciBy ZXR1cm5lZC4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBpbiBSRVNUZnVsIG9wZXJhdGlvbnMgd2hl cmUgdGhlIGF0dHJpYnV0ZSBzdXBwb3J0cyBvbmx5IHVwZGF0ZSBvcGVyYXRpb25zLiBBbiBhdHRy aWJ1dGUgd2l0aCAicmV0dXJuZWQiIHNldCB0byAibmV2ZXIiIE1BWSBiZSB1c2VkIGluIGEgc2Vh cmNoIGZpbHRlciBbW2RlcGVuZGluZyBvbiBpbmRleCBzdXBwb3J0XV0uDQoNCm8gICAgZGVmYXVs dCAtIFRoZSBhdHRyaWJ1dGUgaXMgcmV0dXJuZWQgaW4gU0NJTSByZXNwb25zZXMgYW5kIGlzIHJl dHVybmVkIHdoZW4gdGhlIEdFVCAiYXR0cmlidXRlcyIgcGFyYW1ldGVyIFtBUEkgU2VjIDMuMi4z XSBpcyBub3Qgc3BlY2lmaWVkLg0KDQpvICAgIHJlcXVlc3QgLSBUaGUgYXR0cmlidXRlIGlzIHJl dHVybmVkIGluIHJlc3BvbnNlIHRvIGFueSBTQ0lNIFBVVCwgUE9TVCwgb3IgUEFUQ0ggb3BlcmF0 aW9ucyBpZiB0aGUgYXR0cmlidXRlIHdhcyBzcGVjaWZpZWQgYnkgdGhlIGNsaWVudCAoZm9yIGV4 YW1wbGUsIHRoZSBhdHRyaWJ1dGUgd2FzIG1vZGlmaWVkKS4gVGhlIGF0dHJpYnV0ZSBpcyByZXR1 cm5lZCBpbiBhIFNDSU0gR0VUIG9wZXJhdGlvbiBvbmx5IGlmIHNwZWNpZmllZCBpbiB0aGUgImF0 dHJpYnV0ZXMiIHBhcmFtZXRlciBbQVBJIFNlYyAzLjIuM10uDQoNClBsZWFzZSBsZXQgbWUga25v dyBpZiB5b3UgYWdyZWUsIG9yIGlmIHlvdSBoYXZlIGNvbmNlcm5zLg0KDQpOb3RlIHdlIG1heSBu ZWVkIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGUgZGVmYXVsdCAicmV0dXJuZWQiIHZhbHVlcyBmb3Ig c29tZSBhdHRyaWJ1dGVzLiAgRm9yIG5vdywgSSdsbCBjb25zdWx0IHdpdGggS2VsbHkgYW5kIHB1 dCB0b2dldGhlciBhIHNldCBvZiBwcm9wb3NlZCBkZWZhdWx0cyAoZS5nLiAiaWQiIGlzICJhbHdh eXMiKS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9yZzxtYWlsdG86 c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bQ0K --_000_7a7aa15ce1c941d8a72b628efefd501dBY2PR03MB189namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxl LXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox OTk0MjE0NDEwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTU2NjkxNTY0O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBIdW50 IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBPY3RvYmVyIDI4LCAyMDEzIDI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxp bjxicj4NCjxiPkNjOjwvYj4gc2NpbUBpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NjaW1dIFRpY2tldCAxMCAtIEFiaWxpdHkgdG8gbWFyayBhdHRyaWJ1dGVzIGFzIHNlbnNp dGl2ZSAod2hlbiBhdHRycyBhcmUgcmV0dXJuZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbnkgSSByZWNvbW1lbmQgd2UgZG8gdGhhdCBy aWdodCBhZnRlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Rmlyc3QgZG8gd2UgYWdyZWUgb24gdmFsdWVzIGZvciAmcXVvdDtyZXR1 cm5lZCZxdW90Oz88YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N Ck9uIE9jdCAyOCwgMjAxMywgYXQgMTM6NTAsIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxk IGxpa2UgdG8gc2VlIHRoZSBkaXNjdXNzaW9uIGhhcHBlbiBvbiB0aGUg4oCcZGVmYXVsdOKAnSBy ZXR1cm5lZCBiZWZvcmUgY2xvc2luZyBvbiB0aGlzIHRleHQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5zY2ltLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50 PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyOCwgMjAxMyAxMToyOCBBTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8 L2E+IFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzY2ltXSBUaWNrZXQgMTAgLSBBYmlsaXR5IHRv IG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgKHdoZW4gYXR0cnMgYXJlIHJldHVybmVkKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG9yZGVyIHRv IGJyaW5nIFRpY2tldCAxMCAoIDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L3NjaW0vdHJhYy90aWNrZXQvMTAiPg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvc2Np bS90cmFjL3RpY2tldC8xMDwvYT4gKSB0byBhIGNsb3NlLCB0aGUgZm9sbG93aW5nIGlzIGEgbmV3 IHNjaGVtYSBhdHRyaWJ1dGUgKFNlY3Rpb24gMTEpIGRlZmluaXRpb24gd2hpY2ggZGVmaW5lcyB3 aGVuIGFuIGF0dHJpYnV0ZSBpcyByZXR1cm5lZCBvbiBhIHF1ZXJ5LiBJdCBkZWZpbmVzIDQgbW9k ZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp bjt0ZXh0LWluZGVudDotLjI1aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5yZXR1cm5lZCAtIEEgdmFsdWUgdGhhdCBpbmRpY2F0ZXMgd2hlbiBhbiBhdHRyaWJ1dGUn cyB2YWx1ZSBpcyByZXR1cm5lZCBpbiBhIFNDSU0gR0VUIG9wZXJhdGlvbiBvciBpbiByZXNwb25z ZSB0byBhIFBVVCwgUE9TVCwgb3IgUEFUQ0ggcmVxdWVzdC4gVmFsaWQgdmFsdWVzIGFyZTo8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5czttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmFsd2F5cyAtIFRoZSBhdHRyaWJ1dGUgaXMgYWx3 YXlzIHJldHVybmVkIHJlZ2FyZGxlc3Mgb2YgdGhlIGNvbnRlbnRzIG9mIHRoZSAmcXVvdDthdHRy aWJ1dGVzJnF1b3Q7IHBhcmFtZXRlciBbQVBJIFNlYyAzLjIuM10uIEZvciBleGFtcGxlLCAmcXVv dDtpZCZxdW90OyBpcyBhbHdheXMgcmV0dXJuZWQgdG8gaWRlbnRpZnkgdGhlIFNDSU0gcmVjb3Jk LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDot LjI1aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwwIGxldmVsMiBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+bmV2ZXIgLSBUaGUgYXR0cmlidXRlIGlz IG5ldmVyIHJldHVybmVkLiBUaGlzIGlzIHR5cGljYWxseSB1c2VkIGluIFJFU1RmdWwgb3BlcmF0 aW9ucyB3aGVyZSB0aGUgYXR0cmlidXRlIHN1cHBvcnRzIG9ubHkgdXBkYXRlIG9wZXJhdGlvbnMu IEFuIGF0dHJpYnV0ZSB3aXRoICZxdW90O3JldHVybmVkJnF1b3Q7IHNldCB0byAmcXVvdDtuZXZl ciZxdW90OyBNQVkgYmUgdXNlZCBpbiBhIHNlYXJjaCBmaWx0ZXIgW1tkZXBlbmRpbmcgb24gaW5k ZXggc3VwcG9ydF1dLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0 ZXh0LWluZGVudDotLjI1aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwwIGxl dmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ZGVmYXVsdCAtIFRo ZSBhdHRyaWJ1dGUgaXMgcmV0dXJuZWQgaW4gU0NJTSByZXNwb25zZXMgYW5kIGlzIHJldHVybmVk IHdoZW4gdGhlIEdFVCAmcXVvdDthdHRyaWJ1dGVzJnF1b3Q7IHBhcmFtZXRlciBbQVBJIFNlYyAz LjIuM10gaXMgbm90IHNwZWNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5czttc28t bGlzdDpsMCBsZXZlbDIgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPnJl cXVlc3QgLSBUaGUgYXR0cmlidXRlIGlzIHJldHVybmVkIGluIHJlc3BvbnNlIHRvIGFueSBTQ0lN IFBVVCwgUE9TVCwgb3IgUEFUQ0ggb3BlcmF0aW9ucyBpZiB0aGUgYXR0cmlidXRlIHdhcyBzcGVj aWZpZWQgYnkgdGhlIGNsaWVudCAoZm9yIGV4YW1wbGUsIHRoZSBhdHRyaWJ1dGUgd2FzIG1vZGlm aWVkKS4gVGhlIGF0dHJpYnV0ZSBpcyByZXR1cm5lZCBpbiBhIFNDSU0gR0VUIG9wZXJhdGlvbiBv bmx5IGlmIHNwZWNpZmllZCBpbiB0aGUgJnF1b3Q7YXR0cmlidXRlcyZxdW90OyBwYXJhbWV0ZXIg W0FQSSBTZWMgMy4yLjNdLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGFncmVlLCBvciBpZiB5b3UgaGF2ZSBj b25jZXJucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm90ZSB3ZSBtYXkgbmVlZCBtb3JlIGRpc2N1c3Npb24gb24gdGhlIGRlZmF1bHQgJnF1 b3Q7cmV0dXJuZWQmcXVvdDsgdmFsdWVzIGZvciBzb21lIGF0dHJpYnV0ZXMuICZuYnNwO0ZvciBu b3csIEknbGwgY29uc3VsdCB3aXRoIEtlbGx5IGFuZCBwdXQgdG9nZXRoZXIgYSBzZXQgb2YgcHJv cG9zZWQgZGVmYXVsdHMgKGUuZy4gJnF1b3Q7aWQmcXVvdDsgaXMgJnF1b3Q7YWx3YXlzJnF1b3Q7 KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7a7aa15ce1c941d8a72b628efefd501dBY2PR03MB189namprd03pro_-- From tonynad@microsoft.com Mon Oct 28 22:05:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41C621E80B7 for ; Mon, 28 Oct 2013 22:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjalGiiOrQ2G for ; Mon, 28 Oct 2013 22:05:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85811E814B for ; Mon, 28 Oct 2013 22:05:26 -0700 (PDT) Received: from BLUPR03MB184.namprd03.prod.outlook.com (10.255.212.156) by BLUPR03MB182.namprd03.prod.outlook.com (10.255.212.148) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 05:05:12 +0000 Received: from BLUPR03MB184.namprd03.prod.outlook.com ([169.254.1.199]) by BLUPR03MB184.namprd03.prod.outlook.com ([169.254.1.199]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 05:05:12 +0000 From: Anthony Nadalin To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Proposal for attribute indexing Thread-Index: AQHO1DB291xtZO482UaqLM6c2P6rJZoLIHqw Date: Tue, 29 Oct 2013 05:05:11 +0000 Message-ID: <8e9baaad7102493591069bcbe5e3e6c2@BLUPR03MB184.namprd03.prod.outlook.com> References: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> In-Reply-To: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(54356001)(56816003)(76576001)(19300405004)(74502001)(53806001)(33646001)(77096001)(15202345003)(74316001)(51856001)(74366001)(16601075003)(561944002)(76786001)(16236675002)(74706001)(47736001)(47446002)(4396001)(74662001)(50986001)(47976001)(49866001)(31966008)(46102001)(83072001)(74876001)(66066001)(65816001)(80022001)(81342001)(56776001)(81542001)(81816001)(81686001)(19609705001)(85806002)(79102001)(76796001)(77982001)(69226001)(80976001)(19580395003)(15975445006)(19580405001)(83322001)(54316002)(59766001)(85306002)(76482001)(63696002)(87266001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB182; H:BLUPR03MB184.namprd03.prod.outlook.com; CLIP:50.46.126.7; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_8e9baaad7102493591069bcbe5e3e6c2BLUPR03MB184namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [scim] Proposal for attribute indexing X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 05:05:39 -0000 --_000_8e9baaad7102493591069bcbe5e3e6c2BLUPR03MB184namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Monday, October 28, 2013 3:53 PM To: scim@ietf.org WG Subject: [scim] Proposal for attribute indexing Please indicate your approval or comments with the following proposal for T= icket 47 ( http://trac.tools.ietf.org/wg/scim/trac/ticket/47 ) It is proposed that the following attribute is to be added to section 11 of= the scim-core-schema draft to aid discovery of available searches for attr= ibutes: indexed - One or more keyword values indicating the type of filters that MA= Y be used with the attribute. Valid values are the filter operators defined in sectio= n 3.2.2.2. For example, "eq" indicates the attribute and operator value must be identi= cal for a match. To further values are defined: * any - any filter may be used. * none - no filter operator may be used with this attribute. In section 9 of scim-core-schema, the service provider schema will have a n= ew attribute as follows: unindexedFilters - A Boolean value indicating whether searches filters usin= g unindexed attributes are supported. Additionally the following text is included in section 3.2.2.2 of the scim-= api draft: For any filter for which there is no index available and unindexed searchin= g is not available, the server SHALL evaluate the the filter term as not matc= hed. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_8e9baaad7102493591069bcbe5e3e6c2BLUPR03MB184namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 

From: scim-b= ounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 3:53 PM
To: scim@ietf.org WG
Subject: [scim] Proposal for attribute indexing

 

Please indicate your approval or comments with the f= ollowing proposal for Ticket 47 ( http://trac.t= ools.ietf.org/wg/scim/trac/ticket/47 )

 

It is proposed that the following attribute is= to be added to section 11 of the scim-core-schema draft to aid discovery o= f available searches for attributes:

indexed - One or more keyword values indicating th=
e type of filters that MAY be used 
with the attribute. Valid values are the filter operators define=
d in section 3.2.2.2. 
For example, "eq" indicates the attribute and operator=
 value must be identical for 
a match. To further values are defined:
* any - any filter may be used.
* none - no filter operator may be used with this attribute.

In section 9 of scim-core-schema, the service = provider schema will have a new attribute as follows:

unindexedFilters - A Boolean value indicating whet=
her searches filters using unindexed 
attributes are supported.

Additionally the following text is included in= section 3.2.2.2 of the scim-api draft:

For any filter for which there is no index availab=
le and unindexed searching 
is not available, the server SHALL evaluate the the filter term =
as not matched.

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

--_000_8e9baaad7102493591069bcbe5e3e6c2BLUPR03MB184namprd03pro_-- From t.rossner@tarent.de Tue Oct 29 00:56:46 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07911E8120 for ; Tue, 29 Oct 2013 00:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFVIm-q1GriR for ; Tue, 29 Oct 2013 00:56:39 -0700 (PDT) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 679BA21F99F4 for ; Tue, 29 Oct 2013 00:56:36 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id k11so2759036eaj.28 for ; Tue, 29 Oct 2013 00:56:35 -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; bh=2re9aUN5ieg5CdB3XZzFBgorohnQ7zncPEIpqJRw4yk=; b=NQOSi2yVxIcH9XMUcDMd6T2ntk6UQGiH5mxPyNjw3mSkuRI1DRb16q44LSc73Ft5hC EOl7XpUiawb/jPwTFNMXoWwLkiIl8T1C5zLxhb2Zz72WlKJmMpxQZz/kq33ny6t0oRq9 9tRwm7Udu9q+svsSA4Uga9l2YMVsocqHCRf3l7GwTri/9C2xRmIzchCfMmroJZB3lZyr JPkj9uFROznaoBcGmZIFpd2aSeOTan0aL6she3UuPimw6FRHiN03efFbOIKmgWDSwN8s kC3L2RF1+phD0yLLQ7yLlm+Z04/bHuHBXKHSIxi5fNCB+JVz+Cf9DQ9wrIrGW0qj3wJY bqEA== X-Gm-Message-State: ALoCoQke/v3ePvRmy7VUzC6mmJ3GYceZpIxZtv+9cdqCJM4jDKfVhJ2jaVcMd1ZuSfLYCDNgxYND X-Received: by 10.15.101.130 with SMTP id bp2mr1559078eeb.86.1383033395032; Tue, 29 Oct 2013 00:56:35 -0700 (PDT) Received: from [192.168.43.113] (ip-109-44-0-116.web.vodafone.de. [109.44.0.116]) by mx.google.com with ESMTPSA id u46sm67063128eep.17.2013.10.29.00.56.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 00:56:34 -0700 (PDT) Message-ID: <526F6A28.8010903@tarent.de> Date: Tue, 29 Oct 2013 08:56:24 +0100 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050509000106040205080703" Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 07:56:46 -0000 This is a multi-part message in MIME format. --------------050509000106040205080703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 > _Please confirm_ if you agree with this subtle change which makes root > searches optional to the server. > --------------050509000106040205080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1

Please confirm if you agree with this subtle change which makes root searches optional to the server.


--------------050509000106040205080703-- From t.rossner@tarent.de Tue Oct 29 01:05:41 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED821E8064 for ; Tue, 29 Oct 2013 01:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qyt7RjisNcd4 for ; Tue, 29 Oct 2013 01:05:34 -0700 (PDT) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4139D11E81A2 for ; Tue, 29 Oct 2013 01:05:20 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so2730772eak.4 for ; Tue, 29 Oct 2013 01:05:09 -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=BVq3Y+YjyDv1P9V1/gve40hzXTPrY+m2/dFQK/lZBNE=; b=OYqC2k+/WvA6WfSRsHrXN9EaE+3+eM5eLv2/zGH/2UUrtn8GL0ojIAfuiswlDgsA1r /nofRwpuxjZWi/5kmtUQNPy5hOKiR+muw6oSjPD130vcaroTZzPAf6kWY5yEnSgbImcZ rULbtA7eAtwuMHswWBp/N22CueHqRag2WQtLoKevzY+NEDrd6Dp37G1/IGe3WMRu3bz5 exJM97Evo25UZBKP6fD6CA7ADJdLy5wQKeXGgpS3SV2sH1U/slk7fU6ZctO98AyV0swg EmFstpsO435RI4CHOIV9qMMne8klNSn7umSzmn7BwQ+lZ5TFiUUpuU8MSfeEdC/coapk BFNw== X-Gm-Message-State: ALoCoQmwGWCX4mHcEl20/oaRhywyUg6Dj010qIh/BJAxq21KYKpYnnU2D3/fB8FpdqHMvbo9U4TI X-Received: by 10.14.108.200 with SMTP id q48mr1486645eeg.105.1383033909599; Tue, 29 Oct 2013 01:05:09 -0700 (PDT) Received: from [192.168.43.113] (ip-109-44-0-116.web.vodafone.de. [109.44.0.116]) by mx.google.com with ESMTPSA id k7sm67081639eeg.13.2013.10.29.01.03.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 01:05:08 -0700 (PDT) Message-ID: <526F6BA1.5050006@tarent.de> Date: Tue, 29 Oct 2013 09:02:41 +0100 From: =?ISO-8859-1?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> In-Reply-To: <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 08:05:41 -0000 Depending on which fields are returned by default an option could be helpful that returns a complete resource object (except for the fields that are never returned). Thanks Thorsten From leifj@mnt.se Tue Oct 29 07:30:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5593C11E8277 for ; Tue, 29 Oct 2013 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuKmU4cscrxf for ; Tue, 29 Oct 2013 07:30:16 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5011E8268 for ; Tue, 29 Oct 2013 07:30:16 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id z5so92554lbh.6 for ; Tue, 29 Oct 2013 07:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=FoY+MNgwlIxenCc0sjf7BVSL5PLnKyyXehz9PueNhHo=; b=h1rpoARUt/iGeyRQuq7gOzNy+DdWYBOLHDmfocDji0AE6zJe2mCwm0itUlO3AGHCP4 P6tCjwRFScp+7cOnTPSQFU0W9dBaQv9PTYH459ToForSdomm8blp+7fLmds5fJvmqPlb 3qu5vqePsEs+XhNSmL3rA/LtwkIYHJnQhwNg+KyqwiQ99jt3qm7nR3OGaXyzMkIEjwOg kRx22w+ZYDQLnuXkKCcU3rxBS8nM+DUaQurnIzm+UjAaWN3OUu3x6zQMDnqPviaSqqzc CdQXno8TJgAjzPgQx655k7qVjgvP7VXxt7+2NflwecgKswSg/jiJaavbKLRtE09lvjml W6pg== X-Gm-Message-State: ALoCoQnJugcK4qiQHnkB/76wqmBxAfR++Ce3A4khWPEkkB3IYV2sOKiJ9MmbvuFc4ajId9fSMMzl X-Received: by 10.152.28.7 with SMTP id x7mr5445143lag.26.1383057015155; Tue, 29 Oct 2013 07:30:15 -0700 (PDT) Received: from [2.67.61.185] (2.67.61.185.mobile.tre.se. [2.67.61.185]) by mx.google.com with ESMTPSA id a9sm939638lae.9.2013.10.29.07.30.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 07:30:13 -0700 (PDT) From: Leif Johansson Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11B511) Message-Id: <62CD7DFB-9AC2-4144-B19C-E509E240B85B@mnt.se> Date: Tue, 29 Oct 2013 15:30:09 +0100 To: scim@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [scim] cancel next call X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:30:22 -0000 We where due for a call tomorrow but we've decided to cancel to let everybod= y focus on getting ready for the IETF!= From phil.hunt@oracle.com Tue Oct 29 09:03:22 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA77E11E817E for ; Tue, 29 Oct 2013 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsaeslA4IfxR for ; Tue, 29 Oct 2013 09:03:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3E11E81A8 for ; Tue, 29 Oct 2013 09:03:17 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TG3Fwq011096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 16:03:16 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 r9TG3ErL007485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 16:03:14 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TG3EJO028737; Tue, 29 Oct 2013 16:03:14 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 09:03:13 -0700 References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> <526F6BA1.5050006@tarent.de> Mime-Version: 1.0 (1.0) In-Reply-To: <526F6BA1.5050006@tarent.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <3567C81D-C9CB-4D54-B0F1-B84A643665DA@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Tue, 29 Oct 2013 09:03:12 -0700 To: =?utf-8?Q?Thorsten_Ro=C3=9Fner?= X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:03:22 -0000 Thorsten, Do you agree with the categories? Phil > On Oct 29, 2013, at 1:02, Thorsten Ro=C3=9Fner wrote= : >=20 > Depending on which fields are returned by default an option could be > helpful that returns a complete resource object (except for the fields > that are never returned). >=20 > Thanks > Thorsten > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Oct 29 09:07:38 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A3111E8275 for ; Tue, 29 Oct 2013 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRmIAkui+lQz for ; Tue, 29 Oct 2013 09:07:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 012F811E8137 for ; Tue, 29 Oct 2013 09:07:11 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TG7AI4004295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 16:07:11 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 r9TG788a013833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 16:07:09 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TG78Qv022196; Tue, 29 Oct 2013 16:07:08 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 09:07:08 -0700 References: <62CD7DFB-9AC2-4144-B19C-E509E240B85B@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: <62CD7DFB-9AC2-4144-B19C-E509E240B85B@mnt.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Tue, 29 Oct 2013 09:07:06 -0700 To: Leif Johansson X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" Subject: Re: [scim] cancel next call X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:07:38 -0000 Aww gee, and I got my homework done! ;-) Phil > On Oct 29, 2013, at 7:30, Leif Johansson wrote: >=20 > We where due for a call tomorrow but we've decided to cancel to let everyb= ody focus on getting ready for the IETF! > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Tue Oct 29 10:09:37 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDB911E8262 for ; Tue, 29 Oct 2013 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFB8RBzl-J7J for ; Tue, 29 Oct 2013 10:09:33 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7368621F9F20 for ; Tue, 29 Oct 2013 10:03:04 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id q8so274187lbi.19 for ; Tue, 29 Oct 2013 10:03:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=I0Rkw6y/rxUAoMiHa2r9tfWLROxCiF9fvtJZH5wM1aU=; b=DL8tGEuGqUjZhbva/uA7bWsevJG6VW7LjtyEwuEZcxwAtyrOiWn3Zyg4oSzsaikiLs L/z1BOPg/nTYqjwKH1XEne9iGao5QIPu5/Oak2NX4gZV4AtO7hQjDdbmk8Z5RJcvuArU H4aemrAdgj8me0Xml7FUsL/zlYryox/idPWTpJnpWFBiSaQoNs/N1FSRInRCPQrBfxYb jIJ3RI/5iCUy8msvHdofiKTPvuZG4bVkCNgnWVyANvDBdHfcRCP+sSF5GiuDQMhOAouH JF2akzunImspFaAyC5n8GHe6XdnHQT/U/21nCCcCRKz8Kq84ZypIbebALE9W2wHDGv9d h9Mw== X-Gm-Message-State: ALoCoQnJHlpZryKCxVk3IWwcyBsvDlBBxGzyNsBjlFIbdczwsEVpG+Kkha3WQ33RweM0IIyNI4rD X-Received: by 10.112.72.100 with SMTP id c4mr660486lbv.57.1383066183152; Tue, 29 Oct 2013 10:03:03 -0700 (PDT) Received: from [2.67.61.185] (2.67.61.185.mobile.tre.se. [2.67.61.185]) by mx.google.com with ESMTPSA id e4sm17074158lba.15.2013.10.29.10.02.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 10:03:01 -0700 (PDT) References: <62CD7DFB-9AC2-4144-B19C-E509E240B85B@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B511) From: Leif Johansson Date: Tue, 29 Oct 2013 18:02:17 +0100 To: Phil Hunt Cc: "scim@ietf.org" Subject: Re: [scim] cancel next call X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:09:37 -0000 > 29 okt 2013 kl. 17:07 skrev Phil Hunt : >=20 > Aww gee, and I got my homework done! ;-) >=20 you get your points still :-) > Phil >=20 >> On Oct 29, 2013, at 7:30, Leif Johansson wrote: >>=20 >> We where due for a call tomorrow but we've decided to cancel to let every= body focus on getting ready for the IETF! >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From t.rossner@tarent.de Tue Oct 29 10:56:40 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5321E8093 for ; Tue, 29 Oct 2013 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yal4uGHtF7aS for ; Tue, 29 Oct 2013 10:55:49 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0852111E8243 for ; Tue, 29 Oct 2013 10:54:41 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id d49so96947eek.21 for ; Tue, 29 Oct 2013 10:54:41 -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=8/LHyltwu0TTGIsDJR6vswnLyn3WESBefiug25YBEaI=; b=gpsiMVzDoiS0Pc6/KuquwaUhlS+ym6iQOmBEayI9ceL5NxDbciPG/r2SHTeVpu897u 3iakcCReWckOg9mSqK1plNgudRG3lqwN0nozhKE7uSZarVuAddOEagDrESVvMgdKidXY 1/L7lR9zwozBh5zrTczCy7nZQ8UC7mDaakofizYkqZss9au+ni4sPDJyj+cqPeL+8WmU oJ9SRl9CkHIpg0jCY9yQ62yeZd9xuGJ3b5C4w3JPgBTRCku0aOrR1vCstzYUy6DWvN3D nNnVk8b3mpaLod3gHdOPxW1182+U/V0RHKj6rJzur6ukgfg3JILlnFo7WlW46eA664Kp cPIg== X-Gm-Message-State: ALoCoQlcK+CMrO3cU0+CHc+QemKeYQeia0UQvf4QHQu9PgesGITF0g2nwgiuoalEvu85FfBC8CpF X-Received: by 10.15.98.194 with SMTP id bj42mr946326eeb.12.1383069280895; Tue, 29 Oct 2013 10:54:40 -0700 (PDT) Received: from [213.61.39.89] (h-213.61.39.89.host.de.colt.net. [213.61.39.89]) by mx.google.com with ESMTPSA id j7sm73050099eeo.15.2013.10.29.10.54.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 10:54:40 -0700 (PDT) Message-ID: <526FF65E.4030302@tarent.de> Date: Tue, 29 Oct 2013 18:54:38 +0100 From: =?UTF-8?B?VGhvcnN0ZW4gUm/Dn25lcg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Phil Hunt References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> <526F6BA1.5050006@tarent.de> <3567C81D-C9CB-4D54-B0F1-B84A643665DA@oracle.com> In-Reply-To: <3567C81D-C9CB-4D54-B0F1-B84A643665DA@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "scim@ietf.org" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:57:11 -0000 Phil, yes, I agree. Would it make sense to define a default option when no "returned" attribute is available? I would prefer "request". Cheers Thorsten Am 29.10.2013 17:03, schrieb Phil Hunt: > Thorsten, > > Do you agree with the categories? > > Phil > >> On Oct 29, 2013, at 1:02, Thorsten Roßner wrote: >> >> Depending on which fields are returned by default an option could be >> helpful that returns a complete resource object (except for the fields >> that are never returned). >> >> Thanks >> Thorsten >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Tue Oct 29 11:05:14 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C721E8093 for ; Tue, 29 Oct 2013 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGhVTYrp+ILp for ; Tue, 29 Oct 2013 11:04:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1533A11E8228 for ; Tue, 29 Oct 2013 11:02:14 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TI2Aj4024747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 18:02:12 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 r9TI2AGp027122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 18:02:10 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TI29Y8026781; Tue, 29 Oct 2013 18:02:09 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 11:02:09 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <526FF65E.4030302@tarent.de> Date: Tue, 29 Oct 2013 11:02:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31DADB93-86BB-41BE-B7AE-DD52722AEF19@oracle.com> References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> <7a7aa15ce1c941d8a72b628efefd501d@BY2PR03MB189.namprd03.prod.outlook.com> <526F6BA1.5050006@tarent.de> <3567C81D-C9CB-4D54-B0F1-B84A643665DA@oracle.com> <526FF65E.4030302@tarent.de> To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:05:14 -0000 What I would propose to do is discuss that next week. We can talk about = what the "default" value for index and returned is for each attribute = and we can say what the default setting is if unspecified (e.g. is = default the default, or is request the default).=20 I think this part is a little more messy and best done with projector = and we can quickly mark it up together. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-29, at 10:54 AM, Thorsten Ro=DFner = wrote: > Phil, >=20 > yes, I agree. Would it make sense to define a default option when no > "returned" attribute is available? I would prefer "request". >=20 > Cheers > Thorsten >=20 > Am 29.10.2013 17:03, schrieb Phil Hunt: >> Thorsten, >>=20 >> Do you agree with the categories? >>=20 >> Phil >>=20 >>> On Oct 29, 2013, at 1:02, Thorsten Ro=DFner = wrote: >>>=20 >>> Depending on which fields are returned by default an option could be >>> helpful that returns a complete resource object (except for the = fields >>> that are never returned). >>>=20 >>> Thanks >>> Thorsten >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 From kelly.grizzle@sailpoint.com Tue Oct 29 11:29:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326111E822E for ; Tue, 29 Oct 2013 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3wOybWD2L+3 for ; Tue, 29 Oct 2013 11:29:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5731011E8285 for ; Tue, 29 Oct 2013 11:28:46 -0700 (PDT) Received: from CO1PR04MB393.namprd04.prod.outlook.com (10.141.75.16) by CO1PR04MB395.namprd04.prod.outlook.com (10.141.75.28) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 18:28:37 +0000 Received: from CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.173]) by CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.133]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 18:28:37 +0000 From: Kelly Grizzle To: Anthony Nadalin , Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Proposed resolution - root search optionality (ticket 42) Thread-Index: AQHO1A4KOlaOMHv1bEK7+jWYZUqh2JoKlc8AgAFrRqA= Date: Tue, 29 Oct 2013 18:28:36 +0000 Message-ID: <9677d197b4d145e49cfe42d9553bcd52@CO1PR04MB393.namprd04.prod.outlook.com> References: <609a469eb1de420d9a598fcc37c68962@BY2PR03MB189.namprd03.prod.outlook.com> In-Reply-To: <609a469eb1de420d9a598fcc37c68962@BY2PR03MB189.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2523D7BB0059322523D908 x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(81686001)(81816001)(16601075003)(31966008)(15202345003)(85306002)(33646001)(77096001)(76796001)(56816003)(76576001)(19609705001)(85806002)(15975445006)(76786001)(65816001)(16236675002)(74876001)(54356001)(46102001)(53806001)(51856001)(74366001)(81342001)(81542001)(69226001)(19580405001)(19580395003)(54316002)(76482001)(74502001)(74662001)(56776001)(47446002)(19300405004)(80022001)(83072001)(74316001)(74706001)(59766001)(47736001)(1511001)(4396001)(49866001)(63696002)(79102001)(77982001)(83322001)(47976001)(50986001)(80976001)(87266001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB395; H:CO1PR04MB393.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9677d197b4d145e49cfe42d9553bcd52CO1PR04MB393namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:29:09 -0000 --_000_9677d197b4d145e49cfe42d9553bcd52CO1PR04MB393namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the text, but think that we should also consider adding a ServicePro= viderConfig property that says whether this is supported or not. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ant= hony Nadalin Sent: Monday, October 28, 2013 3:48 PM To: Phil Hunt; scim@ietf.org WG Subject: Re: [scim] Proposed resolution - root search optionality (ticket 4= 2) +1 From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Monday, October 28, 2013 11:47 AM To: scim@ietf.org WG Subject: [scim] Proposed resolution - root search optionality (ticket 42) Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - ht= tp://trac.tools.ietf.org/wg/scim/trac/ticket/42 ): 3.2.2.1 Query Enpoints Resource Queries A query MAY be performed against any specific resource endpoint or resource= . For example: * Resource (e.g. /Users/{userid}), * Resource Type endpoint (e.g. /Users or /Groups) Root Queries A server MAY support queries at the server root (e.g. /) for the purpose of= returning resources of more than one resource type. A search against a server root indicates that ALL resources within the serv= er SHALL be included subject to filtering. For example, a filter against 'm= eta.resourceType' could be used to restrict results to one or more specific= resource types. When processing search operations across endpoints that include more than o= ne SCIM resource type (e.g. a search from the server root endpoint), filter= s MUST be processed in the same fashion as outlined in Section 3.2.2.2. For= filtered attributes that are not part of a particular resource type, the s= ervice provider SHALL treat the attribute as if there is no attribute value= . For example, a presence or equality filter for an undefined attribute eva= luates as FALSE. Please confirm if you agree with this subtle change which makes root search= es optional to the server. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_9677d197b4d145e49cfe42d9553bcd52CO1PR04MB393namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like the text, but thin= k that we should also consider adding a ServiceProviderConfig property that= says whether this is supported or not.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Monday, October 28, 2013 3:48 PM
To: Phil Hunt; scim@ietf.org WG
Subject: Re: [scim] Proposed resolution - root search optionality (t= icket 42)

 

+1<= /p>

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:47 AM
To: scim@ietf.org WG
Subject: [scim] Proposed resolution - root search optionality (ticke= t 42)

 

Proposed tex= t. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - http://trac.t= ools.ietf.org/wg/scim/trac/ticket/42 ):

3.2.2.1 Query Enpoints

Resour= ce Queries

A query MAY be performed against any specific resou= rce endpoint or resource. For example:

  • Resour= ce (e.g. /Users/{userid}),
  • Resour= ce Type endpoint (e.g. /Users or /Groups)

Root Q= ueries

A server MAY support queries at the se= rver root (e.g. /) for the purpose of returning resources of more than one = resource type.

A search against a server root indicates that ALL r= esources within the server SHALL be included subject to filtering. For exam= ple, a filter against 'meta.resourceType' could be used to restrict results to one or more specific resource types.=

When processing search operations acro= ss endpoints that include more than one SCIM resource type (e.g. a search f= rom the server root endpoint), filters MUST be processed in the same fashion as outlined in Section 3.2.2.2. For filtered= attributes that are not part of a particular resource type, the service pr= ovider SHALL treat the attribute as if there is no attribute value. For exa= mple, a presence or equality filter for an undefined attribute evaluates as FALSE.

Pleas= e confirm if you agr= ee with this subtle change which makes root searches optional to the server= .

&nb= sp;

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 

--_000_9677d197b4d145e49cfe42d9553bcd52CO1PR04MB393namprd04pro_-- From kelly.grizzle@sailpoint.com Tue Oct 29 12:03:09 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B3111E819A for ; Tue, 29 Oct 2013 12:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShGvPCMHy6uw for ; Tue, 29 Oct 2013 12:03:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7311E8293 for ; Tue, 29 Oct 2013 12:02:28 -0700 (PDT) Received: from CO1PR04MB393.namprd04.prod.outlook.com (10.141.75.16) by CO1PR04MB394.namprd04.prod.outlook.com (10.141.75.23) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 19:02:13 +0000 Received: from CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.173]) by CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.133]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 19:02:13 +0000 From: Kelly Grizzle To: Phil Hunt , Anthony Nadalin Thread-Topic: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) Thread-Index: AQHO1CDT2qQ1Abj/j0+xhyGlH4FwI5oMAxAg Date: Tue, 29 Oct 2013 19:02:12 +0000 Message-ID: References: <7E8BDF77-5505-49D8-BD2E-C7C8330B299E@oracle.com> <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> In-Reply-To: <634B42A0-1B9F-4FB3-8717-544901769625@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 252AEAAF005932252AEBFC x-originating-ip: [2001:4870:600a:500::2] x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(79102001)(15202345003)(81816001)(4396001)(74706001)(85806002)(51856001)(1511001)(77982001)(54356001)(47736001)(80976001)(49866001)(53806001)(85306002)(59766001)(50986001)(80022001)(47976001)(19609705001)(74876001)(65816001)(81542001)(69226001)(15975445006)(81342001)(81686001)(63696002)(46102001)(74366001)(19580405001)(76482001)(16601075003)(19580395003)(31966008)(83322001)(56776001)(54316002)(74316001)(33646001)(77096001)(19300405004)(83072001)(74662001)(76796001)(76576001)(47446002)(16236675002)(56816003)(74502001)(76786001)(87266001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB394; H:CO1PR04MB393.namprd04.prod.outlook.com; CLIP:2001:4870:600a:500::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f28c4aab3f184202937ec45a01688719CO1PR04MB393namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org WG" Subject: Re: [scim] Ticket 10 - Ability to mark attributes as sensitive (when attrs are returned) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:03:09 -0000 --_000_f28c4aab3f184202937ec45a01688719CO1PR04MB393namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHRoZSBjYXRlZ29yaWVzLg0KDQpGb3Igc29tZSBtaW5vciB3b3JkLXNtaXRoaW5nLCBJ IHdvdWxkIHJlbW92ZSB0aGUgd29yZCDigJxTQ0lN4oCdIGZyb20gdGhlc2UgZGVmaW5pdGlvbnMu ICBJdCBjYW4gYmUgaW1wbGllZC4NCg0KLS1LZWxseQ0KDQpGcm9tOiBzY2ltLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1 bnQNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOCwgMjAxMyA0OjAxIFBNDQpUbzogQW50aG9ueSBO YWRhbGluDQpDYzogc2NpbUBpZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFtzY2ltXSBUaWNrZXQg MTAgLSBBYmlsaXR5IHRvIG1hcmsgYXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgKHdoZW4gYXR0cnMg YXJlIHJldHVybmVkKQ0KDQpUb255IEkgcmVjb21tZW5kIHdlIGRvIHRoYXQgcmlnaHQgYWZ0ZXIu DQoNCkZpcnN0IGRvIHdlIGFncmVlIG9uIHZhbHVlcyBmb3IgInJldHVybmVkIj8NCg0KUGhpbA0K DQpPbiBPY3QgMjgsIDIwMTMsIGF0IDEzOjUwLCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWlj cm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJIHdvdWxk IGxpa2UgdG8gc2VlIHRoZSBkaXNjdXNzaW9uIGhhcHBlbiBvbiB0aGUg4oCcZGVmYXVsdOKAnSBy ZXR1cm5lZCBiZWZvcmUgY2xvc2luZyBvbiB0aGlzIHRleHQNCg0KRnJvbTogc2NpbS1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2NpbS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50DQpTZW50OiBNb25kYXksIE9jdG9i ZXIgMjgsIDIwMTMgMTE6MjggQU0NClRvOiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPiBXRw0KU3ViamVjdDogW3NjaW1dIFRpY2tldCAxMCAtIEFiaWxpdHkgdG8gbWFyayBhdHRy aWJ1dGVzIGFzIHNlbnNpdGl2ZSAod2hlbiBhdHRycyBhcmUgcmV0dXJuZWQpDQoNCkluIG9yZGVy IHRvIGJyaW5nIFRpY2tldCAxMCAoIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NjaW0v dHJhYy90aWNrZXQvMTAgKSB0byBhIGNsb3NlLCB0aGUgZm9sbG93aW5nIGlzIGEgbmV3IHNjaGVt YSBhdHRyaWJ1dGUgKFNlY3Rpb24gMTEpIGRlZmluaXRpb24gd2hpY2ggZGVmaW5lcyB3aGVuIGFu IGF0dHJpYnV0ZSBpcyByZXR1cm5lZCBvbiBhIHF1ZXJ5LiBJdCBkZWZpbmVzIDQgbW9kZXMuDQoN Cg0K4oCiICAgICAgICAgcmV0dXJuZWQgLSBBIHZhbHVlIHRoYXQgaW5kaWNhdGVzIHdoZW4gYW4g YXR0cmlidXRlJ3MgdmFsdWUgaXMgcmV0dXJuZWQgaW4gYSBTQ0lNIEdFVCBvcGVyYXRpb24gb3Ig aW4gcmVzcG9uc2UgdG8gYSBQVVQsIFBPU1QsIG9yIFBBVENIIHJlcXVlc3QuIFZhbGlkIHZhbHVl cyBhcmU6DQoNCm8gICAgYWx3YXlzIC0gVGhlIGF0dHJpYnV0ZSBpcyBhbHdheXMgcmV0dXJuZWQg cmVnYXJkbGVzcyBvZiB0aGUgY29udGVudHMgb2YgdGhlICJhdHRyaWJ1dGVzIiBwYXJhbWV0ZXIg W0FQSSBTZWMgMy4yLjNdLiBGb3IgZXhhbXBsZSwgImlkIiBpcyBhbHdheXMgcmV0dXJuZWQgdG8g aWRlbnRpZnkgdGhlIFNDSU0gcmVjb3JkLg0KDQpvICAgIG5ldmVyIC0gVGhlIGF0dHJpYnV0ZSBp cyBuZXZlciByZXR1cm5lZC4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBpbiBSRVNUZnVsIG9wZXJh dGlvbnMgd2hlcmUgdGhlIGF0dHJpYnV0ZSBzdXBwb3J0cyBvbmx5IHVwZGF0ZSBvcGVyYXRpb25z LiBBbiBhdHRyaWJ1dGUgd2l0aCAicmV0dXJuZWQiIHNldCB0byAibmV2ZXIiIE1BWSBiZSB1c2Vk IGluIGEgc2VhcmNoIGZpbHRlciBbW2RlcGVuZGluZyBvbiBpbmRleCBzdXBwb3J0XV0uDQoNCm8g ICAgZGVmYXVsdCAtIFRoZSBhdHRyaWJ1dGUgaXMgcmV0dXJuZWQgaW4gU0NJTSByZXNwb25zZXMg YW5kIGlzIHJldHVybmVkIHdoZW4gdGhlIEdFVCAiYXR0cmlidXRlcyIgcGFyYW1ldGVyIFtBUEkg U2VjIDMuMi4zXSBpcyBub3Qgc3BlY2lmaWVkLg0KDQpvICAgIHJlcXVlc3QgLSBUaGUgYXR0cmli dXRlIGlzIHJldHVybmVkIGluIHJlc3BvbnNlIHRvIGFueSBTQ0lNIFBVVCwgUE9TVCwgb3IgUEFU Q0ggb3BlcmF0aW9ucyBpZiB0aGUgYXR0cmlidXRlIHdhcyBzcGVjaWZpZWQgYnkgdGhlIGNsaWVu dCAoZm9yIGV4YW1wbGUsIHRoZSBhdHRyaWJ1dGUgd2FzIG1vZGlmaWVkKS4gVGhlIGF0dHJpYnV0 ZSBpcyByZXR1cm5lZCBpbiBhIFNDSU0gR0VUIG9wZXJhdGlvbiBvbmx5IGlmIHNwZWNpZmllZCBp biB0aGUgImF0dHJpYnV0ZXMiIHBhcmFtZXRlciBbQVBJIFNlYyAzLjIuM10uDQoNClBsZWFzZSBs ZXQgbWUga25vdyBpZiB5b3UgYWdyZWUsIG9yIGlmIHlvdSBoYXZlIGNvbmNlcm5zLg0KDQpOb3Rl IHdlIG1heSBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGUgZGVmYXVsdCAicmV0dXJuZWQiIHZh bHVlcyBmb3Igc29tZSBhdHRyaWJ1dGVzLiAgRm9yIG5vdywgSSdsbCBjb25zdWx0IHdpdGggS2Vs bHkgYW5kIHB1dCB0b2dldGhlciBhIHNldCBvZiBwcm9wb3NlZCBkZWZhdWx0cyAoZS5nLiAiaWQi IGlzICJhbHdheXMiKS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50 aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2NpbUBpZXRmLm9y ZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2NpbQ0K --_000_f28c4aab3f184202937ec45a01688719CO1PR04MB393namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFwcGxlLXN0eWxlLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiYjNDM7MSBmb3IgdGhlIGNhdGVnb3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3Igc29tZSBtaW5v ciB3b3JkLXNtaXRoaW5nLCBJIHdvdWxkIHJlbW92ZSB0aGUgd29yZCDigJxTQ0lN4oCdIGZyb20g dGhlc2UgZGVmaW5pdGlvbnMuJm5ic3A7IEl0IGNhbiBiZSBpbXBsaWVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1L ZWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNj aW0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyOCwgMjAxMyA0OjAxIFBNPGJyPg0KPGI+VG86 PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IHNjaW1AaWV0Zi5vcmcgV0c8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBUaWNrZXQgMTAgLSBBYmlsaXR5IHRvIG1hcmsg YXR0cmlidXRlcyBhcyBzZW5zaXRpdmUgKHdoZW4gYXR0cnMgYXJlIHJldHVybmVkKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255IEkgcmVj b21tZW5kIHdlIGRvIHRoYXQgcmlnaHQgYWZ0ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0IGRvIHdlIGFncmVlIG9uIHZh bHVlcyBmb3IgJnF1b3Q7cmV0dXJuZWQmcXVvdDs/PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpPbiBPY3QgMjgsIDIwMTMsIGF0IDEzOjUwLCBBbnRob255IE5h ZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgZGlzY3Vzc2lvbiBoYXBwZW4gb24g dGhlIOKAnGRlZmF1bHTigJ0gcmV0dXJuZWQgYmVmb3JlIGNsb3Npbmcgb24gdGhpcyB0ZXh0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9h PiBbPGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNjaW0tYm91 bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjgsIDIwMTMgMTE6MjggQU08YnI+DQo8Yj5Ubzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiBXRzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbc2NpbV0gVGlja2V0IDEwIC0gQWJpbGl0eSB0byBtYXJrIGF0 dHJpYnV0ZXMgYXMgc2Vuc2l0aXZlICh3aGVuIGF0dHJzIGFyZSByZXR1cm5lZCk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciB0byBicmluZyBU aWNrZXQgMTAgKCA8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zY2ltL3Ry YWMvdGlja2V0LzEwIj4NCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3NjaW0vdHJhYy90 aWNrZXQvMTA8L2E+ICkgdG8gYSBjbG9zZSwgdGhlIGZvbGxvd2luZyBpcyBhIG5ldyBzY2hlbWEg YXR0cmlidXRlIChTZWN0aW9uIDExKSBkZWZpbml0aW9uIHdoaWNoIGRlZmluZXMgd2hlbiBhbiBh dHRyaWJ1dGUgaXMgcmV0dXJuZWQgb24gYSBxdWVyeS4gSXQgZGVmaW5lcyA0IG1vZGVzLiAmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1p bmRlbnQ6LS4yNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+cmV0 dXJuZWQgLSBBIHZhbHVlIHRoYXQgaW5kaWNhdGVzIHdoZW4gYW4gYXR0cmlidXRlJ3MgdmFsdWUg aXMgcmV0dXJuZWQgaW4gYSBTQ0lNIEdFVCBvcGVyYXRpb24gb3IgaW4gcmVzcG9uc2UgdG8gYSBQ VVQsIFBPU1QsIG9yIFBBVENIIHJlcXVlc3QuIFZhbGlkIHZhbHVlcyBhcmU6PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPm88c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5hbHdheXMgLSBUaGUgYXR0cmlidXRlIGlzIGFsd2F5cyByZXR1 cm5lZCByZWdhcmRsZXNzIG9mIHRoZSBjb250ZW50cyBvZiB0aGUgJnF1b3Q7YXR0cmlidXRlcyZx dW90OyBwYXJhbWV0ZXIgW0FQSSBTZWMgMy4yLjNdLiBGb3IgZXhhbXBsZSwgJnF1b3Q7aWQmcXVv dDsgaXMgYWx3YXlzIHJldHVybmVkIHRvIGlkZW50aWZ5IHRoZSBTQ0lNIHJlY29yZC48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO3Bh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+bzxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm5ldmVyIC0gVGhlIGF0dHJpYnV0ZSBpcyBuZXZlciBy ZXR1cm5lZC4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBpbiBSRVNUZnVsIG9wZXJhdGlvbnMgd2hl cmUgdGhlIGF0dHJpYnV0ZSBzdXBwb3J0cyBvbmx5IHVwZGF0ZSBvcGVyYXRpb25zLiBBbiBhdHRy aWJ1dGUgd2l0aCAmcXVvdDtyZXR1cm5lZCZxdW90OyBzZXQgdG8gJnF1b3Q7bmV2ZXImcXVvdDsg TUFZIGJlIHVzZWQgaW4gYSBzZWFyY2ggZmlsdGVyIFtbZGVwZW5kaW5nIG9uIGluZGV4IHN1cHBv cnRdXS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRl bnQ6LS4yNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+bzxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPmRlZmF1bHQgLSBUaGUgYXR0cmli dXRlIGlzIHJldHVybmVkIGluIFNDSU0gcmVzcG9uc2VzIGFuZCBpcyByZXR1cm5lZCB3aGVuIHRo ZSBHRVQgJnF1b3Q7YXR0cmlidXRlcyZxdW90OyBwYXJhbWV0ZXIgW0FQSSBTZWMgMy4yLjNdIGlz IG5vdCBzcGVjaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPm88c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5yZXF1ZXN0IC0g VGhlIGF0dHJpYnV0ZSBpcyByZXR1cm5lZCBpbiByZXNwb25zZSB0byBhbnkgU0NJTSBQVVQsIFBP U1QsIG9yIFBBVENIIG9wZXJhdGlvbnMgaWYgdGhlIGF0dHJpYnV0ZSB3YXMgc3BlY2lmaWVkIGJ5 IHRoZSBjbGllbnQgKGZvciBleGFtcGxlLCB0aGUgYXR0cmlidXRlIHdhcyBtb2RpZmllZCkuIFRo ZSBhdHRyaWJ1dGUgaXMgcmV0dXJuZWQgaW4gYSBTQ0lNIEdFVCBvcGVyYXRpb24gb25seSBpZiBz cGVjaWZpZWQgaW4gdGhlICZxdW90O2F0dHJpYnV0ZXMmcXVvdDsgcGFyYW1ldGVyIFtBUEkgU2Vj IDMuMi4zXS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBhZ3JlZSwgb3IgaWYgeW91IGhhdmUgY29uY2VybnMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v dGUgd2UgbWF5IG5lZWQgbW9yZSBkaXNjdXNzaW9uIG9uIHRoZSBkZWZhdWx0ICZxdW90O3JldHVy bmVkJnF1b3Q7IHZhbHVlcyBmb3Igc29tZSBhdHRyaWJ1dGVzLiAmbmJzcDtGb3Igbm93LCBJJ2xs IGNvbnN1bHQgd2l0aCBLZWxseSBhbmQgcHV0IHRvZ2V0aGVyIGEgc2V0IG9mIHByb3Bvc2VkIGRl ZmF1bHRzIChlLmcuICZxdW90O2lkJnF1b3Q7IGlzICZxdW90O2Fsd2F5cyZxdW90OykuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29t Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f28c4aab3f184202937ec45a01688719CO1PR04MB393namprd04pro_-- From mdiodati@pingidentity.com Tue Oct 29 13:15:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AA811E829D for ; Tue, 29 Oct 2013 13:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDrxykFcQ8Tv for ; Tue, 29 Oct 2013 13:15:28 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 5955311E8282 for ; Tue, 29 Oct 2013 13:15:16 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUnAXQvPfc6lWohP2go9DEk8pMuYShR5K@postini.com; Tue, 29 Oct 2013 13:15:16 PDT Received: by mail-ie0-f175.google.com with SMTP id aq17so648635iec.6 for ; Tue, 29 Oct 2013 13:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=tHjRJTyGj1QKs3JZVnmE3nNqfe0RVvbRsbOOt4ItW4g=; b=d4YE0/m/zlsKSzMCBIphw20UByuQeAeUaY/gKsGtdGYcCrYwxkpnIXT5LBzj8ZT3Tn UEtR647NFY+VBRm5scNHlMOlfalUuXc7EG2n39kqiFo5y8b+9OZB0fsxjA5GQxodqzhI M+sFZQq2RhXPZM3PBw7l2CpNoT5cQnynRymm00ohcN/WcM+/TyIUFvygZ6f98fjx13uu 8YrMjqEOFb+VXfjlls+RmFhPQAmTfrQUFU9fOyi6eF9oIRAUrTpu9FJRnDyhSGDbRgPP 2lHf3hBOOh3ybj1WQ9wdQxk2qUdzIbS8llM1M3UoUuLhW+itJYxZgTsyOCbv4q9UoEz6 in9w== X-Gm-Message-State: ALoCoQlursEyznGb1S07k5EA04zuQ69PP5vA3h9dsmy71b0Rik6OJMRTBXqDeArBhJF7Jp108F4Avl6P5ROfnN4eMSxg0yUKMHhE+IklsE27PVUJCLwozojV733ce/w3w4x+fkIOlgeFVikk8okqNMzJlp/y3i3/Mg== X-Received: by 10.50.118.41 with SMTP id kj9mr1076960igb.9.1383077678854; Tue, 29 Oct 2013 13:14:38 -0700 (PDT) X-Received: by 10.50.118.41 with SMTP id kj9mr1076951igb.9.1383077678706; Tue, 29 Oct 2013 13:14:38 -0700 (PDT) From: Mark Diodati References: <526F6A28.8010903@tarent.de> In-Reply-To: <526F6A28.8010903@tarent.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHGXudzcia/UiG/cSKNYqzM1aNpFgHvDBEEmg2hebA= Date: Tue, 29 Oct 2013 15:14:36 -0600 Message-ID: <2b1edd434e2c6eb8a2ab5382dff69e9a@mail.gmail.com> To: scim@ietf.org Content-Type: multipart/alternative; boundary=089e011769a3bca0e604e9e6dddb Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:15:36 -0000 --089e011769a3bca0e604e9e6dddb Content-Type: text/plain; charset=ISO-8859-1 +1 --089e011769a3bca0e604e9e6dddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1

=A0

--089e011769a3bca0e604e9e6dddb-- From leifj@mnt.se Tue Oct 29 13:23:37 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1054011E8294 for ; Tue, 29 Oct 2013 13:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31fB9fvR9ssj for ; Tue, 29 Oct 2013 13:23:32 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5811E80E9 for ; Tue, 29 Oct 2013 13:23:28 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id eo20so340282lab.12 for ; Tue, 29 Oct 2013 13:23:26 -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; bh=R38SHhP5K/XhxDZpxj+kR5bZXqsEfD6YzsmImsIYahY=; b=NSiUwPQDXamA3F7sc+urv1IF8EtGmm59a5KZV6ohD3dSzj2cFAMsJrq3XQIpmoCRqp RA7lj9vxchFW7je0bPC23L5qbDoOHXiJ63QzL/5l8zMCYKnmvtYfeaQqxJkrzhSUlAQU HmjHyEnATkihtrlcXbDVCYGZQPLcz/0GKW7t68uFqnCVcCkEUQynm260snc93H/1L+Ac 59kH3bUcS1GpFTYg3+uB7sdCIkv0lRV3XTd5s8jgO2M/4llDLiGUwrWcMLTc1fuWJORN 9Pfl07mwARNs0Y1avHt/h7DgI4Jwqg4nsRFgV/LTxmxzhHkgdZjb7GmF76Odqq4lcrk5 S7qA== X-Gm-Message-State: ALoCoQlESzIMTujfEVzSneApPsRhKZCYagKSJrLpEzaBVMNJGNlHrU4/3bxd6/8x5+XKtJKQbYyR X-Received: by 10.152.7.105 with SMTP id i9mr755378laa.9.1383078206478; Tue, 29 Oct 2013 13:23:26 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ao4sm27534812lac.1.2013.10.29.13.23.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 13:23:25 -0700 (PDT) Message-ID: <5270193C.7080807@mnt.se> Date: Tue, 29 Oct 2013 21:23:24 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: scim@ietf.org References: <609a469eb1de420d9a598fcc37c68962@BY2PR03MB189.namprd03.prod.outlook.com> <9677d197b4d145e49cfe42d9553bcd52@CO1PR04MB393.namprd04.prod.outlook.com> In-Reply-To: <9677d197b4d145e49cfe42d9553bcd52@CO1PR04MB393.namprd04.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010706000507020306040604" Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:23:37 -0000 This is a multi-part message in MIME format. --------------010706000507020306040604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/29/2013 07:28 PM, Kelly Grizzle wrote: > > I like the text, but think that we should also consider adding a > ServiceProviderConfig property that says whether this is supported or not. > Propose text ? > > > > --Kelly > > > > *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Anthony Nadalin > *Sent:* Monday, October 28, 2013 3:48 PM > *To:* Phil Hunt; scim@ietf.org WG > *Subject:* Re: [scim] Proposed resolution - root search optionality > (ticket 42) > > > > +1 > > > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Monday, October 28, 2013 11:47 AM > *To:* scim@ietf.org WG > *Subject:* [scim] Proposed resolution - root search optionality > (ticket 42) > > > > Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 > - http://trac.tools.ietf.org/wg/scim/trac/ticket/42 ): > > 3.2.2.1 Query Enpoints > > > Resource Queries > > A query MAY be performed against any specific resource endpoint or > resource. For example: > > * Resource (e.g. /Users/{userid}), > * Resource Type endpoint (e.g. /Users or /Groups) > > > Root Queries > > A server MAY support queries at the server root (e.g. /) for the > purpose of returning resources of more than one resource type. > > A search against a server root indicates that ALL resources within the > server SHALL be included subject to filtering. For example, a filter > against 'meta.resourceType' could be used to restrict results to one > or more specific resource types. > > When processing search operations across endpoints that include more > than one SCIM resource type (e.g. a search from the server root > endpoint), filters MUST be processed in the same fashion as outlined > in Section 3.2.2.2. For filtered attributes that are not part of a > particular resource type, the service provider SHALL treat the > attribute as if there is no attribute value. For example, a presence > or equality filter for an undefined attribute evaluates as FALSE. > > _Please confirm_if you agree with this subtle change which makes root > searches optional to the server. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------010706000507020306040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/29/2013 07:28 PM, Kelly Grizzle wrote:

I like the text, but think that we should also consider adding a ServiceProviderConfig property that says whether this is supported or not.

Propose text ?

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Monday, October 28, 2013 3:48 PM
To: Phil Hunt; scim@ietf.org WG
Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42)

 

+1

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:47 AM
To: scim@ietf.org WG
Subject: [scim] Proposed resolution - root search optionality (ticket 42)

 

Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - http://trac.tools.ietf.org/wg/scim/trac/ticket/42 ):

3.2.2.1 Query Enpoints

Resource Queries

A query MAY be performed against any specific resource endpoint or resource. For example:

  • Resource (e.g. /Users/{userid}),
  • Resource Type endpoint (e.g. /Users or /Groups)

Root Queries

A server MAY support queries at the server root (e.g. /) for the purpose of returning resources of more than one resource type.

A search against a server root indicates that ALL resources within the server SHALL be included subject to filtering. For example, a filter against 'meta.resourceType' could be used to restrict results to one or more specific resource types.

When processing search operations across endpoints that include more than one SCIM resource type (e.g. a search from the server root endpoint), filters MUST be processed in the same fashion as outlined in Section 3.2.2.2. For filtered attributes that are not part of a particular resource type, the service provider SHALL treat the attribute as if there is no attribute value. For example, a presence or equality filter for an undefined attribute evaluates as FALSE.

Please confirm if you agree with this subtle change which makes root searches optional to the server.

 

Phil

 

@independentid

phil.hunt@oracle.com

 



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

--------------010706000507020306040604-- From leifj@mnt.se Tue Oct 29 13:24:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38411E828E for ; Tue, 29 Oct 2013 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJijNf9wSyf3 for ; Tue, 29 Oct 2013 13:24:31 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3A611E80E9 for ; Tue, 29 Oct 2013 13:24:30 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id w6so487480lbh.13 for ; Tue, 29 Oct 2013 13:24:30 -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; bh=sXg8tn1gg2TvrN0ISj+wxDvhY680ObTNqU13uj6xFSY=; b=eohCQexJybncavo/n1gSw8CNU3OLYn11dGMxByqPwG6l6wy01QdNfaGM6VwT/aujHt OF/u/OjCNDMMSh0hfBpefqSCZ4wqTcrMst5xKh4r2VveyKi+FBSLEqSBKRqfB20Avl0I swdWWGi77PW9534xHnJ4/DGZ4ZIbKFKJNpUW+xEg6e72cOnsDBpHPEvT+USGmjNSenBT jVau4CrB8ops/TAEEQyeIPrcX2K4eohOYMaTuNFWJaz2G0I6iWD5y8tWth8Lj4gxkfXL JsGnFH4pMRlU4Wj17rrO00FcJGAVM5IISOO+wUwbmoaP9VioPc/zggqZ6J+bTlPeEPQY a44A== X-Gm-Message-State: ALoCoQmEtPzYDmfy/fR2LRpOkcF3WBnKWLx6SCYs+uaQx2xlRRYp3OtJI8V+84XAKuHaM7i1Jn8B X-Received: by 10.152.3.226 with SMTP id f2mr55769laf.62.1383078270107; Tue, 29 Oct 2013 13:24:30 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id 8sm27526250laq.5.2013.10.29.13.24.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 13:24:29 -0700 (PDT) Message-ID: <5270197C.4010201@mnt.se> Date: Tue, 29 Oct 2013 21:24:28 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: scim@ietf.org References: <526F6A28.8010903@tarent.de> <2b1edd434e2c6eb8a2ab5382dff69e9a@mail.gmail.com> In-Reply-To: <2b1edd434e2c6eb8a2ab5382dff69e9a@mail.gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------090908040705010106030301" Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:24:44 -0000 This is a multi-part message in MIME format. --------------090908040705010106030301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/29/2013 10:14 PM, Mark Diodati wrote: > > +1 > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim This looks like consensus to me. --------------090908040705010106030301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/29/2013 10:14 PM, Mark Diodati wrote:

+1

 



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
This looks like consensus to me.
--------------090908040705010106030301-- From kelly.grizzle@sailpoint.com Tue Oct 29 14:28:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FAC11E8255 for ; Tue, 29 Oct 2013 14:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3kIK6ybFHMU for ; Tue, 29 Oct 2013 14:28:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5FE11E824C for ; Tue, 29 Oct 2013 14:27:48 -0700 (PDT) Received: from CO1PR04MB393.namprd04.prod.outlook.com (10.141.75.16) by CO1PR04MB394.namprd04.prod.outlook.com (10.141.75.23) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 21:27:40 +0000 Received: from CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.173]) by CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.133]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 21:27:40 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Proposed resolution - root search optionality (ticket 42) Thread-Index: AQHO1A4KOlaOMHv1bEK7+jWYZUqh2JoKlc8AgAFrRqCAACA+AIAAEP6g Date: Tue, 29 Oct 2013 21:27:40 +0000 Message-ID: <50a1dc0195b04f7ab7cd1a6bcd1674fb@CO1PR04MB393.namprd04.prod.outlook.com> References: <609a469eb1de420d9a598fcc37c68962@BY2PR03MB189.namprd03.prod.outlook.com> <9677d197b4d145e49cfe42d9553bcd52@CO1PR04MB393.namprd04.prod.outlook.com> <5270193C.7080807@mnt.se> In-Reply-To: <5270193C.7080807@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 25C7BFEB00593825C7C138 x-originating-ip: [10.255.124.4] x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(479174003)(377454003)(54316002)(56776001)(33646001)(74316001)(76482001)(16601075003)(83322001)(31966008)(19580395003)(56816003)(74502001)(16236675002)(76576001)(76796001)(74662001)(47446002)(87266001)(76786001)(83072001)(77096001)(19300405004)(47736001)(80976001)(49866001)(85306002)(59766001)(551544002)(53806001)(77982001)(54356001)(74876001)(81542001)(65816001)(80022001)(50986001)(47976001)(81816001)(15202345003)(79102001)(85806002)(51856001)(4396001)(74706001)(81686001)(81342001)(74366001)(19580405001)(63696002)(46102001)(69226001)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB394; H:CO1PR04MB393.namprd04.prod.outlook.com; CLIP:10.255.124.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_50a1dc0195b04f7ab7cd1a6bcd1674fbCO1PR04MB393namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Proposed resolution - root search optionality (ticket 42) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:28:10 -0000 --_000_50a1dc0195b04f7ab7cd1a6bcd1674fbCO1PR04MB393namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Schema doc section 9 (Service Provider Configuration Schema) - add the foll= owing attribute between the filter and changePassword attributes: rootSearch A complex type that specifies root search configuration opti= ons. REQUIRED. supported Boolean value specifying whether root search is supported.= REQUIRED. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Tuesday, October 29, 2013 3:23 PM To: scim@ietf.org Subject: Re: [scim] Proposed resolution - root search optionality (ticket 4= 2) On 10/29/2013 07:28 PM, Kelly Grizzle wrote: I like the text, but think that we should also consider adding a ServicePro= viderConfig property that says whether this is supported or not. Propose text ? --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Anthony Nadalin Sent: Monday, October 28, 2013 3:48 PM To: Phil Hunt; scim@ietf.org WG Subject: Re: [scim] Proposed resolution - root search optionality (ticket 4= 2) +1 From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Monday, October 28, 2013 11:47 AM To: scim@ietf.org WG Subject: [scim] Proposed resolution - root search optionality (ticket 42) Proposed text. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - ht= tp://trac.tools.ietf.org/wg/scim/trac/ticket/42 ): 3.2.2.1 Query Enpoints Resource Queries A query MAY be performed against any specific resource endpoint or resource= . For example: * Resource (e.g. /Users/{userid}), * Resource Type endpoint (e.g. /Users or /Groups) Root Queries A server MAY support queries at the server root (e.g. /) for the purpose of= returning resources of more than one resource type. A search against a server root indicates that ALL resources within the serv= er SHALL be included subject to filtering. For example, a filter against 'm= eta.resourceType' could be used to restrict results to one or more specific= resource types. When processing search operations across endpoints that include more than o= ne SCIM resource type (e.g. a search from the server root endpoint), filter= s MUST be processed in the same fashion as outlined in Section 3.2.2.2. For= filtered attributes that are not part of a particular resource type, the s= ervice provider SHALL treat the attribute as if there is no attribute value= . For example, a presence or equality filter for an undefined attribute eva= luates as FALSE. Please confirm if you agree with this subtle change which makes root search= es optional to the server. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_50a1dc0195b04f7ab7cd1a6bcd1674fbCO1PR04MB393namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Schema doc section 9 (Ser= vice Provider Configuration Schema) – add the following attribute bet= ween the filter and changePassword attributes:

 <= /p>

   rootSearc= h  A complex type that specifies root search configuration options.

   &nbs= p;  REQUIRED.

 

   &nbs= p;  supported  Boolean value specifying whether root search is su= pported.  REQUIRED.

 <= /p>

--Kelly=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Leif Johansson
Sent: Tuesday, October 29, 2013 3:23 PM
To: scim@ietf.org
Subject: Re: [scim] Proposed resolution - root search optionality (t= icket 42)

 

On 10/29/2013 07:28 PM, Kelly Grizzle wrote:

I like the text, but thin= k that we should also consider adding a ServiceProviderConfig property that= says whether this is supported or not.

Propose text ?

 <= /p>

--Kelly=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Monday, October 28, 2013 3:48 PM
To: Phil Hunt; scim@ietf.org WG=
Subject: Re: [scim] Proposed resolution - root search optionality (t= icket 42)

 

+1<= /p>

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 11:47 AM
To: scim@ietf.org WG
Subject: [scim] Proposed resolution - root search optionality (ticke= t 42)

 

Proposed tex= t. Replace section 3.2.2.1 Query Endpoints with (ticket 42 - http://trac.t= ools.ietf.org/wg/scim/trac/ticket/42 ):

3.2.2.1 Query Enpoin= ts

Resource Queries

A query MAY be performed against = any specific resource endpoint or resource. For example:<= /p>

  • Resource (e.g. /Users/{userid}),
  • Resource Type endpoint (e.g. /Users or /Groups)

Root Queries

A server MAY support= queries at the server root (e.g. /) for the purpose of returning resources= of more than one resource type.

A search against a server root in= dicates that ALL resources within the server SHALL be included subject to f= iltering. For example, a filter against 'meta.resourceType' could be used to restrict results to one or more specific resource types.<= /span>

When processing sear= ch operations across endpoints that include more than one SCIM resource typ= e (e.g. a search from the server root endpoint), filters MUST be processed in the same fashion as outlined in Section 3.2.2.2. For = filtered attributes that are not part of a particular resource type, the se= rvice provider SHALL treat the attribute as if there is no attribute value.= For example, a presence or equality filter for an undefined attribute evaluates as FALSE.

Please confirm if you agree with this subtle chan= ge which makes root searches optional to the server.

 

Phil

 

@independentid

phil.hunt@oracle.com

 




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

 

--_000_50a1dc0195b04f7ab7cd1a6bcd1674fbCO1PR04MB393namprd04pro_-- From phil.hunt@oracle.com Wed Oct 30 12:04:10 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5D011E8220 for ; Wed, 30 Oct 2013 12:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPCyW5O34ssk for ; Wed, 30 Oct 2013 12:03:53 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BE31A11E8155 for ; Wed, 30 Oct 2013 12:03:50 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9UJ3iHp025042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 19:03:45 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UJ3heD006589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 19:03:44 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UJ3hF7005635; Wed, 30 Oct 2013 19:03:43 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Oct 2013 12:03:28 -0700 References: <062.e1a704a73b79f55f1752bf205b939ca0@tools.ietf.org> <077.77ce3ce867ffd9b7fbccac83eea8de41@tools.ietf.org> Mime-Version: 1.0 (1.0) In-Reply-To: <077.77ce3ce867ffd9b7fbccac83eea8de41@tools.ietf.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <61224208-2F3F-40A6-953F-3457F02226FE@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Wed, 30 Oct 2013 12:03:24 -0700 To: scim issue tracker X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , "chris.phillips@canarie.ca" , "kelly.grizzle@sailpoint.com" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:04:10 -0000 Chris I am not sure how visibility is related to policy. This is strictly a protoc= ol issue. You still need to define policy on top that says who may see what etc. but t= his doesn't impact when the protocol has indicated or not that an attribute i= s requested for return. =20 Phil > On Oct 30, 2013, at 11:42, scim issue tracker w= rote: >=20 > #10: Add ability to mark attributes as sensitive in the schemas >=20 >=20 > Comment (by chris.phillips@canarie.ca): >=20 > Replying to [comment:5 phil.hunt@=E2=80=A6]: >> In order to bring Ticket 10 ( > http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the > following is a new schema attribute (Section 11) definition which defines > when an attribute is returned on a query. It defines 4 modes. >> {{{ >> returned - A value that indicates when an attribute's value is returned > in a SCIM GET >> operation or in response to a PUT, POST, or PATCH request. Valid values > are: >> * always - The attribute is always returned regardless of the contents > of the "attributes" parameter [API Sec 3.2.3]. For example, "id" is always= > returned to identify the SCIM record. >> * never - The attribute is never returned. This is typically used in > RESTful operations where the attribute supports only update operations. An= > attribute with "returned" set to "never" MAY be used in a search filter > [[depending on index support]]. >> * default - The attribute is returned in SCIM responses and is returned > when the GET "attributes" parameter [API Sec 3.2.3] is not specified. >> * request - The attribute is returned in response to any SCIM PUT, > POST, or PATCH operations if the attribute was specified by the client > (for example, the attribute was modified). The attribute is returned in a > SCIM GET operation only if specified in the "attributes" parameter [API > Sec 3.2.3]. >> }}} >>=20 >> Please let me know if you agree, or if you have concerns. >>=20 >> Note we may need more discussion on the default "returned" values for > some attributes. For now, I'll consult with Kelly and put together a set > of proposed defaults (e.g. "id" is "always"). >=20 > Hi Phil & community. >=20 > Please see comment in ticket #11 regarding SCIM and how it captures (or > doesn't) security policies: >=20 > "I would propose to the SCIM community that if this model proceeds that > there is agreement to the principle that SCIM does not embody policy nor > enforce it beyond what is in the specification today. These elements are > layered on top of SCIM." >=20 > I think that the elephant in the room around a few of these tickets > (current state of 10, ticket #11) is a contemplation and recommendation of= > what style of policies we want to recognize SCIM as the protocol to > implement policy to content it transits. >=20 > To seed the topic further: >=20 > As I see it, SCIM currently relies on endpoints for security and the > policy enforcement. SCIM doesn't have a lot of instrumentation to do much= > around putting into effect any of the security mechanisms or policies on > it's own and does not police compliance(e.g. little to none in referential= > integrity and no enforcement of rules either e.g. 'if this attribute A > has value X, attribute B MUST not have value Z'). The offshoot is that > it's all about attributes and the content, not the control infrastructure.= > That's up to the endpoints to capture and enforce and if a response > violates it throw an appropriate error message to trigger the re- > evaluation of the request. >=20 > If we don't abstract things out in this fashion what will happen is we are= > going to get a Frankenstein control infrastructure that is a hodge podge > of practices but not standards (is there a standard for group management? > is there a standard for role based access control?) which will reflect > what we know of today but not be 'evergreen' for times to come. It will > also be contradictory to one audience at the expense of another. > For instance, if I'm an organization that adopts the pattern of group > based access control but engage a SCIM endpoint that is entitlement based,= > how will I ever get data from point A to point B without hammering > something into the data and transcoding one model to another?? > How will I ever know that my patterns on policy and security hold true? > In a model where it's at the endpoint, I can evaluate it there without > worry of some in transit data may skew my evaluation. >=20 > I would like to engage the community on the track that the act of > codifying policy should be done on top of SCIM and SCIM be preserved as a > method to transit the data unfiltered. >=20 > If the community thinks otherwise (as this post is below) then I would > like to understand the rational more deeply than is expressed today which > would include why it couldn't be done at the edge and what's the value > proposition to embed it in SCIM. There are existing protocols (LDAP being= > one) that have richly defined concepts so why should we not either adopt a= > pre-existing model instead of creating yet another one? >=20 > --=20 > -------------------------------------+----------------------------------- > Reporter: melinda.shore@gmail.com | Owner: phil.hunt@oracle.com > Type: enhancement | Status: new > Priority: major | Milestone: > Component: core-schema | Version: > Severity: - | Resolution: > Keywords: | > -------------------------------------+----------------------------------- >=20 > Ticket URL: > scim >=20 From Chris.Phillips@canarie.ca Wed Oct 30 12:11:13 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227111E8185 for ; Wed, 30 Oct 2013 12:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl80ymm5ybHF for ; Wed, 30 Oct 2013 12:11:08 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9EF21F9D38 for ; Wed, 30 Oct 2013 12:11:08 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Wed, 30 Oct 2013 15:11:07 -0400 From: Chris Phillips To: Phil Hunt , scim issue tracker Date: Wed, 30 Oct 2013 15:11:04 -0400 Thread-Topic: [scim] #10: Add ability to mark attributes as sensitive in the schemas Thread-Index: Ac7Vo8kgbypTRpNFT8qkh7pBh+pWBg== Message-ID: In-Reply-To: <61224208-2F3F-40A6-953F-3457F02226FE@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "scim@ietf.org" , "kelly.grizzle@sailpoint.com" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:11:13 -0000 Maybe I'm not understanding it well enough. Who or what actor in the SCIM model consumes and acts on the 'always, never, default, request' modes ? Is it appropriate for me to presume it's the implementation of the SCIM endpoint then? Chris. On 13-10-30 3:03 PM, "Phil Hunt" wrote: >Chris > >I am not sure how visibility is related to policy. This is strictly a >protocol issue. > >You still need to define policy on top that says who may see what etc. >but this doesn't impact when the protocol has indicated or not that an >attribute is requested for return. > >Phil > >> On Oct 30, 2013, at 11:42, scim issue tracker >> wrote: >>=20 >> #10: Add ability to mark attributes as sensitive in the schemas >>=20 >>=20 >> Comment (by chris.phillips@canarie.ca): >>=20 >> Replying to [comment:5 phil.hunt@=8A]: >>> In order to bring Ticket 10 ( >> http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the >> following is a new schema attribute (Section 11) definition which >>defines >> when an attribute is returned on a query. It defines 4 modes. >>> {{{ >>> returned - A value that indicates when an attribute's value is returned >> in a SCIM GET >>> operation or in response to a PUT, POST, or PATCH request. Valid values >> are: >>> * always - The attribute is always returned regardless of the contents >> of the "attributes" parameter [API Sec 3.2.3]. For example, "id" is >>always >> returned to identify the SCIM record. >>> * never - The attribute is never returned. This is typically used in >> RESTful operations where the attribute supports only update operations. >>An >> attribute with "returned" set to "never" MAY be used in a search filter >> [[depending on index support]]. >>> * default - The attribute is returned in SCIM responses and is returned >> when the GET "attributes" parameter [API Sec 3.2.3] is not specified. >>> * request - The attribute is returned in response to any SCIM PUT, >> POST, or PATCH operations if the attribute was specified by the client >> (for example, the attribute was modified). The attribute is returned in >>a >> SCIM GET operation only if specified in the "attributes" parameter [API >> Sec 3.2.3]. >>> }}} >>>=20 >>> Please let me know if you agree, or if you have concerns. >>>=20 >>> Note we may need more discussion on the default "returned" values for >> some attributes. For now, I'll consult with Kelly and put together a >>set >> of proposed defaults (e.g. "id" is "always"). >>=20 >> Hi Phil & community. >>=20 >> Please see comment in ticket #11 regarding SCIM and how it captures (or >> doesn't) security policies: >>=20 >> "I would propose to the SCIM community that if this model proceeds that >> there is agreement to the principle that SCIM does not embody policy nor >> enforce it beyond what is in the specification today. These elements are >> layered on top of SCIM." >>=20 >> I think that the elephant in the room around a few of these tickets >> (current state of 10, ticket #11) is a contemplation and recommendation >>of >> what style of policies we want to recognize SCIM as the protocol to >> implement policy to content it transits. >>=20 >> To seed the topic further: >>=20 >> As I see it, SCIM currently relies on endpoints for security and the >> policy enforcement. SCIM doesn't have a lot of instrumentation to do >>much >> around putting into effect any of the security mechanisms or policies on >> it's own and does not police compliance(e.g. little to none in >>referential >> integrity and no enforcement of rules either e.g. 'if this attribute A >> has value X, attribute B MUST not have value Z'). The offshoot is that >> it's all about attributes and the content, not the control >>infrastructure. >> That's up to the endpoints to capture and enforce and if a response >> violates it throw an appropriate error message to trigger the re- >> evaluation of the request. >>=20 >> If we don't abstract things out in this fashion what will happen is we >>are >> going to get a Frankenstein control infrastructure that is a hodge podge >> of practices but not standards (is there a standard for group >>management? >> is there a standard for role based access control?) which will reflect >> what we know of today but not be 'evergreen' for times to come. It will >> also be contradictory to one audience at the expense of another. >> For instance, if I'm an organization that adopts the pattern of group >> based access control but engage a SCIM endpoint that is entitlement >>based, >> how will I ever get data from point A to point B without hammering >> something into the data and transcoding one model to another?? >> How will I ever know that my patterns on policy and security hold true? >> In a model where it's at the endpoint, I can evaluate it there without >> worry of some in transit data may skew my evaluation. >>=20 >> I would like to engage the community on the track that the act of >> codifying policy should be done on top of SCIM and SCIM be preserved as >>a >> method to transit the data unfiltered. >>=20 >> If the community thinks otherwise (as this post is below) then I would >> like to understand the rational more deeply than is expressed today >>which >> would include why it couldn't be done at the edge and what's the value >> proposition to embed it in SCIM. There are existing protocols (LDAP >>being >> one) that have richly defined concepts so why should we not either >>adopt a >> pre-existing model instead of creating yet another one? >>=20 >> --=20 >>=20 >>-------------------------------------+----------------------------------- >> Reporter: melinda.shore@gmail.com | Owner: phil.hunt@oracle.com >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: core-schema | Version: >> Severity: - | Resolution: >> Keywords: | >>=20 >>-------------------------------------+----------------------------------- >>=20 >> Ticket URL:=20 >> >> scim >>=20 From phil.hunt@oracle.com Wed Oct 30 12:28:57 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6816511E818E for ; Wed, 30 Oct 2013 12:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wwVn7Iur0An for ; Wed, 30 Oct 2013 12:28:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA811E8220 for ; Wed, 30 Oct 2013 12:28:48 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9UJSjP3021111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 19:28:46 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 r9UJSip5025586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 19:28:45 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UJSihs025538; Wed, 30 Oct 2013 19:28:44 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Oct 2013 12:28:44 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Wed, 30 Oct 2013 12:29:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B211446-0FC6-493F-8901-0C6CCE99C965@oracle.com> References: To: Chris Phillips X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , scim issue tracker , "kelly.grizzle@sailpoint.com" Subject: Re: [scim] #10: Add ability to mark attributes as sensitive in the schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:28:59 -0000 Chris, All this does is make clear how the attributes parameter is interpreted = by the server. This has nothing to do with whether the client has the right to read or = update anything. If you want to have a very simplistic implementation, you could make all = attributes returned by "default".=20 However you will immediately run into issues like: 1. If a client requests attribute mail for all records that match a = filter, how does the client know what record it came from if multiple = records are returned. This brings up the first case that "id" MUST = always be returned. 2. Some values are hashed and thus cannot be returned. They are = effectively write only. Doesn't matter what policy is, they cannot be = read (well you could return the hash if you really want to). So this = brings up the case "never". 3. "default" and "request" are intended for differentiating between = what is "typical" attributes that clients will want, and SP schema, or = operational data clients aren't normally interested in. So for = example, in many cases clients might not want things like created = timestamps, etc. These attributes can be made "request" only meaning = they are only returned if requested. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-30, at 12:11 PM, Chris Phillips = wrote: > Maybe I'm not understanding it well enough. >=20 > Who or what actor in the SCIM model consumes and acts on the 'always, > never, default, request' modes ? >=20 > Is it appropriate for me to presume it's the implementation of the = SCIM > endpoint then? >=20 > Chris. >=20 >=20 >=20 > On 13-10-30 3:03 PM, "Phil Hunt" wrote: >=20 >> Chris >>=20 >> I am not sure how visibility is related to policy. This is strictly a >> protocol issue. >>=20 >> You still need to define policy on top that says who may see what = etc. >> but this doesn't impact when the protocol has indicated or not that = an >> attribute is requested for return. >>=20 >> Phil >>=20 >>> On Oct 30, 2013, at 11:42, scim issue tracker >>> wrote: >>>=20 >>> #10: Add ability to mark attributes as sensitive in the schemas >>>=20 >>>=20 >>> Comment (by chris.phillips@canarie.ca): >>>=20 >>> Replying to [comment:5 phil.hunt@=8A]: >>>> In order to bring Ticket 10 ( >>> http://trac.tools.ietf.org/wg/scim/trac/ticket/10 ) to a close, the >>> following is a new schema attribute (Section 11) definition which >>> defines >>> when an attribute is returned on a query. It defines 4 modes. >>>> {{{ >>>> returned - A value that indicates when an attribute's value is = returned >>> in a SCIM GET >>>> operation or in response to a PUT, POST, or PATCH request. Valid = values >>> are: >>>> * always - The attribute is always returned regardless of the = contents >>> of the "attributes" parameter [API Sec 3.2.3]. For example, "id" is >>> always >>> returned to identify the SCIM record. >>>> * never - The attribute is never returned. This is typically used = in >>> RESTful operations where the attribute supports only update = operations. >>> An >>> attribute with "returned" set to "never" MAY be used in a search = filter >>> [[depending on index support]]. >>>> * default - The attribute is returned in SCIM responses and is = returned >>> when the GET "attributes" parameter [API Sec 3.2.3] is not = specified. >>>> * request - The attribute is returned in response to any SCIM PUT, >>> POST, or PATCH operations if the attribute was specified by the = client >>> (for example, the attribute was modified). The attribute is returned = in >>> a >>> SCIM GET operation only if specified in the "attributes" parameter = [API >>> Sec 3.2.3]. >>>> }}} >>>>=20 >>>> Please let me know if you agree, or if you have concerns. >>>>=20 >>>> Note we may need more discussion on the default "returned" values = for >>> some attributes. For now, I'll consult with Kelly and put together = a >>> set >>> of proposed defaults (e.g. "id" is "always"). >>>=20 >>> Hi Phil & community. >>>=20 >>> Please see comment in ticket #11 regarding SCIM and how it captures = (or >>> doesn't) security policies: >>>=20 >>> "I would propose to the SCIM community that if this model proceeds = that >>> there is agreement to the principle that SCIM does not embody policy = nor >>> enforce it beyond what is in the specification today. These elements = are >>> layered on top of SCIM." >>>=20 >>> I think that the elephant in the room around a few of these tickets >>> (current state of 10, ticket #11) is a contemplation and = recommendation >>> of >>> what style of policies we want to recognize SCIM as the protocol to >>> implement policy to content it transits. >>>=20 >>> To seed the topic further: >>>=20 >>> As I see it, SCIM currently relies on endpoints for security and the >>> policy enforcement. SCIM doesn't have a lot of instrumentation to = do >>> much >>> around putting into effect any of the security mechanisms or = policies on >>> it's own and does not police compliance(e.g. little to none in >>> referential >>> integrity and no enforcement of rules either e.g. 'if this = attribute A >>> has value X, attribute B MUST not have value Z'). The offshoot is = that >>> it's all about attributes and the content, not the control >>> infrastructure. >>> That's up to the endpoints to capture and enforce and if a response >>> violates it throw an appropriate error message to trigger the re- >>> evaluation of the request. >>>=20 >>> If we don't abstract things out in this fashion what will happen is = we >>> are >>> going to get a Frankenstein control infrastructure that is a hodge = podge >>> of practices but not standards (is there a standard for group >>> management? >>> is there a standard for role based access control?) which will = reflect >>> what we know of today but not be 'evergreen' for times to come. It = will >>> also be contradictory to one audience at the expense of another. >>> For instance, if I'm an organization that adopts the pattern of = group >>> based access control but engage a SCIM endpoint that is entitlement >>> based, >>> how will I ever get data from point A to point B without hammering >>> something into the data and transcoding one model to another?? >>> How will I ever know that my patterns on policy and security hold = true? >>> In a model where it's at the endpoint, I can evaluate it there = without >>> worry of some in transit data may skew my evaluation. >>>=20 >>> I would like to engage the community on the track that the act of >>> codifying policy should be done on top of SCIM and SCIM be preserved = as >>> a >>> method to transit the data unfiltered. >>>=20 >>> If the community thinks otherwise (as this post is below) then I = would >>> like to understand the rational more deeply than is expressed today >>> which >>> would include why it couldn't be done at the edge and what's the = value >>> proposition to embed it in SCIM. There are existing protocols (LDAP >>> being >>> one) that have richly defined concepts so why should we not either >>> adopt a >>> pre-existing model instead of creating yet another one? >>>=20 >>> --=20 >>>=20 >>> = -------------------------------------+----------------------------------- >>> Reporter: melinda.shore@gmail.com | Owner: = phil.hunt@oracle.com >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: core-schema | Version: >>> Severity: - | Resolution: >>> Keywords: | >>>=20 >>> = -------------------------------------+----------------------------------- >>>=20 >>> Ticket URL:=20 >>> >>> scim >>>=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Oct 30 13:41:16 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E30111E822E for ; Wed, 30 Oct 2013 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3nmEGtkG9+e for ; Wed, 30 Oct 2013 13:41:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id BDD8711E80E2 for ; Wed, 30 Oct 2013 13:41:11 -0700 (PDT) Received: from CO1PR04MB393.namprd04.prod.outlook.com (10.141.75.16) by CO1PR04MB395.namprd04.prod.outlook.com (10.141.75.28) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 30 Oct 2013 20:41:09 +0000 Received: from CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.173]) by CO1PR04MB393.namprd04.prod.outlook.com ([169.254.1.133]) with mapi id 15.00.0785.001; Wed, 30 Oct 2013 20:41:08 +0000 From: Kelly Grizzle To: Phil Hunt , "scim@ietf.org WG" Thread-Topic: [scim] Proposal for attribute indexing Thread-Index: AQHO1DB8wg/y1w3iE0ehgc+8WYzNaJoNspSg Date: Wed, 30 Oct 2013 20:41:07 +0000 Message-ID: <7ea7b708e82d4ce9b32ca9408091cae3@CO1PR04MB393.namprd04.prod.outlook.com> References: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> In-Reply-To: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 2AC380940059502AC381E1 x-originating-ip: [10.255.156.132] x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(81686001)(81816001)(16601075003)(31966008)(15202345003)(85306002)(33646001)(561944002)(77096001)(76796001)(56816003)(76576001)(19609705001)(85806002)(15975445006)(76786001)(65816001)(16236675002)(74876001)(54356001)(46102001)(53806001)(51856001)(74366001)(81342001)(81542001)(69226001)(19580405001)(19580395003)(54316002)(76482001)(74502001)(74662001)(56776001)(47446002)(80022001)(19300405004)(83072001)(74316001)(74706001)(59766001)(47736001)(4396001)(49866001)(63696002)(79102001)(77982001)(47976001)(83322001)(50986001)(80976001)(87266001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB395; H:CO1PR04MB393.namprd04.prod.outlook.com; CLIP:10.255.156.132; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7ea7b708e82d4ce9b32ca9408091cae3CO1PR04MB393namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Proposal for attribute indexing X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 20:41:16 -0000 --_000_7ea7b708e82d4ce9b32ca9408091cae3CO1PR04MB393namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So ... would the value of the "indexed" attribute be an array of strings, o= r would it be a comma-separated string that contains the available indexes?= For example: "indexed": [ "eq", "sw" ] Or: "indexed": "eq, sw" A few other comments: 1) The examples in sections 12.5 and 12.7 should be updated to include= these new attributes. 2) The name "indexed" throws me off a little bit ... it sounds more li= ke a true/false boolean property. Maybe change this to "indexes" or "filte= rOperators"? 3) "To further values are defined" <-- Should "To" be "The" here? 4) unindexedFilters - It seems like this should be a sub-attribute of = the "filter" attribute in section 9. Maybe change this to be a bit more sp= ecific (eg - "allowUnindexedFilters"). --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Monday, October 28, 2013 5:53 PM To: scim@ietf.org WG Subject: [scim] Proposal for attribute indexing Please indicate your approval or comments with the following proposal for T= icket 47 ( http://trac.tools.ietf.org/wg/scim/trac/ticket/47 ) It is proposed that the following attribute is to be added to section 11 of= the scim-core-schema draft to aid discovery of available searches for attr= ibutes: indexed - One or more keyword values indicating the type of filters that MA= Y be used with the attribute. Valid values are the filter operators defined in sectio= n 3.2.2.2. For example, "eq" indicates the attribute and operator value must be identi= cal for a match. To further values are defined: * any - any filter may be used. * none - no filter operator may be used with this attribute. In section 9 of scim-core-schema, the service provider schema will have a n= ew attribute as follows: unindexedFilters - A Boolean value indicating whether searches filters usin= g unindexed attributes are supported. Additionally the following text is included in section 3.2.2.2 of the scim-= api draft: For any filter for which there is no index available and unindexed searchin= g is not available, the server SHALL evaluate the the filter term as not matc= hed. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_7ea7b708e82d4ce9b32ca9408091cae3CO1PR04MB393namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So … would the valu= e of the “indexed” attribute be an array of strings, or would i= t be a comma-separated string that contains the available indexes?  Fo= r example:

 <= /p>

  “indexedR= 21;: [ “eq”, “sw” ]

 <= /p>

Or:

 <= /p>

  “indexedR= 21;: “eq, sw”

 <= /p>

 <= /p>

A few other comments:

1) = ;     The examples in s= ections 12.5 and 12.7 should be updated to include these new attributes.

2) = ;     The name “i= ndexed” throws me off a little bit … it sounds more like a true= /false boolean property.  Maybe change this to “indexes” o= r “filterOperators”?

3) = ;      “To f= urther values are defined” <-- Should “To” be “T= he” here?

4) = ;     unindexedFilters = – It seems like this should be a sub-attribute of the “filter&#= 8221; attribute in section 9.  Maybe change this to be a bit more spec= ific (eg – “allowUnindexedFilters”).

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 28, 2013 5:53 PM
To: scim@ietf.org WG
Subject: [scim] Proposal for attribute indexing

 

Please indicate your approval or comments with the f= ollowing proposal for Ticket 47 ( http://trac.t= ools.ietf.org/wg/scim/trac/ticket/47 )

 

It is proposed that the following attribute is= to be added to section 11 of the scim-core-schema draft to aid discovery o= f available searches for attributes:

indexed - One or more keyword values indicating th=
e type of filters that MAY be used 
with the attribute. Valid values are the filter operators define=
d in section 3.2.2.2. 
For example, "eq" indicates the attribute and operator=
 value must be identical for 
a match. To further values are defined:
* any - any filter may be used.
* none - no filter operator may be used with this attribute.

In section 9 of scim-core-schema, the service = provider schema will have a new attribute as follows:

unindexedFilters - A Boolean value indicating whet=
her searches filters using unindexed 
attributes are supported.

Additionally the following text is included in= section 3.2.2.2 of the scim-api draft:

For any filter for which there is no index availab=
le and unindexed searching 
is not available, the server SHALL evaluate the the filter term =
as not matched.

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

--_000_7ea7b708e82d4ce9b32ca9408091cae3CO1PR04MB393namprd04pro_-- From phil.hunt@oracle.com Wed Oct 30 15:09:44 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1708B11E81B4 for ; Wed, 30 Oct 2013 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXI1jmd0yvrI for ; Wed, 30 Oct 2013 15:09:38 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 02DB011E81DE for ; Wed, 30 Oct 2013 15:09:37 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9UM9asR001941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 22:09:37 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 r9UM9Zsv028902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 22:09:36 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UM9ZNr028898; Wed, 30 Oct 2013 22:09:35 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Oct 2013 15:09:35 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_D0B7F738-C869-4D59-95CA-5664E1CE45F2" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <7ea7b708e82d4ce9b32ca9408091cae3@CO1PR04MB393.namprd04.prod.outlook.com> Date: Wed, 30 Oct 2013 15:10:37 -0700 Message-Id: <6CA71EE2-F825-4F5D-8967-1140C7C20AE3@oracle.com> References: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> <7ea7b708e82d4ce9b32ca9408091cae3@CO1PR04MB393.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org WG" Subject: Re: [scim] Proposal for attribute indexing X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:09:44 -0000 --Apple-Mail=_D0B7F738-C869-4D59-95CA-5664E1CE45F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 these seem like reasonable comments. I am neutral on the array vs. comma separated list. What's typical for = what we have so far?=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-30, at 1:41 PM, Kelly Grizzle = wrote: > So =85 would the value of the =93indexed=94 attribute be an array of = strings, or would it be a comma-separated string that contains the = available indexes? For example: > =20 > =93indexed=94: [ =93eq=94, =93sw=94 ] > =20 > Or: > =20 > =93indexed=94: =93eq, sw=94 > =20 > =20 > A few other comments: > 1) The examples in sections 12.5 and 12.7 should be updated to = include these new attributes. > 2) The name =93indexed=94 throws me off a little bit =85 it = sounds more like a true/false boolean property. Maybe change this to = =93indexes=94 or =93filterOperators=94? > 3) =93To further values are defined=94 <-- Should =93To=94 be = =93The=94 here? > 4) unindexedFilters =96 It seems like this should be a = sub-attribute of the =93filter=94 attribute in section 9. Maybe change = this to be a bit more specific (eg =96 =93allowUnindexedFilters=94). > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Monday, October 28, 2013 5:53 PM > To: scim@ietf.org WG > Subject: [scim] Proposal for attribute indexing > =20 > Please indicate your approval or comments with the following proposal = for Ticket 47 (http://trac.tools.ietf.org/wg/scim/trac/ticket/47 ) > =20 > It is proposed that the following attribute is to be added to section = 11 of the scim-core-schema draft to aid discovery of available searches = for attributes: >=20 > indexed - One or more keyword values indicating the type of filters = that MAY be used=20 > with the attribute. Valid values are the filter operators defined in = section 3.2.2.2.=20 > For example, "eq" indicates the attribute and operator value must be = identical for=20 > a match. To further values are defined: > * any - any filter may be used. > * none - no filter operator may be used with this attribute. > In section 9 of scim-core-schema, the service provider schema will = have a new attribute as follows: >=20 > unindexedFilters - A Boolean value indicating whether searches filters = using unindexed=20 > attributes are supported. > Additionally the following text is included in section 3.2.2.2 of the = scim-api draft: >=20 > For any filter for which there is no index available and unindexed = searching=20 > is not available, the server SHALL evaluate the the filter term as not = matched. > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_D0B7F738-C869-4D59-95CA-5664E1CE45F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1 =  these seem like reasonable comments.

I am = neutral on the array vs. comma separated list.  What's typical for = what we have so far? 


On 2013-10-30, at 1:41 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

So =85 would the value = of the =93indexed=94 attribute be an array of strings, or would it be a = comma-separated string that contains the available indexes?  For = example:
 
  =93indexed=94: [ =93eq=94, =93sw=94 = ]
 
Or:
 
  =93indexed=94: = =93eq, sw=94
 
 
A few other = comments:
1) The examples in sections 12.5 and 12.7 should be = updated to include these new attributes.
2) The name =93indexed=94 throws me off a little bit =85 = it sounds more like a true/false boolean property.  Maybe change = this to =93indexes=94 or =93filterOperators=94?
3)  =93To further values are defined=94 <-- = Should =93To=94 be =93The=94 here?
4) unindexedFilters =96 It seems like this should be a = sub-attribute of the =93filter=94 attribute in section 9.  Maybe = change this to be a bit more specific (eg =96 = =93allowUnindexedFilters=94).
 
 
 scim-bounces@ietf.org = [mailto:scim-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Monday, October 28, 2013 = 5:53 PM
To: scim@ietf.org = WG
Subject: [scim] Proposal for = attribute indexing
 

It is proposed that the following = attribute is to be added to section 11 of the scim-core-schema draft to = aid discovery of available searches for = attributes:

indexed - One or more keyword values =
indicating the type of filters that MAY be used =

with the attribute. Valid values are the filter operators =
defined in section 3.2.2.2. 
For example, "eq" indicates the attribute =
and operator value must be identical for 
a match. To =
further values are defined:
* any - any filter may be =
used.
* =
none - no filter operator may be used with this =
attribute.

In section 9 of scim-core-schema, the service provider = schema will have a new attribute as follows:

unindexedFilters - A Boolean value indicating whether =
searches filters using unindexed 
attributes are =
supported.

Additionally the following text is included in section = 3.2.2.2 of the scim-api draft:

For any =
filter for which there is no index available and unindexed searching =

is=
 not available, the server SHALL evaluate the the filter term as not =
matched.
Phil
 
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_D0B7F738-C869-4D59-95CA-5664E1CE45F2-- From kelly.grizzle@sailpoint.com Thu Oct 31 07:07:33 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6609021F8411 for ; Thu, 31 Oct 2013 07:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP0GxNp8+7OC for ; Thu, 31 Oct 2013 07:07:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 476D011E8226 for ; Thu, 31 Oct 2013 07:07:15 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 31 Oct 2013 14:07:14 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.183]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.183]) with mapi id 15.00.0815.000; Thu, 31 Oct 2013 14:07:13 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Proposal for attribute indexing Thread-Index: AQHO1DB8wg/y1w3iE0ehgc+8WYzNaJoNspSggAAew4CAAQsNIA== Date: Thu, 31 Oct 2013 14:07:13 +0000 Message-ID: References: <129C80FE-ABC2-43AF-849D-F9AFEB29AC67@oracle.com> <7ea7b708e82d4ce9b32ca9408091cae3@CO1PR04MB393.namprd04.prod.outlook.com> <6CA71EE2-F825-4F5D-8967-1140C7C20AE3@oracle.com> In-Reply-To: <6CA71EE2-F825-4F5D-8967-1140C7C20AE3@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 00338085005956003381D2 x-originating-ip: [173.226.147.242] x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377424004)(377454003)(24454002)(81542001)(19580395003)(83322001)(19580405001)(85306002)(80976001)(33646001)(81342001)(81816001)(50986001)(49866001)(47976001)(81686001)(4396001)(76482001)(69226001)(76576001)(54316002)(76796001)(76786001)(77096001)(56776001)(56816003)(16236675002)(83072001)(16601075003)(74876001)(51856001)(74706001)(87266001)(19609705001)(19300405004)(15975445006)(77982001)(46102001)(59766001)(31966008)(47736001)(53806001)(79102001)(74366001)(74502001)(561944002)(63696002)(80022001)(65816001)(66066001)(47446002)(54356001)(15202345003)(74662001)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; CLIP:173.226.147.242; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f08c51d17a5f45dc94b1ad17b41484a5BN1PR04MB392namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org WG" Subject: Re: [scim] Proposal for attribute indexing X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:07:33 -0000 --_000_f08c51d17a5f45dc94b1ad17b41484a5BN1PR04MB392namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that arrays are more common. This would be a little weird if usi= ng the "none" or "all" keywords, but seems like the right way to go still. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, October 30, 2013 5:11 PM To: Kelly Grizzle Cc: scim@ietf.org WG Subject: Re: [scim] Proposal for attribute indexing +1 these seem like reasonable comments. I am neutral on the array vs. comma separated list. What's typical for wha= t we have so far? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-30, at 1:41 PM, Kelly Grizzle > wrote: So ... would the value of the "indexed" attribute be an array of strings, o= r would it be a comma-separated string that contains the available indexes?= For example: "indexed": [ "eq", "sw" ] Or: "indexed": "eq, sw" A few other comments: 1) The examples in sections 12.5 and 12.7 should be updated to include= these new attributes. 2) The name "indexed" throws me off a little bit ... it sounds more li= ke a true/false boolean property. Maybe change this to "indexes" or "filte= rOperators"? 3) "To further values are defined" <-- Should "To" be "The" here? 4) unindexedFilters - It seems like this should be a sub-attribute of = the "filter" attribute in section 9. Maybe change this to be a bit more sp= ecific (eg - "allowUnindexedFilters"). --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Phil Hunt Sent: Monday, October 28, 2013 5:53 PM To: scim@ietf.org WG Subject: [scim] Proposal for attribute indexing Please indicate your approval or comments with the following proposal for T= icket 47 (http://trac.tools.ietf.org/wg/scim/trac/ticket/47 ) It is proposed that the following attribute is to be added to section 11 of= the scim-core-schema draft to aid discovery of available searches for attr= ibutes: indexed - One or more keyword values indicating the type of filters that MA= Y be used with the attribute. Valid values are the filter operators defined in sectio= n 3.2.2.2. For example, "eq" indicates the attribute and operator value must be identi= cal for a match. To further values are defined: * any - any filter may be used. * none - no filter operator may be used with this attribute. In section 9 of scim-core-schema, the service provider schema will have a n= ew attribute as follows: unindexedFilters - A Boolean value indicating whether searches filters usin= g unindexed attributes are supported. Additionally the following text is included in section 3.2.2.2 of the scim-= api draft: For any filter for which there is no index available and unindexed searchin= g is not available, the server SHALL evaluate the the filter term as not matc= hed. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_f08c51d17a5f45dc94b1ad17b41484a5BN1PR04MB392namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that arrays are= more common.  This would be a little weird if using the “none&#= 8221; or “all” keywords, but seems like the right way to go sti= ll.

 

 <= /p>

From: Phil Hun= t [mailto:phil.hunt@oracle.com]
Sent: Wednesday, October 30, 2013 5:11 PM
To: Kelly Grizzle
Cc: scim@ietf.org WG
Subject: Re: [scim] Proposal for attribute indexing

 

+1  these seem like reasonable comments.

 

I am neutral on the array vs. comma separated list. =  What's typical for what we have so far? 

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

On 2013-10-30, at 1:41 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com>= wrote:



So … would the valu= e of the “indexed” attribute be an array of strings, or would i= t be a comma-separated string that contains the available indexes?  Fo= r example:

 <= /p>

  “indexedR= 21;: [ “eq”, “sw” ]

 <= /p>

Or:

 <= /p>

  “indexedR= 21;: “eq, sw”

 <= /p>

 <= /p>

A few other comments:

1)  &nbs= p;   The examples in sections 12.5 and 12.7 should be updated to include these new = attributes.

2)  &nbs= p;   The name “indexed” throws me off a little bit … it sounds mo= re like a true/false boolean property.  Maybe change this to “in= dexes” or “filterOperators”?

3)  &nbs= p;    “To further values are defined” <-- Should “To” be “= ;The” here?

4)  &nbs= p;   unindexedFilters – It seems like this should be a sub-attribute of the “filter&= #8221; attribute in section 9.  Maybe change this to be a bit more spe= cific (eg – “allowUnindexedFilters”).

 <= /p>

--Kelly=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, Octo= ber 28, 2013 5:53 PM
To: scim@ietf.org WG
Subject: [scim] Pr= oposal for attribute indexing

 

Please indicate your approval or comments with the f= ollowing proposal for Ticket 47 (http://trac.tools.ietf.org= /wg/scim/trac/ticket/47 )

 

It is proposed that the following attribute is to be added= to section 11 of the scim-core-schema draft to aid discovery of available = searches for attributes:

indexed - One or more keyword values indi=
cating the type of filters that MAY be used 
with the attribute. Valid values are the filte=
r operators defined in section 3.2.2.2. 
For example, "eq" indicates the attr=
ibute and operator value must be identical for 
a match. To further values are defined:
* any - any filter may be used.

* none - no filter operator may be used with t=
his attribute.

In section 9 of scim-core-schema, the service provider sch= ema will have a new attribute as follows:

unindexedFilters - A Boolean value indica=
ting whether searches filters using unindexed 
attributes are supported.

Additionally the following text is included in section 3.2= .2.2 of the scim-api draft:

For any filter for which there is no inde=
x available and unindexed searching 
is not available, the server SHALL evaluate th=
e the filter term as not matched.

Phil

 

@independentid

 

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

 

--_000_f08c51d17a5f45dc94b1ad17b41484a5BN1PR04MB392namprd04pro_--