From edreux@cloudiway.com Sat Sep 1 14:11:53 2012 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 1038E11E80FB for ; Sat, 1 Sep 2012 14:11:53 -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=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTxnbi8VsL+U for ; Sat, 1 Sep 2012 14:11:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id B95B811E80F1 for ; Sat, 1 Sep 2012 14:11:48 -0700 (PDT) Received: from mail97-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Sat, 1 Sep 2012 21:11:44 +0000 Received: from mail97-ch1 (localhost [127.0.0.1]) by mail97-ch1-R.bigfish.com (Postfix) with ESMTP id 485862E00EB; Sat, 1 Sep 2012 21:11:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -71 X-BigFish: PS-71(zzc89bh148cI15caKJzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail97-ch1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail97-ch1 (localhost.localdomain [127.0.0.1]) by mail97-ch1 (MessageSwitch) id 1346533902482134_31819; Sat, 1 Sep 2012 21:11:42 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail97-ch1.bigfish.com (Postfix) with ESMTP id 7308246022B; Sat, 1 Sep 2012 21:11:42 +0000 (UTC) Received: from AMXPRD0610HT004.eurprd06.prod.outlook.com (157.56.248.213) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 1 Sep 2012 21:11:42 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.58]) by AMXPRD0610HT004.eurprd06.prod.outlook.com ([10.255.58.39]) with mapi id 14.16.0190.008; Sat, 1 Sep 2012 21:11:40 +0000 From: Emmanuel Dreux To: Dale Olds , "scim@ietf.org" Thread-Topic: 11RE: [scim] userids, usernames, and group names Thread-Index: AQHNiHQempqPN2ol5kOUfaD2Z62Qrpd180sQ Date: Sat, 1 Sep 2012 21:11:39 +0000 Message-ID: References: <504133BE.4020704@rbcon.com> In-Reply-To: <504133BE.4020704@rbcon.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.84.144.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: [scim] 11RE: userids, usernames, and group names 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, 01 Sep 2012 21:11:53 -0000 Hi Dale, You have raised 2 very good points. Point 1: We are (potentially) facing the same problem. We have a customer who is using our product to synchronize their Active Dir= ectory with Google Apps. When we've put our solution in place, we've discovered that he had 400 grou= ps where the email address in Google was different from the group's SamAcco= unName in Active Directory. Example: Active Directory GroupName (=3DsamAccountName) : MarkettingApp01 Google email: MarkettingApplication01@domain.com We addressed the issue by creating a mapping table:Source=3D" MarkettingApp= 01" target=3D"MarkettingApplication01@domain.com" If we were synchronizing with SCIM, we would need the following schema: displayName: MarkettingApp01 GroupId : MarkettingApplication01@domain.com I re-read the spec after reading your mail and indeed an equivalent of the = groupID attribute does not exist yet in the spec. Point 2: We are facing the same issue too but we suggested to handle it dif= ferently with a mapping mechanisms between the source identifier and target= identifier (that would be part of the IAM implementation but not the SCIM = protocol). Example: Source :Active Directory: Group : Grp01 Members: CN=3Duser1,OU=3Dmy,dc=3Dmycompany,dc=3Dcom CN=3Duser2,OU=3Dmy,dc=3Dmycompany,dc=3Dcom Target: SAAS provider Group : Grp01 Members: UserID1 UserID2 How do we address it: In our product, we maintain a mapping table between the source user and tar= get user: CN=3Duser1,OU=3Dmy,dc=3Dmycompany,dc=3Dcom =3D UserID1 CN=3Duser2,OU=3Dmy,dc=3Dmycompany,dc=3Dcom =3D UserID2 So, when we send the group membership, we send UserID1 and UserID2 (that ar= e understandable by the target). How would you imagine to handle this scenario differently? -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Dale Olds [mailto:olds@rbcon.com]=20 Envoy=E9=A0: vendredi 31 ao=FBt 2012 23:59 =C0=A0: scim@ietf.org Objet=A0: [scim] userids, usernames, and group names In our scim implementation we assign the following meanings to these user a= ttributes: * id: unique, immutable, required, not intended to be typed by humans.=20 The only identifier safe to store in external systems. * userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user. * displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed. Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing use= rName to be mutable in 1.1. We are now implementing groups. IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users. I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName? A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this: User: { id: 111111 userName: 'joe' groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] = } Group: { id: 22222 groupName: 'guides' members: [{display: 'Joey', name: 'joe', value: 11111}] } I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well. --Dale From hasini@wso2.com Sun Sep 2 02:40:07 2012 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 0982B21F89A5 for ; Sun, 2 Sep 2012 02:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x49E-CBunr+u for ; Sun, 2 Sep 2012 02:40:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68221F89A4 for ; Sun, 2 Sep 2012 02:40:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5187431vbb.31 for ; Sun, 02 Sep 2012 02:40:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=+oFxn/Iy52lFkFHAfeKfEUrgx02OB/FnCqezHnMrhSw=; b=QmSsqreIw6wPsutDqcdenbjDJ6tYrryUVm1evCTwDP7UCbV32yImqX5vXWRxoPCAgi 7lnhbvCrkLCxolROL/B6a3hJQwNphh8kHt3O97cHyorcpXnjhsRh/2QqdwZ6q9X5M0Da +8ys1zSSDlLatW7FntZcWqWO5Evap2kcJeoFzrEpDKQt6xrRjtSykX57Ggt3r7KOaRDl e81e2D5PVfgNba+REG7QYoNf8vpUresAw1e2wqHQXljyTcGt0wacZbknX1dmWcKCQ9/S kj/RzpUVv3DGKWqlJIrnNU/BMLvZPvw+Dq9obJocHXHCsNwE80/soEIatMa01Yezz27z JcvA== MIME-Version: 1.0 Received: by 10.52.94.148 with SMTP id dc20mr7710939vdb.12.1346578805260; Sun, 02 Sep 2012 02:40:05 -0700 (PDT) Received: by 10.58.132.179 with HTTP; Sun, 2 Sep 2012 02:40:05 -0700 (PDT) Date: Sun, 2 Sep 2012 15:10:05 +0530 Message-ID: From: Hasini Gunasinghe To: scim@ietf.org Content-Type: multipart/alternative; boundary=bcaec5015f2b59831d04c8b4cfc4 X-Gm-Message-State: ALoCoQlcZY5NOQrfqbuasjhDgaHKBJ51UAKbKp/0kyfpM29vBKy/sbwgmlntdpf4gQlss9ZlpZi1 Subject: [scim] Proposing permissions/entitlements attribute to group 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, 02 Sep 2012 09:40:07 -0000 --bcaec5015f2b59831d04c8b4cfc4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, In the identity management systems that support Role Based Access Control, groups/roles are assigned a set of permissions/entitlements which are required to be synchronized across domains along with the corresponding groups. Having an optional, multi-valued attribute as permissions/entitlements in the group schema is useful to facilitate such requirements. Appreciate thoughts on this. Thanks, Hasini. --bcaec5015f2b59831d04c8b4cfc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

In the identity management systems that support = Role Based Access Control, groups/roles are assigned a set of permissions/e= ntitlements which are required to be synchronized=A0across=A0domains along = with the corresponding groups.
Having an optional, multi-valued attribute as permissions/entitlements= in the group schema is useful to facilitate such requirements.
<= br>
Appreciate thoughts on this.

Thanks,=
Hasini.
--bcaec5015f2b59831d04c8b4cfc4-- From hasini@wso2.com Mon Sep 3 02:16:01 2012 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 07D0E21F84FC for ; Mon, 3 Sep 2012 02:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtikOE54T-XD for ; Mon, 3 Sep 2012 02:16:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 075B821F8455 for ; Mon, 3 Sep 2012 02:15:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5960149vbb.31 for ; Mon, 03 Sep 2012 02:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ViBwToMiVR3BepVr9Pj2+UgWSEzYFnRWIBNDIxMPVzE=; b=bdlA0X66gdGToYswCmou/SN26la43FNBp2mOncAmFApPaOGtwyrqQwflqLlyy0JwCE onP5x4fF7TMjlVetrZSIEvOd/G53Qy6jbOqlioKF7ZjrhKttT9LCTQepTfbK4A/3lU3G hhrD/wzhKqQo86zQUi5CyI+1mzgKMa8Ixjjb0WwUjoqV2PvOoqkFo8NWNviFkU3Deteo 64oDPIJcrjx29GzorbtiPUv32cSce2IPwxmffY3aVzhoaAaqYh/WEY9DywM7lfNdpHs+ agZMksKRuThNq5fyy2ctNdaAstUICRvEhvPUP0huyEWmL52VJy+Z0zQKbmqAlhOJUUoM Qv7A== MIME-Version: 1.0 Received: by 10.52.75.36 with SMTP id z4mr9297907vdv.52.1346663759073; Mon, 03 Sep 2012 02:15:59 -0700 (PDT) Received: by 10.58.132.179 with HTTP; Mon, 3 Sep 2012 02:15:59 -0700 (PDT) In-Reply-To: <504133BE.4020704@rbcon.com> References: <504133BE.4020704@rbcon.com> Date: Mon, 3 Sep 2012 14:45:59 +0530 Message-ID: From: Hasini Gunasinghe To: Dale Olds Content-Type: multipart/alternative; boundary=bcaec5016057fdd19f04c8c896c7 X-Gm-Message-State: ALoCoQnb3JMPXfCQh91MswHe4p2CJcbj3TgZhA6spoE/VzIsFMvYRP0tFLCG+Aj2oOtBJshiUx0q Cc: "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 03 Sep 2012 09:16:01 -0000 --bcaec5016057fdd19f04c8c896c7 Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds wrote: > In our scim implementation we assign the following meanings to these user > attributes: > > * id: unique, immutable, required, not intended to be typed by humans. The > only identifier safe to store in external systems. > > * userName: unique, mutable, required, though rarely changed in practice, > not localized -- more like a keyword. It's what humans can use when they > need to type in a reference to a user. > > * displayName: not unique, mutable, optional, used as input to some > display context but might not be literally displayed. > > Access control for the id and userName fields is identical -- they are > both essentially treated as identifiers, displayName is different. These > meanings work for us. All 3 attributes are used for specific purposes, and > I believe our use does not violate the current spec. BTW, thanks for > changing userName to be mutable in 1.1. > > We are now implementing groups. > > IIRC, the only choice the spec gives for human readable group names is > displayName, but we have tools (e.g. CLIs) that need to accept a reference > to a group typed in by a user. We could use displayName for that purpose, > but then we lose the displayName capability that we have for users. > I do not see a reason why you can not use displayName of groups here. IIUC, displayName for user and group are two separate attributes and you can use them independently. > > I've checked for this issue in the list archives but did not see any > discussion. Has the group discussed a naming attribute for groups that > would be more like userName than displayName? > Another option would be externalId - which is defined in the common schema. Thanks, Hasini. > > A related issue is compound attributes such as Users.groups and > Groups.members. If Groups had groupName attribute similar to userName for > users, it would be most useful if these attributes could have > sub-attributes like this: > > User: > { > id: 111111 > userName: 'joe' > groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] > } > > Group: > { > id: 22222 > groupName: 'guides' > members: [{display: 'Joey', name: 'joe', value: 11111}] > } > > I suppose we could add this capability as an extension, but would like to > see if others would find this useful as well. > > --Dale > > ______________________________**_________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/**listinfo/scim > --bcaec5016057fdd19f04c8c896c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dale,

On Sat, Sep 1, 2012 at 3:29 AM, = Dale Olds <olds@rbcon.com> wrote:
In our scim implementation we assign the following meanings to these user a= ttributes:

* id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they= need to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing use= rName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users.
I do not see a reason why you can not use displayName of = groups here. IIUC, displayName for user and group are two separate attribut= es and you can use them independently.=A0

I've checked for this issue in the list archives but did not see any di= scussion. Has the group discussed a naming attribute for groups that would = be more like userName than displayName?
Another option= would be externalId - which is defined in the common schema.

Thanks,
Hasini.=A0

A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this:=

User:
{
=A0 id: 111111
=A0 userName: 'joe'
=A0 groups: [{display: 'Hiking Tour Guides', name: 'guides'= , value: 22222}]
}

Group:
{
=A0 id: 22222
=A0 groupName: 'guides'
=A0 members: [{display: 'Joey', name: 'joe', value: 11111}]=
}

I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well.

--Dale

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

--bcaec5016057fdd19f04c8c896c7-- From edreux@cloudiway.com Mon Sep 3 13:08:19 2012 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 ECD4621F8554 for ; Mon, 3 Sep 2012 13:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9gTFVkimiTC for ; Mon, 3 Sep 2012 13:08:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 83D6C21F8551 for ; Mon, 3 Sep 2012 13:08:17 -0700 (PDT) Received: from mail12-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Sep 2012 20:08:16 +0000 Received: from mail12-co1 (localhost [127.0.0.1]) by mail12-co1-R.bigfish.com (Postfix) with ESMTP id 76E9D400E6; Mon, 3 Sep 2012 20:08:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT001.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371Ic89bh148cIc85dh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail12-co1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT001.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail12-co1 (localhost.localdomain [127.0.0.1]) by mail12-co1 (MessageSwitch) id 1346702893948962_29266; Mon, 3 Sep 2012 20:08:13 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.234]) by mail12-co1.bigfish.com (Postfix) with ESMTP id E58DF800DA; Mon, 3 Sep 2012 20:08:13 +0000 (UTC) Received: from AMXPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.213) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Sep 2012 20:08:13 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.58]) by AMXPRD0610HT001.eurprd06.prod.outlook.com ([10.255.58.36]) with mapi id 14.16.0190.008; Mon, 3 Sep 2012 20:08:12 +0000 From: Emmanuel Dreux To: Hasini Gunasinghe , Dale Olds Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2b5q6U7SDb0+XIqsJt3b0l5d5CTrQ Date: Mon, 3 Sep 2012 20:08:05 +0000 Message-ID: References: <504133BE.4020704@rbcon.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.41.102.231] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B52FAMXPRD0610MB353_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 03 Sep 2012 20:08:20 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B52FAMXPRD0610MB353_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding of Dale issue is the following: I have a group in Google ( let's talk about Google if Active Directory does= not ring bells): DisplayName: Developpers Group email address (=3D Id) : devs@company.com How do you represent it in SCIM? According to the spec here ( http://tools.ietf.org/html/draft-ietf-scim-cor= e-schema-00#section-11.4), a "groupID" (or call it GroupUsername) is missin= g. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Hasini Gunasinghe [mailto:hasini@wso2.com] Envoy=E9 : lundi 3 septembre 2012 11:16 =C0 : Dale Olds Cc : scim@ietf.org Objet : Re: [scim] userids, usernames, and group names Hi Dale, On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds > wrote: In our scim implementation we assign the following meanings to these user a= ttributes: * id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems. * userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user. * displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed. Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing use= rName to be mutable in 1.1. We are now implementing groups. IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users. I do not see a reason why you can not use displayName of groups here. IIUC,= displayName for user and group are two separate attributes and you can use= them independently. I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName? Another option would be externalId - which is defined in the common schema. Thanks, Hasini. A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this: User: { id: 111111 userName: 'joe' groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] } Group: { id: 22222 groupName: 'guides' members: [{display: 'Joey', name: 'joe', value: 11111}] } I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well. --Dale _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B52FAMXPRD0610MB353_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My underst= anding of Dale issue is the following:

 = ;

I have a g= roup in Google ( let’s talk about Google if Active Directory does not= ring bells):

DisplayNam= e: Developpers

Group emai= l address (=3D Id) : devs@company.com<= /p>

 = ;

How do you= represent it in SCIM?

According = to the spec here ( http://tools.ietf.org/html/draft-ietf-s= cim-core-schema-00#section-11.4), a “groupID” (or call it GroupUsername) is missing.

 = ;

--

Regards,

Emmanuel Dreux=

http://www.cloudiway.com<= o:p>

Tel: +33 4 26 78 17 5= 8

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 <= /p>

De : Hasi= ni Gunasinghe [mailto:hasini@wso2.com]
Envoy=E9 : lundi 3 septembre 2012 11:16
=C0 : Dale Olds
Cc : scim@ietf.org
Objet : Re: [scim] userids, usernames, and group names

 

Hi Dale,

On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds <olds@rbcon.com> wrote:=

In our scim implementation we assign the following m= eanings to these user attributes:

* id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing userName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users.

I do not see a reason why you can not use displayNam= e of groups here. IIUC, displayName for user and group are two separate att= ributes and you can use them independently. 


I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName?

Another option would be externalId - which is define= d in the common schema.

 

Thanks,

Hasini. 


A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this:=

User:
{
  id: 111111
  userName: 'joe'
  groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 2222= 2}]
}

Group:
{
  id: 22222
  groupName: 'guides'
  members: [{display: 'Joey', name: 'joe', value: 11111}]
}

I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well.

--Dale

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

 

--_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B52FAMXPRD0610MB353_-- From edreux@cloudiway.com Mon Sep 3 13:12:44 2012 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 207B521F84CD for ; Mon, 3 Sep 2012 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpOpkNJOCHNy for ; Mon, 3 Sep 2012 13:12:41 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3921F8551 for ; Mon, 3 Sep 2012 13:12:40 -0700 (PDT) Received: from mail47-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Sep 2012 20:12:39 +0000 Received: from mail47-am1 (localhost [127.0.0.1]) by mail47-am1-R.bigfish.com (Postfix) with ESMTP id 1124644014B; Mon, 3 Sep 2012 20:12:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371Ic89bh148cIc85dh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail47-am1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail47-am1 (localhost.localdomain [127.0.0.1]) by mail47-am1 (MessageSwitch) id 1346703156919872_22053; Mon, 3 Sep 2012 20:12:36 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.226]) by mail47-am1.bigfish.com (Postfix) with ESMTP id D472320047; Mon, 3 Sep 2012 20:12:36 +0000 (UTC) Received: from AMXPRD0610HT004.eurprd06.prod.outlook.com (157.56.248.213) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Sep 2012 20:12:36 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.58]) by AMXPRD0610HT004.eurprd06.prod.outlook.com ([10.255.58.39]) with mapi id 14.16.0190.008; Mon, 3 Sep 2012 20:12:35 +0000 From: Emmanuel Dreux To: Emmanuel Dreux , Hasini Gunasinghe , Dale Olds Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2b5q6U7SDb0+XIqsJt3b0l5d5CTrQgAADWoA= Date: Mon, 3 Sep 2012 20:12:34 +0000 Message-ID: References: <504133BE.4020704@rbcon.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.41.102.231] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B53EAMXPRD0610MB353_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 03 Sep 2012 20:12:44 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B53EAMXPRD0610MB353_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And less problematic, Group Description is missing as well. That's a field that usually our customers are asking to synchronize. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Emmanuel Dreux Envoy=E9 : lundi 3 septembre 2012 22:08 =C0 : 'Hasini Gunasinghe'; Dale Olds Cc : scim@ietf.org Objet : RE: [scim] userids, usernames, and group names My understanding of Dale issue is the following: I have a group in Google ( let's talk about Google if Active Directory does= not ring bells): DisplayName: Developpers Group email address (=3D Id) : devs@company.com How do you represent it in SCIM? According to the spec here ( http://tools.ietf.org/html/draft-ietf-scim-cor= e-schema-00#section-11.4), a "groupID" (or call it GroupUsername) is missin= g. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Hasini Gunasinghe [mailto:hasini@wso2.com] Envoy=E9 : lundi 3 septembre 2012 11:16 =C0 : Dale Olds Cc : scim@ietf.org Objet : Re: [scim] userids, usernames, and group names Hi Dale, On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds > wrote: In our scim implementation we assign the following meanings to these user a= ttributes: * id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems. * userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user. * displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed. Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing use= rName to be mutable in 1.1. We are now implementing groups. IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users. I do not see a reason why you can not use displayName of groups here. IIUC,= displayName for user and group are two separate attributes and you can use= them independently. I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName? Another option would be externalId - which is defined in the common schema. Thanks, Hasini. A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this: User: { id: 111111 userName: 'joe' groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] } Group: { id: 22222 groupName: 'guides' members: [{display: 'Joey', name: 'joe', value: 11111}] } I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well. --Dale _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B53EAMXPRD0610MB353_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

And less p= roblematic, Group Description is missing as well.

That’= ;s a field that usually our customers are asking to synchronize.=

 = ;

--

Regards,

Emmanuel Dreux=

http://www.cloudiway.com<= o:p>

Tel: +33 4 26 78 17 5= 8

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 <= /p>

De : Emma= nuel Dreux
Envoy=E9 : lundi 3 septembre 2012 22:08
=C0 : 'Hasini Gunasinghe'; Dale Olds
Cc : scim@ietf.org
Objet : RE: [scim] userids, usernames, and group names

 

My underst= anding of Dale issue is the following:

 = ;

I have a g= roup in Google ( let’s talk about Google if Active Directory does not= ring bells):

DisplayNam= e: Developpers

Group emai= l address (=3D Id) : devs@company.com<= /p>

 = ;

How do you= represent it in SCIM?

According = to the spec here ( http://tools.ietf.org/html/draft-ietf-s= cim-core-schema-00#section-11.4), a “groupID” (or call it GroupUsername) is missing.

 = ;

--

Regards,

Emmanuel Dreux=

http://www.cloudiway.com

Tel: +33 4 26 78 17 5= 8

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 <= /p>

De : Hasi= ni Gunasinghe [mailto:hasini@wso2.com]
Envoy=E9 : lundi 3 septembre 2012 11:16
=C0 : Dale Olds
Cc : scim@ietf.org
Objet : Re: [scim] userids, usernames, and group names

 

Hi Dale,

On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds <olds@rbcon.com> wrote:=

In our scim implementation we assign the following m= eanings to these user attributes:

* id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing userName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users.

I do not see a reason why you can not use displayNam= e of groups here. IIUC, displayName for user and group are two separate att= ributes and you can use them independently. 


I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName?

Another option would be externalId - which is define= d in the common schema.

 

Thanks,

Hasini. 


A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this:=

User:
{
  id: 111111
  userName: 'joe'
  groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 2222= 2}]
}

Group:
{
  id: 22222
  groupName: 'guides'
  members: [{display: 'Joey', name: 'joe', value: 11111}]
}

I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well.

--Dale

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

 

--_000_DF63ACC82673DB40A7AAC08FFA71DFBD2741B53EAMXPRD0610MB353_-- From kelly.grizzle@sailpoint.com Tue Sep 4 09:16:58 2012 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 6689D21E8042 for ; Tue, 4 Sep 2012 09:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MMVvDRZR0o5 for ; Tue, 4 Sep 2012 09:16:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2351C21E8041 for ; Tue, 4 Sep 2012 09:16:51 -0700 (PDT) Received: from mail165-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 16:16:51 +0000 Received: from mail165-ch1 (localhost [127.0.0.1]) by mail165-ch1-R.bigfish.com (Postfix) with ESMTP id 295CF2A00A8; Tue, 4 Sep 2012 16:16:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371Ic89bh148cIc85dh1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail165-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail165-ch1 (localhost.localdomain [127.0.0.1]) by mail165-ch1 (MessageSwitch) id 1346775409906059_23427; Tue, 4 Sep 2012 16:16:49 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail165-ch1.bigfish.com (Postfix) with ESMTP id DB86B340044; Tue, 4 Sep 2012 16:16:49 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 16:16:48 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.140]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 16:16:48 +0000 From: Kelly Grizzle To: Emmanuel Dreux , Hasini Gunasinghe , Dale Olds Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2FJzTx0x2CUeh0OVx1e4T+Jd5CTrQgAADWoCAAU6Z0A== Date: Tue, 4 Sep 2012 16:16:47 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <504133BE.4020704@rbcon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330E7B64BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 16:16:58 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330E7B64BY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think description and groupName attributes make sense. Using externalId = for names may make more sense groups than for users, but my preference woul= d be to use groupName to keep the resources similar. > A related issue is compound attributes such as Users.groups and Groups.me= mbers. If Groups > had groupName attribute similar to userName for users, it would be most u= seful if these attributes > could have sub-attributes... You can always fetch the group to get the additional data, but this would i= ncur some cost. I agree that only including the displayName is a bit arbit= rary, though. IMO we should take a look at this more generally for all rel= ationships. For instance, this also applies to the "manager" attribute in = the enterprise user extension. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emm= anuel Dreux Sent: Monday, September 03, 2012 3:13 PM To: Emmanuel Dreux; Hasini Gunasinghe; Dale Olds Cc: scim@ietf.org Subject: Re: [scim] userids, usernames, and group names And less problematic, Group Description is missing as well. That's a field that usually our customers are asking to synchronize. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Emmanuel Dreux Envoy=E9 : lundi 3 septembre 2012 22:08 =C0 : 'Hasini Gunasinghe'; Dale Olds Cc : scim@ietf.org Objet : RE: [scim] userids, usernames, and group names My understanding of Dale issue is the following: I have a group in Google ( let's talk about Google if Active Directory does= not ring bells): DisplayName: Developpers Group email address (=3D Id) : devs@company.com How do you represent it in SCIM? According to the spec here ( http://tools.ietf.org/html/draft-ietf-scim-cor= e-schema-00#section-11.4), a "groupID" (or call it GroupUsername) is missin= g. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Hasini Gunasinghe [mailto:hasini@wso2.com] Envoy=E9 : lundi 3 septembre 2012 11:16 =C0 : Dale Olds Cc : scim@ietf.org Objet : Re: [scim] userids, usernames, and group names Hi Dale, On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds > wrote: In our scim implementation we assign the following meanings to these user a= ttributes: * id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems. * userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user. * displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed. Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing use= rName to be mutable in 1.1. We are now implementing groups. IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users. I do not see a reason why you can not use displayName of groups here. IIUC,= displayName for user and group are two separate attributes and you can use= them independently. I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName? Another option would be externalId - which is defined in the common schema. Thanks, Hasini. A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this: User: { id: 111111 userName: 'joe' groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] } Group: { id: 22222 groupName: 'guides' members: [{display: 'Joey', name: 'joe', value: 11111}] } I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well. --Dale _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_56C3C758F9D6534CA3778EAA1E0C3437330E7B64BY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think description and g= roupName attributes make sense.  Using externalId for names may make m= ore sense groups than for users, but my preference would be to use groupName to keep the resources similar.

 <= /p>

 <= /p>

> A related issue is compound attributes such as Use= rs.groups and Groups.members. If Groups

> had groupName attribute simil= ar to userName for users, it would be most useful if these attributes<= /o:p>

> could have sub-attributes...<= /span>

 <= /p>

You can always fetch the = group to get the additional data, but this would incur some cost.  I a= gree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all rel= ationships.  For instance, this also applies to the “managerR= 21; attribute in the enterprise user extension.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Monday, September 03, 2012 3:13 PM
To: Emmanuel Dreux; Hasini Gunasinghe; Dale Olds
Cc: scim@ietf.org
Subject: Re: [scim] userids, usernames, and group names

 

And less problematic, Gro= up Description is missing as well.

That’s a field that= usually our customers are asking to synchronize.<= o:p>

 

--

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 = 4 26 78 17 58

Mobile: += 33 6 47 81 26 70

skype: Emmanu= el.Dreux

 =

De : Emmanuel Dreux
Envoy=E9 : lundi 3 septembre 2012 22:08
=C0 : 'Hasini Gunasinghe'; Dale Olds
Cc : scim@ietf.org
Objet : RE: [scim] userids, usernames, and group names

 

My understanding of Dale = issue is the following:

 

I have a group in Google = ( let’s talk about Google if Active Directory does not ring bells):

DisplayName: Developpers<= /span>

Group email address (=3D = Id) : devs@company.com

 

How do you represent it i= n SCIM?

According to the spec her= e ( http://tools.ietf.org= /html/draft-ietf-scim-core-schema-00#section-11.4), a “groupID” (or call it GroupUsername) is missing.

 

--

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 = 4 26 78 17 58

Mobile: += 33 6 47 81 26 70

skype: Emmanu= el.Dreux

 =

De : Hasini Gunasinghe [m= ailto:hasini@wso2.com]
Envoy=E9 : lundi 3 septembre 2012 11:16
=C0 : Dale Olds
Cc : scim@ietf.org
Objet : Re: [scim] userids, usernames, and group names

 

Hi = Dale,

On Sat, Sep 1, 2012 at 3:29 AM, Da= le Olds <olds@rbcon.= com> wrote:

In our scim implementation we assi= gn the following meanings to these user attributes:

* id: unique, immutable, required, not intended to be typed by humans. The = only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in practice, n= ot localized -- more like a keyword. It's what humans can use when they nee= d to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some display= context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are both= essentially treated as identifiers, displayName is different. These meanin= gs work for us. All 3 attributes are used for specific purposes, and I beli= eve our use does not violate the current spec. BTW, thanks for changing userName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is disp= layName, but we have tools (e.g. CLIs) that need to accept a reference to a= group typed in by a user. We could use displayName for that purpose, but t= hen we lose the displayName capability that we have for users.

I do not see a reason why you can = not use displayName of groups here. IIUC, displayName for user and group ar= e two separate attributes and you can use them independently. 


I've checked for this issue in the list archives but did not see any discus= sion. Has the group discussed a naming attribute for groups that would be m= ore like userName than displayName?

Another option would be externalId= - which is defined in the common schema.

 

Thanks,

Hasini. 


A related issue is compound attributes such as Users.groups and Groups.memb= ers. If Groups had groupName attribute similar to userName for users, it wo= uld be most useful if these attributes could have sub-attributes like this:=

User:
{
  id: 111111
  userName: 'joe'
  groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 2222= 2}]
}

Group:
{
  id: 22222
  groupName: 'guides'
  members: [{display: 'Joey', name: 'joe', value: 11111}]
}

I suppose we could add this capability as an extension, but would like to s= ee if others would find this useful as well.

--Dale

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

 

--_000_56C3C758F9D6534CA3778EAA1E0C3437330E7B64BY2PRD0410MB354_-- From olds@rbcon.com Tue Sep 4 10:34:29 2012 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 76C8221F8683 for ; Tue, 4 Sep 2012 10:34:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLJe9cLFQmhd for ; Tue, 4 Sep 2012 10:34:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E45CD21F8681 for ; Tue, 4 Sep 2012 10:34:27 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9493829pbb.31 for ; Tue, 04 Sep 2012 10:34:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=SWxRlCwAvYGyS5Qopg3kFtByr95WUQowOSwT9oaEWvQ=; b=TYhmmZEYaz6UWHScBTxzyW01r7xbwPhDHO4qaxBj+YmqEzq6irydPtIewgELx7wZy+ 8yJ8PD3reuceTr9XZ603qEOJcZuryDUtj/BaqsW/x4b7lzPNdCWeYZhZDy8wWF+1gURX CoA+y2LxcK0eOdnINDbbb/ynH0zal2P2JbLhi4Mj7FKMjwpBr973JlppLQB+yU3nRtU8 omlhquqsPduXwr/ph1fQao3YOIsD5ZcnLQCi11Jcbnj8iMIPioSNWyfQxCCqvuEpbB3N uGm80xaNGXFoWYGwmYvrwkybEqfkfyV5Fwz+OcBoedT9Ifgo42tyMLY3gc3C8lj5Xtql +Xeg== Received: by 10.66.77.40 with SMTP id p8mr42600219paw.78.1346780067617; Tue, 04 Sep 2012 10:34:27 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id ko8sm12615371pbc.40.2012.09.04.10.34.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:34:26 -0700 (PDT) Message-ID: <50463BA1.4090409@rbcon.com> Date: Tue, 04 Sep 2012 10:34:25 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Hasini Gunasinghe References: <504133BE.4020704@rbcon.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050701000402050204090205" X-Gm-Message-State: ALoCoQnfgz4po6DNPvQHDe42tuA1hvI7957pj2J+u4unrLvRPBBuRdHpbgKL1FVTv49yJI8kFoBE Cc: "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 17:34:29 -0000 This is a multi-part message in MIME format. --------------050701000402050204090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hasini, On 09/03/2012 02:15 AM, Hasini Gunasinghe wrote: > > IIRC, the only choice the spec gives for human readable group > names is displayName, but we have tools (e.g. CLIs) that need to > accept a reference to a group typed in by a user. We could use > displayName for that purpose, but then we lose the displayName > capability that we have for users. > > I do not see a reason why you can not use displayName of groups here. > IIUC, displayName for user and group are two separate attributes and > you can use them independently. I could have worded that better. Certainly we can (and do) use group displayName independently of user attributes. The point I was trying to make is that if we use displayName for groups (requiring it to be unique, etc) then we can't also use it like we use displayNames for users. For groups, we'd like 3 similar attributes (with the same restrictions and meaning) as we the 3 we have for users: id: immutable, unique (group | user)Name: mutable, unique displayName: mutable, non-unique > > I've checked for this issue in the list archives but did not see > any discussion. Has the group discussed a naming attribute for > groups that would be more like userName than displayName? > > Another option would be externalId - which is defined in the common > schema. > > Yes, we thought of that as well, but I'd like to reserve externalId to be used to hold a resource's id from an external system. --Dale --------------050701000402050204090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hasini,

On 09/03/2012 02:15 AM, Hasini Gunasinghe wrote:
IIRC, the only choice the spec gives for human readable group names is displayName, but we have tools (e.g. CLIs) that need to accept a reference to a group typed in by a user. We could use displayName for that purpose, but then we lose the displayName capability that we have for users.
I do not see a reason why you can not use displayName of groups here. IIUC, displayName for user and group are two separate attributes and you can use them independently.

I could have worded that better. Certainly we can (and do) use group displayName independently of user attributes.

The point I was trying to make is that if we use displayName for groups (requiring it to be unique, etc) then we can't also use it like we use displayNames for users. For groups, we'd like 3 similar attributes (with the same restrictions and meaning) as we the 3 we have for users:

id: immutable, unique
(group | user)Name: mutable, unique
displayName: mutable, non-unique


I've checked for this issue in the list archives but did not see any discussion. Has the group discussed a naming attribute for groups that would be more like userName than displayName?
Another option would be externalId - which is defined in the common schema.


Yes, we thought of that as well, but I'd like to reserve externalId to be used to hold a resource's id from an external system.

--Dale
--------------050701000402050204090205-- From olds@rbcon.com Tue Sep 4 10:49:38 2012 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 5655021F8514 for ; Tue, 4 Sep 2012 10:49: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzd6BGlunYRU for ; Tue, 4 Sep 2012 10:49:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4A21F84D3 for ; Tue, 4 Sep 2012 10:49:37 -0700 (PDT) Received: by dadf8 with SMTP id f8so4317609dad.31 for ; Tue, 04 Sep 2012 10:49:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=E8vUzinlnAmFW9yQMcT16Mlj6UTzbHgw2OISjyiiE9A=; b=WjU4rjdcF/Zys4cqOLK53oRbaC0DbwVScVy4UR/oJMEUbzgD5/0o0BgOur+e3gE3ry ixG7fCRnq5EQ7l3lc/b5zwtUIgL9y3uBYhRX2rROKdUaI93F+MSXiXzgw2+cRTTMfScR 5ITRd10kjLNkjTqXsmk+jWBZZwXf04UkBmrgB79LTkFD+20hwy3MDwp/KDzX7Ov6rCfc EyXFRu3EULIkLi/ULshHMuuY/mDMrsliw+oKLwUeyEMwJ1ZhGxa5DBqkA/LxRqKrfIWm pdbm9/Ctyd1V6Ru5/Oer5qGZAVoYh10RTxiJhXUlauxXNoy411qlgdK4goIjtVD8g7zy s/cQ== Received: by 10.68.200.162 with SMTP id jt2mr47375209pbc.54.1346780976606; Tue, 04 Sep 2012 10:49:36 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id ko8sm12638669pbc.40.2012.09.04.10.49.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:49:35 -0700 (PDT) Message-ID: <50463F2E.1090503@rbcon.com> Date: Tue, 04 Sep 2012 10:49:34 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Kelly Grizzle References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------060400010406020302040803" X-Gm-Message-State: ALoCoQlj0By5Nnt3rBQJ+QmEZIFvrTcCTefjg/rTLOfFfW1/PCXPRMWnLsgdApf5/3b2T7W7aONv Cc: Hasini Gunasinghe , "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 17:49:38 -0000 This is a multi-part message in MIME format. --------------060400010406020302040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kelly, On 09/04/2012 09:16 AM, Kelly Grizzle wrote: > > You can always fetch the group to get the additional data, but this > would incur some cost. I agree that only including the displayName is > a bit arbitrary, though. IMO we should take a look at this more > generally for all relationships. For instance, this also applies to > the "manager" attribute in the enterprise user extension. > > I agree that when we read a user's groups attribute, we could always fetch the groups to get the displayName, or whatever attribute we use as the groupName. But it's not just a performance issue to add that fetch, the access control on the group resource itself may be different than the users attribute -- in fact SCIM specifies different access control already in that the groups attribute is read-only. IMO, it's likely that access control for identifiers like id and userName may be different than access control for attributes such as postal addresses and phone numbers. It would be easier to handle the access control needs of our client applications (with better performance) if we could get these three attributes as subattributes in the User 'groups' and Group 'members' attributes: Users.groups: [{userName, id, displayName}, ...] Groups.member: [{groupName, id, displayName}, ...] --Dale --------------060400010406020302040803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:
 

You can always fetch the group to get the additional data, but this would incur some cost.  I agree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all relationships.  For instance, this also applies to the “manager” attribute in the enterprise user extension.



I agree that when we read a user's groups attribute, we could always fetch the groups to get the displayName, or whatever attribute we use as the groupName. But it's not just a performance issue to add that fetch, the access control on the group resource itself may be different than the users attribute -- in fact SCIM specifies different access control already in that the groups attribute is read-only. IMO, it's likely that access control for identifiers like id and userName may be different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applications (with better performance) if we could get these three attributes as subattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale
--------------060400010406020302040803-- From tonynad@microsoft.com Tue Sep 4 11:12:08 2012 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 DF11D21E803A for ; Tue, 4 Sep 2012 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3H4-gZO49Y6 for ; Tue, 4 Sep 2012 11:12:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id D7B0E11E809A for ; Tue, 4 Sep 2012 11:12:01 -0700 (PDT) Received: from mail182-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:12:00 +0000 Received: from mail182-tx2 (localhost [127.0.0.1]) by mail182-tx2-R.bigfish.com (Postfix) with ESMTP id D6CA44A0093 for ; Tue, 4 Sep 2012 18:12:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzbb2dI98dI9371Ic85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah1155h) Received-SPF: pass (mail182-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail182-tx2 (localhost.localdomain [127.0.0.1]) by mail182-tx2 (MessageSwitch) id 1346782318213655_16412; Tue, 4 Sep 2012 18:11:58 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.253]) by mail182-tx2.bigfish.com (Postfix) with ESMTP id 303B3220043 for ; Tue, 4 Sep 2012 18:11:58 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:11:57 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 4 Sep 2012 18:11:55 +0000 Received: from mail166-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:11:05 +0000 Received: from mail166-co1 (localhost [127.0.0.1]) by mail166-co1-R.bigfish.com (Postfix) with ESMTP id D9BC69801AD for ; Tue, 4 Sep 2012 18:11:05 +0000 (UTC) Received: from mail166-co1 (localhost.localdomain [127.0.0.1]) by mail166-co1 (MessageSwitch) id 1346782263636413_8423; Tue, 4 Sep 2012 18:11:03 +0000 (UTC) Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.227]) by mail166-co1.bigfish.com (Postfix) with ESMTP id 9758954021D; Tue, 4 Sep 2012 18:11:03 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:11:02 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.24]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 18:11:01 +0000 From: Anthony Nadalin To: Dale Olds , Kelly Grizzle Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2sorTwbEq1EKAFjSY1ZBZAZd5CTrQgAADWoCAAVC8gIAAGewAgAAFP9A= Date: Tue, 4 Sep 2012 18:11:01 +0000 Message-ID: References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> In-Reply-To: <50463F2E.1090503@rbcon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF890BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%RBCON.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%WSO2.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CLOUDIWAY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Hasini Gunasinghe , Emmanuel Dreux , "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 18:12:09 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF890BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems odd to have a rigid view, the object should be able to describe itsel= f From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dal= e Olds Sent: Tuesday, September 04, 2012 10:50 AM To: Kelly Grizzle Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names Kelly, On 09/04/2012 09:16 AM, Kelly Grizzle wrote: You can always fetch the group to get the additional data, but this would i= ncur some cost. I agree that only including the displayName is a bit arbit= rary, though. IMO we should take a look at this more generally for all rel= ationships. For instance, this also applies to the "manager" attribute in = the enterprise user extension. I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attrib= ute -- in fact SCIM specifies different access control already in that the = groups attribute is read-only. IMO, it's likely that access control for ide= ntifiers like id and userName may be different than access control for attr= ibutes such as postal addresses and phone numbers. It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes: Users.groups: [{userName, id, displayName}, ...] Groups.member: [{groupName, id, displayName}, ...] --Dale --_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF890BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems odd to have a rigid= view, the object should be able to describe itself

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:

 

You can always fetch the = group to get the additional data, but this would incur some cost.  I a= gree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all rel= ationships.  For instance, this also applies to the “managerR= 21; attribute in the enterprise user extension.

 


I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attribute -- in fact SCIM specifies differ= ent access control already in that the groups attribute is read-only. IMO, = it's likely that access control for identifiers like id and userName may be= different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF890BL2PRD0310MB362_-- From kelly.grizzle@sailpoint.com Tue Sep 4 11:42:00 2012 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 9D5CA21F8697 for ; Tue, 4 Sep 2012 11:42: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=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co6YjJmQH8bp for ; Tue, 4 Sep 2012 11:41:58 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2B121F8699 for ; Tue, 4 Sep 2012 11:41:58 -0700 (PDT) Received: from mail33-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:41:57 +0000 Received: from mail33-ch1 (localhost [127.0.0.1]) by mail33-ch1-R.bigfish.com (Postfix) with ESMTP id A5A01C00C2; Tue, 4 Sep 2012 18:41:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic85fh1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail33-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail33-ch1 (localhost.localdomain [127.0.0.1]) by mail33-ch1 (MessageSwitch) id 1346784115276586_8370; Tue, 4 Sep 2012 18:41:55 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail33-ch1.bigfish.com (Postfix) with ESMTP id 3CFF01C0049; Tue, 4 Sep 2012 18:41:55 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:41:53 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.140]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 18:41:53 +0000 From: Kelly Grizzle To: Anthony Nadalin , Dale Olds Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2FJzTx0x2CUeh0OVx1e4T+Jd5CTrQgAADWoCAAU6Z0IAAHA8AgAAF/oCAAALaEA== Date: Tue, 4 Sep 2012 18:41:53 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330E9587BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: Hasini Gunasinghe , "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 18:42:00 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330E9587BY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony, can you elaborate? Are you saying that having the spec dictate that = name, displayName, and id should be returned for references is odd? In one= sense, I agree with you. Name and displayName are a bit arbitrary, but wo= uld probably be the most commonly used. Perhaps SCIM should support expanding parts of references similar to OData = - http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. = It might make sense to allow retrieving only some of the referenced object'= s attributes rather than the full representation, though. By default (ie - without any expansion) I think that name, displayName, and= id are a good set of attributes. Alternatively, we could just return the = id and require the client to request expansion if they want name and displa= yName. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ant= hony Nadalin Sent: Tuesday, September 04, 2012 1:11 PM To: Dale Olds; Kelly Grizzle Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org Subject: Re: [scim] userids, usernames, and group names Seems odd to have a rigid view, the object should be able to describe itsel= f From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Dale Olds Sent: Tuesday, September 04, 2012 10:50 AM To: Kelly Grizzle Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names Kelly, On 09/04/2012 09:16 AM, Kelly Grizzle wrote: You can always fetch the group to get the additional data, but this would i= ncur some cost. I agree that only including the displayName is a bit arbit= rary, though. IMO we should take a look at this more generally for all rel= ationships. For instance, this also applies to the "manager" attribute in = the enterprise user extension. I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attrib= ute -- in fact SCIM specifies different access control already in that the = groups attribute is read-only. IMO, it's likely that access control for ide= ntifiers like id and userName may be different than access control for attr= ibutes such as postal addresses and phone numbers. It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes: Users.groups: [{userName, id, displayName}, ...] Groups.member: [{groupName, id, displayName}, ...] --Dale --_000_56C3C758F9D6534CA3778EAA1E0C3437330E9587BY2PRD0410MB354_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tony, can you elaborate?&= nbsp; Are you saying that having the spec dictate that name, displayName, a= nd id should be returned for references is odd?  In one sense, I agree with you.  Name and displayName are a bit arbitrary, but woul= d probably be the most commonly used.

 <= /p>

Perhaps SCIM should suppo= rt expanding parts of references similar to OData - http://www.odata.org/media/30002/OData.html#theexpandsystemq= ueryoption.  It might make sense to allow retrieving only som= e of the referenced object’s attributes rather than the full represen= tation, though.

 <= /p>

By default (ie – wi= thout any expansion) I think that name, displayName, and id are a good set = of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.=

 <= /p>

--Kelly=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] userids, usernames, and group names

 

Seems odd to have a rigid= view, the object should be able to describe itself

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; scim@ietf.or= g; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:

 

You can always fetch the = group to get the additional data, but this would incur some cost.  I a= gree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all rel= ationships.  For instance, this also applies to the “managerR= 21; attribute in the enterprise user extension.

 


I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attribute -- in fact SCIM specifies differ= ent access control already in that the groups attribute is read-only. IMO, = it's likely that access control for identifiers like id and userName may be= different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale

--_000_56C3C758F9D6534CA3778EAA1E0C3437330E9587BY2PRD0410MB354_-- From tonynad@microsoft.com Tue Sep 4 12:09:49 2012 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 34FDD21E8054 for ; Tue, 4 Sep 2012 12:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHzB-gT+6ih for ; Tue, 4 Sep 2012 12:09:46 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9521E804E for ; Tue, 4 Sep 2012 12:09:46 -0700 (PDT) Received: from mail180-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 19:09:45 +0000 Received: from mail180-co1 (localhost [127.0.0.1]) by mail180-co1-R.bigfish.com (Postfix) with ESMTP id 0A5DA8400DE for ; Tue, 4 Sep 2012 19:09:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zzbb2dI98dI9371Ic85fh1418Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah1155h) Received-SPF: pass (mail180-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail180-co1 (localhost.localdomain [127.0.0.1]) by mail180-co1 (MessageSwitch) id 134678578363492_4488; Tue, 4 Sep 2012 19:09:43 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.254]) by mail180-co1.bigfish.com (Postfix) with ESMTP id 0AE82A20048 for ; Tue, 4 Sep 2012 19:09:43 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 19:09:41 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 4 Sep 2012 19:09:35 +0000 Received: from mail267-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 19:09:34 +0000 Received: from mail267-va3 (localhost [127.0.0.1]) by mail267-va3-R.bigfish.com (Postfix) with ESMTP id 5AC64180012D for ; Tue, 4 Sep 2012 19:09:34 +0000 (UTC) Received: from mail267-va3 (localhost.localdomain [127.0.0.1]) by mail267-va3 (MessageSwitch) id 1346785771991942_6042; Tue, 4 Sep 2012 19:09:31 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.249]) by mail267-va3.bigfish.com (Postfix) with ESMTP id EBE471240049; Tue, 4 Sep 2012 19:09:31 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 19:09:30 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.24]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 19:09:30 +0000 From: Anthony Nadalin To: Kelly Grizzle , Dale Olds Thread-Topic: [scim] userids, usernames, and group names Thread-Index: AQHNigZ2sorTwbEq1EKAFjSY1ZBZAZd5CTrQgAADWoCAAVC8gIAAGewAgAAFP9CAAAlfgIAABNEA Date: Tue, 4 Sep 2012 19:09:29 +0000 Message-ID: References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF9E3BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%RBCON.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%WSO2.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CLOUDIWAY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Hasini Gunasinghe , Emmanuel Dreux , "scim@ietf.org" Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 19:09:49 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF9E3BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By default I think it makes sense to have some common attributes returned l= ike ObjectId, ObjectType, Description, DisplayName, etc. but also believe w= e should allow for expanding parts of references (as ODATA does) for gettin= g other. From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Tuesday, September 04, 2012 11:42 AM To: Anthony Nadalin; Dale Olds Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names Tony, can you elaborate? Are you saying that having the spec dictate that = name, displayName, and id should be returned for references is odd? In one= sense, I agree with you. Name and displayName are a bit arbitrary, but wo= uld probably be the most commonly used. Perhaps SCIM should support expanding parts of references similar to OData = - http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. = It might make sense to allow retrieving only some of the referenced object'= s attributes rather than the full representation, though. By default (ie - without any expansion) I think that name, displayName, and= id are a good set of attributes. Alternatively, we could just return the = id and require the client to request expansion if they want name and displa= yName. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Anthony N= adalin Sent: Tuesday, September 04, 2012 1:11 PM To: Dale Olds; Kelly Grizzle Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org Subject: Re: [scim] userids, usernames, and group names Seems odd to have a rigid view, the object should be able to describe itsel= f From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Dale Olds Sent: Tuesday, September 04, 2012 10:50 AM To: Kelly Grizzle Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux Subject: Re: [scim] userids, usernames, and group names Kelly, On 09/04/2012 09:16 AM, Kelly Grizzle wrote: You can always fetch the group to get the additional data, but this would i= ncur some cost. I agree that only including the displayName is a bit arbit= rary, though. IMO we should take a look at this more generally for all rel= ationships. For instance, this also applies to the "manager" attribute in = the enterprise user extension. I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attrib= ute -- in fact SCIM specifies different access control already in that the = groups attribute is read-only. IMO, it's likely that access control for ide= ntifiers like id and userName may be different than access control for attr= ibutes such as postal addresses and phone numbers. It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes: Users.groups: [{userName, id, displayName}, ...] Groups.member: [{groupName, id, displayName}, ...] --Dale --_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF9E3BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

By default I think it mak= es sense to have some common attributes returned like ObjectId, ObjectType,= Description, DisplayName, etc. but also believe we should allow for expanding parts of references (as ODATA does) for getting other.=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.o= rg] On Behalf Of Kelly Grizzle
Sent: Tuesday, September 04, 2012 11:42 AM
To: Anthony Nadalin; Dale Olds
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Tony, can you elaborate?&= nbsp; Are you saying that having the spec dictate that name, displayName, a= nd id should be returned for references is odd?  In one sense, I agree with you.  Name and displayName are a bit arbitrary, but woul= d probably be the most commonly used.

 <= /p>

Perhaps SCIM should suppo= rt expanding parts of references similar to OData - http://www.odata.org/media/30002/OData.html#theexpandsystemq= ueryoption.  It might make sense to allow retrieving only som= e of the referenced object’s attributes rather than the full represen= tation, though.

 <= /p>

By default (ie – wi= thout any expansion) I think that name, displayName, and id are a good set = of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.=

 <= /p>

--Kelly=

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] userids, usernames, and group names

 

Seems odd to have a rigid= view, the object should be able to describe itself

 <= /p>

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; scim@ietf.or= g; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:

 

You can always fetch the = group to get the additional data, but this would incur some cost.  I a= gree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all rel= ationships.  For instance, this also applies to the “managerR= 21; attribute in the enterprise user extension.

 


I agree that when we read a user's groups attribute, we could always fetch = the groups to get the displayName, or whatever attribute we use as the grou= pName. But it's not just a performance issue to add that fetch, the access = control on the group resource itself may be different than the users attribute -- in fact SCIM specifies differ= ent access control already in that the groups attribute is read-only. IMO, = it's likely that access control for identifiers like id and userName may be= different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applica= tions (with better performance) if we could get these three attributes as s= ubattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7620AF9E3BL2PRD0310MB362_-- From trey.drake@unboundid.com Tue Sep 4 12:14:55 2012 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 76C2821E8064 for ; Tue, 4 Sep 2012 12:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fbJNqufHSiI for ; Tue, 4 Sep 2012 12:14:54 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37021E804D for ; Tue, 4 Sep 2012 12:14:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1420051ghb.31 for ; Tue, 04 Sep 2012 12:14:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zmBkWAlyr26tXwNS5Tnvmza9qzwt4hSmx5ze7JCjoIY=; b=FdoGrKj8kKmacY8EQR44ee8pfMB0OIYf/T170vT+hdeFr/4fvxVPezvd/Qc6I2yWlh KRKCpqnc45VCL9ql4S1cSnOz7LRnNqUIf6MsvL5C27uFD4al92xVKWSKOoPU2wPgoGTz Kr9CSVC1Ll+BXD7ailoOSeGpUrbYqkHRWMhtD32JkOc+l78Ay9OHC4hNxg7Popo8Uuvc UkFzqxQI0nuJCjQNnoHdw4YXejCg/QPMyc7TVZ4VL/nA/IZbZFv5uCR6WvBUsTDv0Bgh vmc2FVOvSDsEO0d1BqLqddsQwrSaf47BZNZJNL61H44kmS3CGBBsjhGHhDbJrKMFc4q6 aNUA== Received: by 10.236.87.194 with SMTP id y42mr19568971yhe.81.1346786093083; Tue, 04 Sep 2012 12:14:53 -0700 (PDT) Received: from [192.168.241.248] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id e16sm15813423ani.22.2012.09.04.12.14.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 12:14:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B35A98C7-F69A-492B-B37C-B03316520F98" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: Date: Tue, 4 Sep 2012 14:14:48 -0500 Message-Id: <872361B8-C990-4065-90BD-6038793D9AFF@unboundid.com> References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkN9ZejPt+Md1EKZ/Bpl0nSlKICDdxlJk49+R9JdjxmJV78+0uyHeWDEoC3daSBN0WhUHGl Cc: Dale Olds , Emmanuel Dreux , "scim@ietf.org" , Hasini Gunasinghe , Kelly Grizzle Subject: Re: [scim] userids, usernames, and group names 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, 04 Sep 2012 19:14:55 -0000 --Apple-Mail=_B35A98C7-F69A-492B-B37C-B03316520F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 On Sep 4, 2012, at 2:09 PM, Anthony Nadalin = wrote: > By default I think it makes sense to have some common attributes = returned like ObjectId, ObjectType, Description, DisplayName, etc. but = also believe we should allow for expanding parts of references (as ODATA = does) for getting other. > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Kelly Grizzle > Sent: Tuesday, September 04, 2012 11:42 AM > To: Anthony Nadalin; Dale Olds > Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux > Subject: Re: [scim] userids, usernames, and group names > =20 > Tony, can you elaborate? Are you saying that having the spec dictate = that name, displayName, and id should be returned for references is odd? = In one sense, I agree with you. Name and displayName are a bit = arbitrary, but would probably be the most commonly used. > =20 > Perhaps SCIM should support expanding parts of references similar to = OData = -http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. = It might make sense to allow retrieving only some of the referenced = object=92s attributes rather than the full representation, though. > =20 > By default (ie =96 without any expansion) I think that name, = displayName, and id are a good set of attributes. Alternatively, we = could just return the id and require the client to request expansion if = they want name and displayName. > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Anthony Nadalin > Sent: Tuesday, September 04, 2012 1:11 PM > To: Dale Olds; Kelly Grizzle > Cc: Hasini Gunasinghe; Emmanuel Dreux;scim@ietf.org > Subject: Re: [scim] userids, usernames, and group names > =20 > Seems odd to have a rigid view, the object should be able to describe = itself > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Dale Olds > Sent: Tuesday, September 04, 2012 10:50 AM > To: Kelly Grizzle > Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux > Subject: Re: [scim] userids, usernames, and group names > =20 > Kelly, >=20 > On 09/04/2012 09:16 AM, Kelly Grizzle wrote: > =20 > You can always fetch the group to get the additional data, but this = would incur some cost. I agree that only including the displayName is a = bit arbitrary, though. IMO we should take a look at this more generally = for all relationships. For instance, this also applies to the =93manager=94= attribute in the enterprise user extension. > =20 >=20 > I agree that when we read a user's groups attribute, we could always = fetch the groups to get the displayName, or whatever attribute we use as = the groupName. But it's not just a performance issue to add that fetch, = the access control on the group resource itself may be different than = the users attribute -- in fact SCIM specifies different access control = already in that the groups attribute is read-only. IMO, it's likely that = access control for identifiers like id and userName may be different = than access control for attributes such as postal addresses and phone = numbers.=20 >=20 > It would be easier to handle the access control needs of our client = applications (with better performance) if we could get these three = attributes as subattributes in the User 'groups' and Group 'members' = attributes: >=20 > Users.groups: [{userName, id, displayName}, ...] >=20 > Groups.member: [{groupName, id, displayName}, ...] >=20 > --Dale > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_B35A98C7-F69A-492B-B37C-B03316520F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1

On Sep 4, = 2012, at 2:09 PM, Anthony Nadalin <tonynad@microsoft.com> = wrote:

By default I think it makes sense to have some = common attributes returned like ObjectId, ObjectType, Description, = DisplayName, etc. but also believe we should allow for expanding parts = of references (as ODATA does) for getting = other.
 
From: scim-bounces@ietf.org = [mailto:scim-bounces@ietf.org] On Behalf Of Kelly = Grizzle
Sent: Tuesday, September 04, 2012 = 11:42 AM
To: Anthony Nadalin; Dale = Olds
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel = Dreux
Subject: Re: [scim] userids, = usernames, and group names
 
Tony, can you elaborate?  Are you saying = that having the spec dictate that name, displayName, and id should be = returned for references is odd?  In one sense, I agree with = you.  Name and displayName are a bit arbitrary, but would probably = be the most commonly used.
 
 scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony = Nadalin
Sent: Tuesday, September 04, 2012 = 1:11 PM
To: Dale Olds; Kelly = Grizzle
Cc: Hasini Gunasinghe; Emmanuel = Dreux;scim@ietf.org
Subject: Re: [scim] userids, = usernames, and group names
 
Seems odd to have a rigid view, the object = should be able to describe itself
 scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale = Olds
Sent: Tuesday, September 04, 2012 = 10:50 AM
To: Kelly = Grizzle
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, = usernames, and group names
 

Kelly,

On = 09/04/2012 09:16 AM, Kelly Grizzle = wrote:
You can always fetch the group to get the additional = data, but this would incur some cost.  I agree that only including = the displayName is a bit arbitrary, though.  IMO we should take a = look at this more generally for all relationships.  For instance, = this also applies to the =93manager=94 attribute in the enterprise user = extension.
 

It would be easier = to handle the access control needs of our client applications (with = better performance) if we could get these three attributes as = subattributes in the User 'groups' and Group 'members' = attributes:

Users.groups: [{userName, id, displayName}, = ...]

Groups.member: [{groupName, id, displayName}, = ...]

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

= --Apple-Mail=_B35A98C7-F69A-492B-B37C-B03316520F98-- From olds@rbcon.com Tue Sep 4 23:12:54 2012 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 5DC8911E80E6 for ; Tue, 4 Sep 2012 23:12:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR42mQr59BZR for ; Tue, 4 Sep 2012 23:12:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5811E80DE for ; Tue, 4 Sep 2012 23:12:51 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so372796pbb.31 for ; Tue, 04 Sep 2012 23:12:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=rH08B2ST7Sd8nLNYYDnIOst2KiP5AnabRv+xL7X0JIw=; b=XML5S3DaFNXgynW4hlteS2JRlg16MGtZuw6Iin8pBnj463OOAVvtucXKJzCw0v7Oe6 MrBspzyaP8ysJIBukn/uR69UeSrHGlI670Um0CWpbAU/HNhwmaDNgWEvvI9DhmmOmFtb JbcwHq6KVqEPxhrddMhpNY0qMeKnxJCdXQbEsUUNqDKaH+b1BPx0c9jAe6yvqIZNtlxj osZmsRfdeZnOx45aoW5Om3YuD+aeHiBlxKqMaCKrXNW2iDhbrayzUeBAMlmLer5Zu0RJ 2/4z8TlAvBfDdXvifGnqOvyDwalpKGTOMsu657A3Vl9xR+9mNiNprr09EJj3X/r73CmP xWvw== Received: by 10.68.138.234 with SMTP id qt10mr51563555pbb.26.1346825570870; Tue, 04 Sep 2012 23:12:50 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id pv9sm697813pbb.67.2012.09.04.23.12.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 23:12:49 -0700 (PDT) Message-ID: <5046ED60.2040604@rbcon.com> Date: Tue, 04 Sep 2012 23:12:48 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Anthony Nadalin References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090801090200000102030703" X-Gm-Message-State: ALoCoQlshz7PyaIh0XnE+rxvFIJjlEQhyi8Jp6JiZ6brlayjZbgIrCtft3i/HxW/fRWfaIkhMq3n Cc: Hasini Gunasinghe , Emmanuel Dreux , "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] userids, usernames, and group names 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, 05 Sep 2012 06:12:54 -0000 This is a multi-part message in MIME format. --------------090801090200000102030703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tony, previously in this thread: > the object should be able to describe itself A self describing object sounds like self documenting code, but, like self documenting code, I'm all for it if it really works. In the meantime, I would separate your list of common attributes below into two categories: identifiers and informational. As I see it, the identifiers in your list are ObjectID and ObjectType. I include ObjectType here because, if objects can be retrieved from multiple endpoints depending on type (/Users vs. /Groups), we need to know the type to know how to identify the object. The informational attributes are Description and DisplayName. As discussed earlier in this thread, retrieving them as subattributes in a multi-valued attribute can affect performance and access control, but they are not required to get more information about the object. At least one identifier IS required. My point is that I think two identifiers are useful in different use cases. My purpose in this thread was to see if there would be support for another identifier for Group, similar to userName for User. As Kelly said, it keeps the resources similar. I'd also think that identifiers should be able to be retrieved as subattributes for multi-valued attributes that reference an object. If you can make it so any reference can be expanded to arbitrary attributes (identifiers or informational) in a relatively easy way, that would work for me, but it sounds like a big addition. I haven't read OData yet. In this thread I was looking to see if there would be support for making identifiers for Group more like User -- which appears to me to be a fairly small addition. --Dale On 09/04/2012 12:09 PM, Anthony Nadalin wrote: > > By default I think it makes sense to have some common attributes > returned like ObjectId, ObjectType, Description, DisplayName, etc. but > also believe we should allow for expanding parts of references (as > ODATA does) for getting other. > > *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Kelly Grizzle > *Sent:* Tuesday, September 04, 2012 11:42 AM > *To:* Anthony Nadalin; Dale Olds > *Cc:* Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux > *Subject:* Re: [scim] userids, usernames, and group names > > Tony, can you elaborate? Are you saying that having the spec dictate > that name, displayName, and id should be returned for references is > odd? In one sense, I agree with you. Name and displayName are a bit > arbitrary, but would probably be the most commonly used. > > Perhaps SCIM should support expanding parts of references similar to > OData - > http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. It > might make sense to allow retrieving only some of the referenced > object's attributes rather than the full representation, though. > > By default (ie -- without any expansion) I think that name, > displayName, and id are a good set of attributes. Alternatively, we > could just return the id and require the client to request expansion > if they want name and displayName. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org] > *On Behalf Of *Anthony Nadalin > *Sent:* Tuesday, September 04, 2012 1:11 PM > *To:* Dale Olds; Kelly Grizzle > *Cc:* Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org > > *Subject:* Re: [scim] userids, usernames, and group names > > Seems odd to have a rigid view, the object should be able to describe > itself > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org] *On Behalf Of *Dale Olds > *Sent:* Tuesday, September 04, 2012 10:50 AM > *To:* Kelly Grizzle > *Cc:* Hasini Gunasinghe; scim@ietf.org ; > Emmanuel Dreux > *Subject:* Re: [scim] userids, usernames, and group names > > Kelly, > > On 09/04/2012 09:16 AM, Kelly Grizzle wrote: > > You can always fetch the group to get the additional data, but > this would incur some cost. I agree that only including the > displayName is a bit arbitrary, though. IMO we should take a look > at this more generally for all relationships. For instance, this > also applies to the "manager" attribute in the enterprise user > extension. > > > I agree that when we read a user's groups attribute, we could always > fetch the groups to get the displayName, or whatever attribute we use > as the groupName. But it's not just a performance issue to add that > fetch, the access control on the group resource itself may be > different than the users attribute -- in fact SCIM specifies different > access control already in that the groups attribute is read-only. IMO, > it's likely that access control for identifiers like id and userName > may be different than access control for attributes such as postal > addresses and phone numbers. > > It would be easier to handle the access control needs of our client > applications (with better performance) if we could get these three > attributes as subattributes in the User 'groups' and Group 'members' > attributes: > > Users.groups: [{userName, id, displayName}, ...] > > Groups.member: [{groupName, id, displayName}, ...] > > --Dale > --------------090801090200000102030703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tony,

previously in this thread:
the object should be able to describe itself

A self describing object sounds like self documenting code, but, like self documenting code, I'm all for it if it really works.

In the meantime, I would separate your list of common attributes below into two categories: identifiers and informational.

As I see it, the identifiers in your list are ObjectID and ObjectType. I include ObjectType here because, if objects can be retrieved from multiple endpoints depending on type (/Users vs. /Groups), we need to know the type to know how to identify the object.

The informational attributes are Description and DisplayName. As discussed earlier in this thread, retrieving them as subattributes in a multi-valued attribute can affect performance and access control, but they are not required to get more information about the object.

At least one identifier IS required. My point is that I think two identifiers are useful in different use cases. My purpose in this thread was to see if there would be support for another identifier for Group, similar to userName for User. As Kelly said, it keeps the resources similar. I'd also think that identifiers should be able to be retrieved as subattributes for multi-valued attributes that reference an object.

If you can make it so any reference can be expanded to arbitrary attributes (identifiers or informational) in a relatively easy way, that would work for me, but it sounds like a big addition. I haven't read OData yet. In this thread I was looking to see if there would be support for making identifiers for Group more like User -- which appears to me to be a fairly small addition.

--Dale

On 09/04/2012 12:09 PM, Anthony Nadalin wrote:

By default I think it makes sense to have some common attributes returned like ObjectId, ObjectType, Description, DisplayName, etc. but also believe we should allow for expanding parts of references (as ODATA does) for getting other.

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle
Sent: Tuesday, September 04, 2012 11:42 AM
To: Anthony Nadalin; Dale Olds
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Tony, can you elaborate?  Are you saying that having the spec dictate that name, displayName, and id should be returned for references is odd?  In one sense, I agree with you.  Name and displayName are a bit arbitrary, but would probably be the most commonly used.

 

Perhaps SCIM should support expanding parts of references similar to OData - http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption.  It might make sense to allow retrieving only some of the referenced object’s attributes rather than the full representation, though.

 

By default (ie – without any expansion) I think that name, displayName, and id are a good set of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] userids, usernames, and group names

 

Seems odd to have a rigid view, the object should be able to describe itself

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:

 

You can always fetch the group to get the additional data, but this would incur some cost.  I agree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all relationships.  For instance, this also applies to the “manager” attribute in the enterprise user extension.

 


I agree that when we read a user's groups attribute, we could always fetch the groups to get the displayName, or whatever attribute we use as the groupName. But it's not just a performance issue to add that fetch, the access control on the group resource itself may be different than the users attribute -- in fact SCIM specifies different access control already in that the groups attribute is read-only. IMO, it's likely that access control for identifiers like id and userName may be different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applications (with better performance) if we could get these three attributes as subattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale


--------------090801090200000102030703-- From igor.faynberg@alcatel-lucent.com Wed Sep 5 03:23:37 2012 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 5BEED21F85ED for ; Wed, 5 Sep 2012 03:23:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VynRqJnrXPNP for ; Wed, 5 Sep 2012 03:23:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2A21F85E7 for ; Wed, 5 Sep 2012 03:23:31 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q85ANUct011072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Sep 2012 05:23:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q85ANUFM000766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Sep 2012 05:23:30 -0500 Received: from [135.244.0.86] (faynberg.lra.lucent.com [135.244.0.86]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q85ANShZ006600; Wed, 5 Sep 2012 05:23:29 -0500 (CDT) Message-ID: <50472820.4090601@alcatel-lucent.com> Date: Wed, 05 Sep 2012 06:23:28 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <504133BE.4020704@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E7B64@BY2PRD0410MB354.namprd04.prod.outlook.com> <50463F2E.1090503@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330E9587@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070308040806010801020605" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [scim] userids, usernames, and group names X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:23:37 -0000 This is a multi-part message in MIME format. --------------070308040806010801020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Igor On 9/4/2012 3:09 PM, Anthony Nadalin wrote: > > By default I think it makes sense to have some common attributes > returned like ObjectId, ObjectType, Description, DisplayName, etc. but > also believe we should allow for expanding parts of references (as > ODATA does) for getting other. > > *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Kelly Grizzle > *Sent:* Tuesday, September 04, 2012 11:42 AM > *To:* Anthony Nadalin; Dale Olds > *Cc:* Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux > *Subject:* Re: [scim] userids, usernames, and group names > > Tony, can you elaborate? Are you saying that having the spec dictate > that name, displayName, and id should be returned for references is > odd? In one sense, I agree with you. Name and displayName are a bit > arbitrary, but would probably be the most commonly used. > > Perhaps SCIM should support expanding parts of references similar to > OData - > http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. It > might make sense to allow retrieving only some of the referenced > object's attributes rather than the full representation, though. > > By default (ie -- without any expansion) I think that name, > displayName, and id are a good set of attributes. Alternatively, we > could just return the id and require the client to request expansion > if they want name and displayName. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org] > *On Behalf Of *Anthony Nadalin > *Sent:* Tuesday, September 04, 2012 1:11 PM > *To:* Dale Olds; Kelly Grizzle > *Cc:* Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org > > *Subject:* Re: [scim] userids, usernames, and group names > > Seems odd to have a rigid view, the object should be able to describe > itself > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org] *On Behalf Of *Dale Olds > *Sent:* Tuesday, September 04, 2012 10:50 AM > *To:* Kelly Grizzle > *Cc:* Hasini Gunasinghe; scim@ietf.org ; > Emmanuel Dreux > *Subject:* Re: [scim] userids, usernames, and group names > > Kelly, > > On 09/04/2012 09:16 AM, Kelly Grizzle wrote: > > You can always fetch the group to get the additional data, but > this would incur some cost. I agree that only including the > displayName is a bit arbitrary, though. IMO we should take a look > at this more generally for all relationships. For instance, this > also applies to the "manager" attribute in the enterprise user > extension. > > > I agree that when we read a user's groups attribute, we could always > fetch the groups to get the displayName, or whatever attribute we use > as the groupName. But it's not just a performance issue to add that > fetch, the access control on the group resource itself may be > different than the users attribute -- in fact SCIM specifies different > access control already in that the groups attribute is read-only. IMO, > it's likely that access control for identifiers like id and userName > may be different than access control for attributes such as postal > addresses and phone numbers. > > It would be easier to handle the access control needs of our client > applications (with better performance) if we could get these three > attributes as subattributes in the User 'groups' and Group 'members' > attributes: > > Users.groups: [{userName, id, displayName}, ...] > > Groups.member: [{groupName, id, displayName}, ...] > > --Dale > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------070308040806010801020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Igor

 
On 9/4/2012 3:09 PM, Anthony Nadalin wrote:

By default I think it makes sense to have some common attributes returned like ObjectId, ObjectType, Description, DisplayName, etc. but also believe we should allow for expanding parts of references (as ODATA does) for getting other.

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle
Sent: Tuesday, September 04, 2012 11:42 AM
To: Anthony Nadalin; Dale Olds
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Tony, can you elaborate?  Are you saying that having the spec dictate that name, displayName, and id should be returned for references is odd?  In one sense, I agree with you.  Name and displayName are a bit arbitrary, but would probably be the most commonly used.

 

Perhaps SCIM should support expanding parts of references similar to OData - http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption.  It might make sense to allow retrieving only some of the referenced object’s attributes rather than the full representation, though.

 

By default (ie – without any expansion) I think that name, displayName, and id are a good set of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] userids, usernames, and group names

 

Seems odd to have a rigid view, the object should be able to describe itself

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

 

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:

 

You can always fetch the group to get the additional data, but this would incur some cost.  I agree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all relationships.  For instance, this also applies to the “manager” attribute in the enterprise user extension.

 


I agree that when we read a user's groups attribute, we could always fetch the groups to get the displayName, or whatever attribute we use as the groupName. But it's not just a performance issue to add that fetch, the access control on the group resource itself may be different than the users attribute -- in fact SCIM specifies different access control already in that the groups attribute is read-only. IMO, it's likely that access control for identifiers like id and userName may be different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applications (with better performance) if we could get these three attributes as subattributes in the User 'groups' and Group 'members' attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------070308040806010801020605-- From kelly.grizzle@sailpoint.com Wed Sep 5 06:32:20 2012 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 CC2BC21F84CF for ; Wed, 5 Sep 2012 06:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOxs5b-uPpal for ; Wed, 5 Sep 2012 06:32:19 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id B437F21F84D9 for ; Wed, 5 Sep 2012 06:32:19 -0700 (PDT) Received: from mail239-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 13:32:18 +0000 Received: from mail239-tx2 (localhost [127.0.0.1]) by mail239-tx2-R.bigfish.com (Postfix) with ESMTP id C4B9B4C017B; Wed, 5 Sep 2012 13:32:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic85fh4015I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail239-tx2: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail239-tx2 (localhost.localdomain [127.0.0.1]) by mail239-tx2 (MessageSwitch) id 134685193781718_7605; Wed, 5 Sep 2012 13:32:17 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.236]) by mail239-tx2.bigfish.com (Postfix) with ESMTP id 05F2840045; Wed, 5 Sep 2012 13:32:17 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 13:32:14 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.140]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0190.008; Wed, 5 Sep 2012 13:32:05 +0000 From: Kelly Grizzle To: Hasini Gunasinghe , "scim@ietf.org" Thread-Topic: [scim] Proposing permissions/entitlements attribute to group schema Thread-Index: AQHNiO714PEyYpnTsE+SdPYWK8e5f5d7wxzw Date: Wed, 5 Sep 2012 13:32:04 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E989D@BY2PRD0410MB354.namprd04.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: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330E989DBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Proposing permissions/entitlements attribute to group 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: Wed, 05 Sep 2012 13:32:20 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330E989DBY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that this is very useful for identity management systems that provi= de group management and/or synchronization. I'm not sure if this is genera= lly useful for the typical SCIM consumer, so I don't know whether it would = be better placed in the core or as a standard extension. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Has= ini Gunasinghe Sent: Sunday, September 02, 2012 4:40 AM To: scim@ietf.org Subject: [scim] Proposing permissions/entitlements attribute to group schem= a Hi all, In the identity management systems that support Role Based Access Control, = groups/roles are assigned a set of permissions/entitlements which are requi= red to be synchronized across domains along with the corresponding groups. Having an optional, multi-valued attribute as permissions/entitlements in t= he group schema is useful to facilitate such requirements. Appreciate thoughts on this. Thanks, Hasini. --_000_56C3C758F9D6534CA3778EAA1E0C3437330E989DBY2PRD0410MB354_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that this is very= useful for identity management systems that provide group management and/o= r synchronization.  I’m not sure if this is generally useful for the typical SCIM consumer, so I don’t know whether it would be b= etter placed in the core or as a standard extension.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02, 2012 4:40 AM
To: scim@ietf.org
Subject: [scim] Proposing permissions/entitlements attribute to grou= p schema

 

Hi all,

 

In the identity management systems that support Role= Based Access Control, groups/roles are assigned a set of permissions/entit= lements which are required to be synchronized across domains alon= g with the corresponding groups.

Having an optional, multi-valued attribute as permis= sions/entitlements in the group schema is useful to facilitate such require= ments.

 

Appreciate thoughts on this.

 

Thanks,

Hasini.

--_000_56C3C758F9D6534CA3778EAA1E0C3437330E989DBY2PRD0410MB354_-- From phil.hunt@oracle.com Thu Sep 6 09:55:32 2012 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 1CAE221F874F for ; Thu, 6 Sep 2012 09:55:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpPkiXIpYn-9 for ; Thu, 6 Sep 2012 09:55:31 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6321F872D for ; Thu, 6 Sep 2012 09:55:30 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q86GtTLG026273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Sep 2012 16:55:30 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q86GtS4E008048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 16:55:29 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q86GtSAm023899 for ; Thu, 6 Sep 2012 11:55:28 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Sep 2012 09:55:28 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_4FD42042-DD81-4BC3-B8F7-8D338433CA21" Date: Thu, 6 Sep 2012 09:53:59 -0700 References: <20120906164349.22618.79831.idtracker@ietfa.amsl.com> To: scim WG Message-Id: <869261FB-D933-415E-BFAD-0B3302419776@oracle.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] Fwd: New Version Notification for draft-hunt-scim-directory-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: Thu, 06 Sep 2012 16:55:32 -0000 --Apple-Mail=_4FD42042-DD81-4BC3-B8F7-8D338433CA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As a follow-up to the Vancouver IETF meeting, I have put together an = initial draft on a SCIM Directory for the WG. The directory spec does = not alter the SCIM protocol, but imposes some additional requirements = (MUST implements) that are not required in the core API spec and makes = distinctions between a Directory implementation and an Application = implementation of the core SCIM specifications. The draft aso includes a proposed mapping for SCIM to LDAP support and = defines what a SCIM Directory is. Note that some items, such as searching without regards to object type = have not been addressed here. Rather I think these should be addressed = in the API spec itself. Please note that this draft still needs much discussion. However it = seemed time given that several have indicated to me personally they want = to move forward on a draft.=20 I will be away for the remainder of the month, but plan to catch up and = collect feedback early next month. Phil @independentid www.independentid.com phil.hunt@oracle.com Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-scim-directory-00.txt > Date: 6 September, 2012 9:43:49 AM PDT > To: phil.hunt@yahoo.com >=20 >=20 > A new version of I-D, draft-hunt-scim-directory-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Filename: draft-hunt-scim-directory > Revision: 00 > Title: SCIM Directory Services > Creation date: 2012-09-06 > WG ID: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-hunt-scim-directory-00.txt > Status: = http://datatracker.ietf.org/doc/draft-hunt-scim-directory > Htmlized: = http://tools.ietf.org/html/draft-hunt-scim-directory-00 >=20 >=20 > Abstract: > This document describes a directory server that implements the SCIM > protocol and schema [, its capabilities and access control model], > and optional support for LDAPv3 protocol. This specification = extends > SCIM from provisioning to a general purpose access protocol in > support of data management applications (e.g. self-service systems) > and RESTful clients that need read/write access to a directory on = the > Internet, between domains, or within a cloud. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_4FD42042-DD81-4BC3-B8F7-8D338433CA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As a = follow-up to the Vancouver IETF meeting, I have put together an initial = draft on a SCIM Directory for the WG. The directory spec does not = alter the SCIM protocol, but imposes some additional requirements (MUST = implements) that are not required in the core API spec and makes = distinctions between a Directory implementation and an Application = implementation of the core SCIM specifications.

The = draft aso includes a proposed mapping for SCIM to LDAP support and = defines what a SCIM Directory is.

Note that = some items, such as searching without regards to object type have not = been addressed here. Rather I think these should be addressed in the API = spec itself.

Please note that this draft still = needs much discussion. However it seemed time given that several have = indicated to me personally they want to move forward on a = draft. 

I will be away for the remainder = of the month, but plan to catch up and collect feedback early next = month.


Begin forwarded message:

Subject: New Version Notification for = draft-hunt-scim-directory-00.txt
Date: 6 September, 2012 = 9:43:49 AM PDT
To: phil.hunt@yahoo.com


A new version of I-D, = draft-hunt-scim-directory-00.txt
has been successfully submitted by = Phil Hunt and posted to the
IETF repository.

Filename: = draft-hunt-scim-directory
Revision: 00
Title: SCIM = Directory Services
Creation date: 2012-09-06
WG ID: = Individual Submission
Number of pages: 14
URL: =             http://www.ietf.org/internet-drafts/draft-hunt-scim-directory-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-hunt-scim-directory
Htmlized: =        http://to= ols.ietf.org/html/draft-hunt-scim-directory-00


Abstract:   This document describes a directory server that implements = the SCIM
  protocol and schema [, its capabilities and = access control model],
  and optional support for LDAPv3 = protocol.  This specification extends
  SCIM from = provisioning to a general purpose access protocol in
=   support of data management applications (e.g. self-service = systems)
  and RESTful clients that need read/write access = to a directory on the
  Internet, between domains, or = within a cloud.




The IETF = Secretariat


= --Apple-Mail=_4FD42042-DD81-4BC3-B8F7-8D338433CA21-- From phil.hunt@oracle.com Thu Sep 6 14:37:51 2012 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 1586421F863B for ; Thu, 6 Sep 2012 14:37:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqiWK6t6xiji for ; Thu, 6 Sep 2012 14:37:50 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 97CF921F8643 for ; Thu, 6 Sep 2012 14:37:49 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q86LbmUo019552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Sep 2012 21:37:49 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q86LblgG027659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 21:37:48 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q86LblVB030939 for ; Thu, 6 Sep 2012 16:37:47 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Sep 2012 14:37:47 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_35FB28DA-A0AA-467D-A996-CE0085FB7BFC" Date: Thu, 6 Sep 2012 14:36:03 -0700 References: <20120906212502.12305.8918.idtracker@ietfa.amsl.com> To: scim WG Message-Id: <4BCCB207-ED46-4844-A2D0-3A0D22655F24@oracle.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [scim] Fwd: New Version Notification for draft-hunt-scim-targeting-01.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: Thu, 06 Sep 2012 21:37:51 -0000 --Apple-Mail=_35FB28DA-A0AA-467D-A996-CE0085FB7BFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I noticed that this draft will expire while I am away on vacation. = Thought it best to keep around for future discussion. No changes have = been made in draft 01. Regards, Phil @independentid www.independentid.com phil.hunt@oracle.com Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-scim-targeting-01.txt > Date: 6 September, 2012 2:25:02 PM PDT > To: phil.hunt@yahoo.com >=20 >=20 > A new version of I-D, draft-hunt-scim-targeting-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Filename: draft-hunt-scim-targeting > Revision: 01 > Title: SCIM Targeted Resource Extension > Creation date: 2012-09-06 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-hunt-scim-targeting-01.txt > Status: = http://datatracker.ietf.org/doc/draft-hunt-scim-targeting > Htmlized: = http://tools.ietf.org/html/draft-hunt-scim-targeting-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-scim-targeting-01 >=20 > Abstract: > The core SCIM 1.0 specification is intended to provide updates to a > single cloud-based application. This extension specifies an extended > API definition which allows a single SCIM endpoint to support = updates > to multiple cloud-based applications. These extensions enable = network > relationships such as proxy updates, and hub-to-hub-to-spoke > relationships in addition to the hub-spoke relationship defined in > the core SCIM 1.0 specification. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_35FB28DA-A0AA-467D-A996-CE0085FB7BFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

I noticed that this draft will expire while I am = away on vacation. Thought it best to keep around for future discussion. =  No changes have been made in draft = 01.

Regards,

Phil

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





Begin forwarded message:

Subject: New Version Notification for = draft-hunt-scim-targeting-01.txt
Date: 6 September, 2012 = 2:25:02 PM PDT
To: phil.hunt@yahoo.com


A new version of I-D, = draft-hunt-scim-targeting-01.txt
has been successfully submitted by = Phil Hunt and posted to the
IETF repository.

Filename: = draft-hunt-scim-targeting
Revision: 01
Title: SCIM = Targeted Resource Extension
Creation date: = 2012-09-06
WG ID: Individual Submission
Number = of pages: 12
URL: =             http://www.ietf.org/internet-drafts/draft-hunt-scim-targeting-01.txt
Status:          http://= datatracker.ietf.org/doc/draft-hunt-scim-targeting
Htmlized: =        http://to= ols.ietf.org/html/draft-hunt-scim-targeting-01
Diff: =            h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-scim-targeting-01

= Abstract:
  The core SCIM 1.0 specification is intended to = provide updates to a
  single cloud-based application. = This extension specifies an extended
  API definition = which allows a single SCIM endpoint to support updates
=   to multiple cloud-based applications. These extensions = enable network
  relationships such as proxy updates, and = hub-to-hub-to-spoke
  relationships in addition to the = hub-spoke relationship defined in
  the core SCIM 1.0 = specification.





The IETF = Secretariat


= --Apple-Mail=_35FB28DA-A0AA-467D-A996-CE0085FB7BFC-- From hasini@wso2.com Mon Sep 10 00:53:02 2012 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 3CD8021F849C for ; Mon, 10 Sep 2012 00:53:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW+B0zmveMYy for ; Mon, 10 Sep 2012 00:53:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB421F8498 for ; Mon, 10 Sep 2012 00:52:52 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so190839vbb.31 for ; Mon, 10 Sep 2012 00:52:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MchGYk6VxAKAmL4i0Bea7OSvFFEDdyJLLFk2gvb+nSg=; b=kyHi+9n/CAOk0iUuMZGdAwm/njYhxte3rXR/DL7zNybxWa3xHpfhLaD72Ob8HGpgaj 3I7rUp1BbRabU0X8PkuiIvti32AOiyc9HO1rj739BKz1ZVgszrA1hhN0ZnvJndPYzq3H ymYm5Z9Tgw9XLtzKxU4Lxbo1q8kq0bWrcnQpJCAtBBInA/CLlAt6SL7OnBEvBJbcUS0h K5Ut+T8CLEn69iz5B57VMw3htupjj0VnfDmvVh3dx+jn9Jr7gH3EIvO/yy6lD1U6v+BP BSEN/nxX3Xbj/Uk4PD305Wpg4oAh2y8QwoAT8lEnzZ885sPNDhpOiRM6G9qeUmgtOn6E JjCw== MIME-Version: 1.0 Received: by 10.52.26.138 with SMTP id l10mr4745048vdg.104.1347263571980; Mon, 10 Sep 2012 00:52:51 -0700 (PDT) Received: by 10.58.124.101 with HTTP; Mon, 10 Sep 2012 00:52:51 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330E989D@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C3437330E989D@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Mon, 10 Sep 2012 13:22:51 +0530 Message-ID: From: Hasini Gunasinghe To: Kelly Grizzle Content-Type: multipart/alternative; boundary=bcaec5314441a0727c04c9543efe X-Gm-Message-State: ALoCoQmDqUjBOfobIRSl5cqo/gkxbd5hv1JeSinS8PoLtq4byGd3x+b/M05+Xi4Um3kdONC0qQlx Cc: "scim@ietf.org" Subject: Re: [scim] Proposing permissions/entitlements attribute to group 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: Mon, 10 Sep 2012 07:53:02 -0000 --bcaec5314441a0727c04c9543efe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kelly, Yes, I get your point. Usually most identity management systems support authorization management and RBAC has become common. Therefore having it as an optional attribute in core-group schema will not make any harm IMO. Currently 'entitlement' attribute is in core-user schema which facilitate user based authorization model - which is kind of obsolete. However, If the majority think it is not useful to have in core-group schema, we can define a custom extended schema and use. Thanks, Hasini. On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle wrote: > I agree that this is very useful for identity management systems that > provide group management and/or synchronization. I=92m not sure if this = is > generally useful for the typical SCIM consumer, so I don=92t know whether= it > would be better placed in the core or as a standard extension.**** > > ** ** > > --Kelly**** > > ** ** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Hasini Gunasinghe > *Sent:* Sunday, September 02, 2012 4:40 AM > *To:* scim@ietf.org > *Subject:* [scim] Proposing permissions/entitlements attribute to group > schema**** > > ** ** > > Hi all,**** > > ** ** > > In the identity management systems that support Role Based Access Control= , > groups/roles are assigned a set of permissions/entitlements which are > required to be synchronized across domains along with the corresponding > groups.**** > > Having an optional, multi-valued attribute as permissions/entitlements in > the group schema is useful to facilitate such requirements.**** > > ** ** > > Appreciate thoughts on this.**** > > ** ** > > Thanks,**** > > Hasini.**** > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --bcaec5314441a0727c04c9543efe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kelly,

Yes, I get your point. Usually most identity m= anagement systems support authorization management and RBAC has become comm= on.=A0
Therefore having it as an optional attribute in core-group= schema will not make any harm IMO.=A0
Currently 'entitlement' attribute is in core-user schema which= facilitate user based authorization model - which is kind of obsolete.
However, If the majority think it is not useful to have in core-grou= p schema, we can define a custom extended schema and use.

Thanks,
Hasini.

On Wed, Sep 5, = 2012 at 7:02 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com&= gt; wrote:

I agree that this is very= useful for identity management systems that provide group management and/o= r synchronization.=A0 I=92m not sure if this is generally useful for the typical SCIM consumer, so I don=92t know whether it would be bette= r placed in the core or as a standard extension.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02, 2012 4:40 AM
To: scim@ietf.org=
Subject: [scim] Proposing permissions/entitlements attribute to grou= p schema

=A0

Hi all,

=A0

In the identity management systems that support Role= Based Access Control, groups/roles are assigned a set of permissions/entit= lements which are required to be synchronized=A0across=A0domains along with= the corresponding groups.

Having an optional, multi-valued attribute as permis= sions/entitlements in the group schema is useful to facilitate such require= ments.

=A0

Appreciate thoughts on this.

=A0

Thanks,

Hasini.


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


--bcaec5314441a0727c04c9543efe-- From Chris.Phillips@canarie.ca Mon Sep 10 06:24:34 2012 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 9F0C521F862B for ; Mon, 10 Sep 2012 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ-+jNFQWtmU for ; Mon, 10 Sep 2012 06:24:33 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50221F8600 for ; Mon, 10 Sep 2012 06:24:33 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 10 Sep 2012 09:24:31 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Mon, 10 Sep 2012 09:24:34 -0400 Thread-Topic: [scim] Proposing permissions/entitlements attribute to group schema Thread-Index: Ac2PV5w9tV17YrPITVOWnvJOxAgygw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC73559BC1371chrisphillipscanarieca_" MIME-Version: 1.0 Cc: Hasini Gunasinghe , Kelly Grizzle Subject: Re: [scim] Proposing permissions/entitlements attribute to group 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: Mon, 10 Sep 2012 13:24:34 -0000 --_000_CC73559BC1371chrisphillipscanarieca_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm supportive of enhancing/decorating the group schema with additional att= ributes that are relevant to groups specifically. I see this being simila= r in function as attribute decoration in the user schema from the perspec= tive that it behaves as a container for useful information about the user. = Keeping attributes relevant and 'just enough' are still key in this contex= t though. However, if the intent behind the enhancements/attribute decorating is to i= mply or limit SCIM adopters to a single model such as 'SCIM wants RBAC' o= r 'SCIM will favour group based access control' then I would say we need to= talk this through more as I see this as a negative thing to do. I doubt this is the case though -- SCIM should be agnostic to any and all a= ccess control methodologies but have 'just enough' to minimally support com= mon ones. Another point, FWIW, entitlements are not obsolete=97 they have their place= and you may not have encountered their use/utility in your environment yet= . The environment I'm in, Research and Education federations, frequently u= se entitlements across hundreds of Service Providers world wide. With the= Canadian Access Federation dealing with 1/10th the size of higher ed & res= earchers as compared to the US we are not one of the largest data points. T= hat said, inCommon as the US R&E Fed. certainly ranks up there and has > 80= 0 Service Providers[1] alone and they are just one of 27+ federations[2]. For background, a recent R&E perspective on privilege and access management= that talks about groups,entitlements, and more can be found here[3] -- for= the TL;DR crowd, slides 23/24 may be of direct interest as this has direct= bearing on the interesting bits of schema and provisioning to the R&E comm= unity. C. [1] http://www.incommon.org/federation/info/all-entities.html [2] https://refeds.org/resources.html [3] http://www.incommon.org/docs/iamonline/IAM_Online_2012_08_08.pdf From: Hasini Gunasinghe > Date: Monday, 10 September, 2012 3:52 AM To: Kelly Grizzle > Cc: "scim@ietf.org" > Subject: Re: [scim] Proposing permissions/entitlements attribute to group s= chema Hi Kelly, Yes, I get your point. Usually most identity management systems support aut= horization management and RBAC has become common. Therefore having it as an optional attribute in core-group schema will not = make any harm IMO. Currently 'entitlement' attribute is in core-user schema which facilitate u= ser based authorization model - which is kind of obsolete. However, If the majority think it is not useful to have in core-group schem= a, we can define a custom extended schema and use. Thanks, Hasini. On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle > wrote: I agree that this is very useful for identity management systems that provi= de group management and/or synchronization. I=92m not sure if this is gene= rally useful for the typical SCIM consumer, so I don=92t know whether it wo= uld be better placed in the core or as a standard extension. --Kelly From:scim-bounces@ietf.org [mailto:scim-bounc= es@ietf.org] On Behalf Of Hasini Gunasinghe Sent: Sunday, September 02, 2012 4:40 AM To: scim@ietf.org Subject: [scim] Proposing permissions/entitlements attribute to group schem= a Hi all, In the identity management systems that support Role Based Access Control, = groups/roles are assigned a set of permissions/entitlements which are requi= red to be synchronized across domains along with the corresponding groups. Having an optional, multi-valued attribute as permissions/entitlements in t= he group schema is useful to facilitate such requirements. Appreciate thoughts on this. Thanks, Hasini. _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_CC73559BC1371chrisphillipscanarieca_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'm supportive of enhancing/dec= orating the group schema with additional attributes that are relevant to gr= oups specifically.  I see this being  similar in function as &nbs= p;attribute decoration in  the user schema from the perspective that i= t behaves as a container for useful information about the user.  Keepi= ng attributes relevant and 'just enough' are still key in this context thou= gh.

However, if the intent behind the enhancements= /attribute decorating is to imply or limit SCIM adopters to a single model = such as   'SCIM wants RBAC' or 'SCIM will favour group based access co= ntrol' then I would say we need to talk this through more as I see this as = a negative thing to do.
I doubt this is the case though -- SCIM s= hould be agnostic to any and all access control methodologies but have 'jus= t enough' to minimally support common ones.

Anothe= r point, FWIW, entitlements are not obsolete=97 they have their place and y= ou may not have encountered their use/utility in your environment yet. &nbs= p;The environment I'm in, Research and Education federations, frequently us= e entitlements across hundreds of Service Providers world wide.   With= the Canadian Access Federation dealing with 1/10th the size of higher ed &= amp; researchers as compared to the US we are not one of the largest data p= oints. That said, inCommon as the US R&E Fed. certainly ranks up there = and has > 800 Service Providers[1] alone and they are just one of 27+= ; federations[2].  

For background, a recent = R&E perspective on privilege and access management that talks about gro= ups,entitlements, and more can be found here[3] -- for the TL;DR crowd, sli= des 23/24 may be of direct interest as this has direct bearing on the inter= esting bits of schema and provisioning to the R&E community.
=
C.




From: Hasini Gunasinghe <hasini@wso2.com>
Dat= e: Monday, 10 September, 2012 3:52 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org&= quot; <scim@ietf.org>
Subject: Re: [scim] Proposing permissions= /entitlements attribute to group schema

Hi Kelly,

Yes, I get your point. Usually most identity management= systems support authorization management and RBAC has become common. =
Therefore having it as an optional attribute in core-group schem= a will not make any harm IMO. 
Currently 'entitlement' attri= bute is in core-user schema which facilitate user based authorization model= - which is kind of obsolete.
However, If the majority think it i= s not useful to have in core-group schema, we can define a custom extended = schema and use.

Thanks,
Hasini.

<= div class=3D"gmail_quote">On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle <kelly.= grizzle@sailpoint.com> wrote:

I agree that this is very useful for identity mana= gement systems that provide group management and/or synchronization.  = I=92m not sure if this is generally useful for the typical SCIM consumer, so I don=92t know whether it would be bette= r placed in the core or as a standard extension.

 

--Kelly

 

<= p class=3D"MsoNormal">From:scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02,= 2012 4:40 AM
To: scim@ietf.org
Subject: [scim] Proposing permissions/entit= lements attribute to group schema

<= p class=3D"MsoNormal"> 

Hi all= ,

 

In the identity management systems that suppo= rt Role Based Access Control, groups/roles are assigned a set of permission= s/entitlements which are required to be synchronized across domai= ns along with the corresponding groups.

Having an optional, multi-valued attribute as permissions/e= ntitlements in the group schema is useful to facilitate such requirements.<= u>

 

=

Appreciate thoughts on this.

 

<= p class=3D"MsoNormal">Thanks,

Hasini.


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


 --_000_CC73559BC1371chrisphillipscanarieca_-- From leifj@mnt.se Mon Sep 10 11:59:53 2012 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 F26D321E8090 for ; Mon, 10 Sep 2012 11:59:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0WrsE-LtD+t for ; Mon, 10 Sep 2012 11:59:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C0F8821E8063 for ; Mon, 10 Sep 2012 11:59:51 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q8AIxhnY016582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 20:59:48 +0200 (CEST) Message-ID: <504E389F.1020603@mnt.se> Date: Mon, 10 Sep 2012 20:59:43 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim chairs Subject: [scim] planning for Atlanta 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, 10 Sep 2012 18:59:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We'd like to get everyone to start to think about topics they'd like on the table for the Atlanta agenda. Send your suggestions as replies to this email, thx! Best R Leif & Morteza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBOOJsACgkQ8Jx8FtbMZndtpwCfc+NYPPWv/F+M5CkBCPF30NKf Of8AnjXR1VPpjk7Y+QBfnID2k67UoJrl =xHcE -----END PGP SIGNATURE----- From tonynad@microsoft.com Mon Sep 10 14:44:58 2012 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 EFE2221F866D for ; Mon, 10 Sep 2012 14:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAACxgvJatf6 for ; Mon, 10 Sep 2012 14:44:54 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id BA9B321F865F for ; Mon, 10 Sep 2012 14:44:53 -0700 (PDT) Received: from mail232-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 21:44:52 +0000 Received: from mail232-tx2 (localhost [127.0.0.1]) by mail232-tx2-R.bigfish.com (Postfix) with ESMTP id 900889C00D8 for ; Mon, 10 Sep 2012 21:44:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zz98dI9371Ic85fh4015I14ffIzz1202h1d1ah1082kzz1033IL17326ah8275bh8275dh5eeeKz2fh2a8h683h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail232-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail232-tx2 (localhost.localdomain [127.0.0.1]) by mail232-tx2 (MessageSwitch) id 1347313489295953_20133; Mon, 10 Sep 2012 21:44:49 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.239]) by mail232-tx2.bigfish.com (Postfix) with ESMTP id 462ABA4004B for ; Mon, 10 Sep 2012 21:44:49 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 21:44:48 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 10 Sep 2012 21:44:39 +0000 Received: from mail190-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 21:44:23 +0000 Received: from mail190-co1 (localhost [127.0.0.1]) by mail190-co1-R.bigfish.com (Postfix) with ESMTP id D87EA8C0088 for ; Mon, 10 Sep 2012 21:44:23 +0000 (UTC) Received: from mail190-co1 (localhost.localdomain [127.0.0.1]) by mail190-co1 (MessageSwitch) id 1347313461519155_18824; Mon, 10 Sep 2012 21:44:21 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.231]) by mail190-co1.bigfish.com (Postfix) with ESMTP id 79FE2B20121; Mon, 10 Sep 2012 21:44:21 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 21:44:18 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.238]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0190.008; Mon, 10 Sep 2012 21:44:17 +0000 From: Anthony Nadalin To: Chris Phillips , "scim@ietf.org" Thread-Topic: [scim] Proposing permissions/entitlements attribute to group schema Thread-Index: AQHNj1fnRdK4emz2Wk6tsQ73rm2nnZeD/B9w Date: Mon, 10 Sep 2012 21:44:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7662939E1BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CANARIE.CA$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%WSO2.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Hasini Gunasinghe , Kelly Grizzle Subject: Re: [scim] Proposing permissions/entitlements attribute to group 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: Mon, 10 Sep 2012 21:44:58 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7662939E1BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's somewhat of a rat's nest to try to universalize these assertions/attri= butes when in reality they must be evaluated from the point of view of ind= ividual relying parties. A universalized authorization fabric is infinitel= y less likely to succeed than one like OAuth which allows the user to make = these decisions on a per-resource basis and then essentially caches the res= ults. If one wanted to go beyond this it would be a matter of automating t= he user's decision-making process, not universalizing the authorization sta= tements. From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chr= is Phillips Sent: Monday, September 10, 2012 6:25 AM To: scim@ietf.org Cc: Hasini Gunasinghe; Kelly Grizzle Subject: Re: [scim] Proposing permissions/entitlements attribute to group s= chema I'm supportive of enhancing/decorating the group schema with additional att= ributes that are relevant to groups specifically. I see this being simila= r in function as attribute decoration in the user schema from the perspec= tive that it behaves as a container for useful information about the user. = Keeping attributes relevant and 'just enough' are still key in this contex= t though. However, if the intent behind the enhancements/attribute decorating is to i= mply or limit SCIM adopters to a single model such as 'SCIM wants RBAC' o= r 'SCIM will favour group based access control' then I would say we need to= talk this through more as I see this as a negative thing to do. I doubt this is the case though -- SCIM should be agnostic to any and all a= ccess control methodologies but have 'just enough' to minimally support com= mon ones. Another point, FWIW, entitlements are not obsolete- they have their place a= nd you may not have encountered their use/utility in your environment yet. = The environment I'm in, Research and Education federations, frequently use= entitlements across hundreds of Service Providers world wide. With the C= anadian Access Federation dealing with 1/10th the size of higher ed & resea= rchers as compared to the US we are not one of the largest data points. Tha= t said, inCommon as the US R&E Fed. certainly ranks up there and has > 800 = Service Providers[1] alone and they are just one of 27+ federations[2]. For background, a recent R&E perspective on privilege and access management= that talks about groups,entitlements, and more can be found here[3] -- for= the TL;DR crowd, slides 23/24 may be of direct interest as this has direct= bearing on the interesting bits of schema and provisioning to the R&E comm= unity. C. [1] http://www.incommon.org/federation/info/all-entities.html [2] https://refeds.org/resources.html [3] http://www.incommon.org/docs/iamonline/IAM_Online_2012_08_08.pdf From: Hasini Gunasinghe > Date: Monday, 10 September, 2012 3:52 AM To: Kelly Grizzle > Cc: "scim@ietf.org" > Subject: Re: [scim] Proposing permissions/entitlements attribute to group s= chema Hi Kelly, Yes, I get your point. Usually most identity management systems support aut= horization management and RBAC has become common. Therefore having it as an optional attribute in core-group schema will not = make any harm IMO. Currently 'entitlement' attribute is in core-user schema which facilitate u= ser based authorization model - which is kind of obsolete. However, If the majority think it is not useful to have in core-group schem= a, we can define a custom extended schema and use. Thanks, Hasini. On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle > wrote: I agree that this is very useful for identity management systems that provi= de group management and/or synchronization. I'm not sure if this is genera= lly useful for the typical SCIM consumer, so I don't know whether it would = be better placed in the core or as a standard extension. --Kelly From:scim-bounces@ietf.org [mailto:scim-bounc= es@ietf.org] On Behalf Of Hasini Gunasinghe Sent: Sunday, September 02, 2012 4:40 AM To: scim@ietf.org Subject: [scim] Proposing permissions/entitlements attribute to group schem= a Hi all, In the identity management systems that support Role Based Access Control, = groups/roles are assigned a set of permissions/entitlements which are requi= red to be synchronized across domains along with the corresponding groups. Having an optional, multi-valued attribute as permissions/entitlements in t= he group schema is useful to facilitate such requirements. Appreciate thoughts on this. Thanks, Hasini. _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_B26C1EF377CB694EAB6BDDC8E624B6E7662939E1BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It's somewhat of a rat's nest to try to universal= ize these assertions/attributes  when in reality they must be evaluate= d from the point of view of individual relying parties.  A universaliz= ed authorization fabric is infinitely less likely to succeed than one like OAuth which allows the user to make these decisio= ns on a per-resource basis and then essentially caches the results.  I= f one wanted to go beyond this it would be a matter of automating the user'= s decision-making process, not universalizing the authorization statements.

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips
Sent: Monday, September 10, 2012 6:25 AM
To: scim@ietf.org
Cc: Hasini Gunasinghe; Kelly Grizzle
Subject: Re: [scim] Proposing permissions/entitlements attribute to = group schema

 

I'm supportive of enhancing= /decorating the group schema with additional attributes that are relevant t= o groups specifically.  I see this being  similar in function as  attribute decoration in  the user schema from the perspectiv= e that it behaves as a container for useful information about the user. &nb= sp;Keeping attributes relevant and 'just enough' are still key in this cont= ext though.

 

However, if the intent behi= nd the enhancements/attribute decorating is to imply or limit SCIM adopters= to a single model such as   'SCIM wants RBAC' or 'SCIM will favour group based access control' then I would say we need to talk t= his through more as I see this as a negative thing to do.=

I doubt this is the case th= ough -- SCIM should be agnostic to any and all access control methodologies= but have 'just enough' to minimally support common ones.=

 

Another point, FWIW, entitl= ements are not obsolete— they have their place and you may not have e= ncountered their use/utility in your environment yet.  The environment I'm in, Research and Education federations, frequently use entitlements ac= ross hundreds of Service Providers world wide.   With the Canadian Acc= ess Federation dealing with 1/10th the size of higher ed & researchers = as compared to the US we are not one of the largest data points. That said, inCommon as the US R&E Fed. certainly = ranks up there and has > 800 Service Providers[1] alone and they are jus= t one of 27+ federations[2].  

 

For background, a recent R&= amp;E perspective on privilege and access management that talks about group= s,entitlements, and more can be found here[3] -- for the TL;DR crowd, slides 23/24 may be of direct interest as this has direct bearing o= n the interesting bits of schema and provisioning to the R&E community.=

 

C.

 

 

 

 

From: Hasini Gunasinghe <hasini@wso2.com>
Date: Monday, 10 September, 2012 3:52 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] Proposing permissions/entitlements attribute to = group schema

 

Hi Kelly,

 

Yes, I get your point. Usua= lly most identity management systems support authorization management and R= BAC has become common. 

Therefore having it as an o= ptional attribute in core-group schema will not make any harm IMO. 

Currently 'entitlement' att= ribute is in core-user schema which facilitate user based authorization mod= el - which is kind of obsolete.

However, If the majority th= ink it is not useful to have in core-group schema, we can define a custom e= xtended schema and use.

 

Thanks,

Hasini.

On Wed, Sep 5, 2012 at 7:02= PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree that this is very useful for id= entity management systems that provide group management and/or synchronization.  I’m not sure if this is generally useful for = the typical SCIM consumer, so I don’t know whether it would be better= placed in the core or as a standard extension.

 

--Kelly

 

From:scim-bounces@ie= tf.org [mailto:scim-bo= unces@ietf.org] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02, 2012 4:40 AM
To: scim@ietf.org=
Subject: [scim] Proposing permissions/entitlements attribute to grou= p schema

 

Hi all,

 

In the identity management systems tha= t support Role Based Access Control, groups/roles are assigned a set of per= missions/entitlements which are required to be synchronized across domains along with the corresponding g= roups.

Having an optional, multi-valued attri= bute as permissions/entitlements in the group schema is useful to facilitat= e such requirements.

 

Appreciate thoughts on this.

 

Thanks,

Hasini.


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

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7662939E1BL2PRD0310MB362_-- From tonynad@microsoft.com Mon Sep 10 14:46:40 2012 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 6B6CE21F867B for ; Mon, 10 Sep 2012 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=-1.899, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCURD42F5ukP for ; Mon, 10 Sep 2012 14:46:39 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id BB6B221F867A for ; Mon, 10 Sep 2012 14:46:31 -0700 (PDT) Received: from mail97-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 21:46:30 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 797F1380085 for ; Mon, 10 Sep 2012 21:46:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zz154cP9371I542Mzz1202h1d1ah1082kzz8275ch1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail97-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 1347313588418608_5051; Mon, 10 Sep 2012 21:46:28 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.249]) by mail97-am1.bigfish.com (Postfix) with ESMTP id 5B29F3A00B2 for ; Mon, 10 Sep 2012 21:46:28 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 21:46:25 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 10 Sep 2012 21:46:23 +0000 Received: from mail73-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 21:46:00 +0000 Received: from mail73-co1 (localhost [127.0.0.1]) by mail73-co1-R.bigfish.com (Postfix) with ESMTP id 2AAF54800CD for ; Mon, 10 Sep 2012 21:46:00 +0000 (UTC) Received: from mail73-co1 (localhost.localdomain [127.0.0.1]) by mail73-co1 (MessageSwitch) id 1347313558473083_1321; Mon, 10 Sep 2012 21:45:58 +0000 (UTC) Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.233]) by mail73-co1.bigfish.com (Postfix) with ESMTP id 6F9FA580042; Mon, 10 Sep 2012 21:45:58 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 21:45:54 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.238]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0190.008; Mon, 10 Sep 2012 21:45:53 +0000 From: Anthony Nadalin To: Leif Johansson , scim WG Thread-Topic: [scim] planning for Atlanta Thread-Index: AQHNj4bB7PzXOA1c4kyF9U4RPvMWnZeEG9uQ Date: Mon, 10 Sep 2012 21:45:52 +0000 Message-ID: References: <504E389F.1020603@mnt.se> In-Reply-To: <504E389F.1020603@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: scim chairs Subject: Re: [scim] planning for Atlanta 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, 10 Sep 2012 21:46:40 -0000 1. use cases 2. authorization 3. attributes (default/optional) 4. metadata on objects -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Monday, September 10, 2012 12:00 PM To: scim WG Cc: scim chairs Subject: [scim] planning for Atlanta -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We'd like to get everyone to start to think about topics they'd like on the= table for the Atlanta agenda. Send your suggestions as replies to this ema= il, thx! Best R Leif & Morteza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBOOJsACgkQ8Jx8FtbMZndtpwCfc+NYPPWv/F+M5CkBCPF30NKf Of8AnjXR1VPpjk7Y+QBfnID2k67UoJrl =3DxHcE -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From hasini@wso2.com Mon Sep 10 21:26:01 2012 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 48D5821E803D for ; Mon, 10 Sep 2012 21:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIcuhgbpsrCQ for ; Mon, 10 Sep 2012 21:26:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5DDD21E803F for ; Mon, 10 Sep 2012 21:25:59 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so99688vbb.31 for ; Mon, 10 Sep 2012 21:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TJE+mWZRXl9XwJrUwSA+wMMI442R37x1v1txClzg9VU=; b=Kvbb8SxuvIU0/gBAztUHtTIZZlj+IZRDF9ExDaPcl2auLa7j3I0MdKwF4ZhUzKUvUp iCU7QHFxGuHXyIMxwkEBsUXyoz2VxPYljgG0URDuPBeyS/eJLGNKiApUp5HO6mq7XE+o paqkW13TU1iSF8Dik8rN3UPoWGUS1dO+bR5jZdCBRODHV2dzwbOztwULt7EiV9lXF0Cg JicmcbxV02ap6MSU4tzgcm5CW6E25lJiv6Te7Zyto64sto+cj1llt12KE3k9tU2gq4Vp muYwo0h0R+lByp0VLsB1oli926KKE3loyRX4c6l/YR6gonW4W5eA7GpG/koC+VpikbXh NIog== MIME-Version: 1.0 Received: by 10.220.142.79 with SMTP id p15mr23302000vcu.24.1347337559118; Mon, 10 Sep 2012 21:25:59 -0700 (PDT) Received: by 10.58.124.101 with HTTP; Mon, 10 Sep 2012 21:25:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Sep 2012 09:55:58 +0530 Message-ID: From: Hasini Gunasinghe To: Chris Phillips Content-Type: multipart/alternative; boundary=f46d042fdb3e9a941a04c965788b X-Gm-Message-State: ALoCoQk/0s4gDIFL0p2R3zIZfrpPDPkt+VVYK9Xdolpe9LZJACnVAoc/v+WxJc5LKoO9tndZ9NVY Cc: "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] Proposing permissions/entitlements attribute to group 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: Tue, 11 Sep 2012 04:26:01 -0000 --f46d042fdb3e9a941a04c965788b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2012 at 6:54 PM, Chris Phillips wrote: > I'm supportive of enhancing/decorating the group schema with additional > attributes that are relevant to groups specifically. I see this being > similar in function as attribute decoration in the user schema from th= e > perspective that it behaves as a container for useful information about t= he > user. Keeping attributes relevant and 'just enough' are still key in thi= s > context though. > I'm +1 for keeping the attributes relevant and 'just enough' to make the schema simple. > > However, if the intent behind the enhancements/attribute decorating is to > imply or limit SCIM adopters to a single model such as 'SCIM wants RBAC= ' > or 'SCIM will favour group based access control' then I would say we need > to talk this through more as I see this as a negative thing to do. > I doubt this is the case though -- SCIM should be agnostic to any and all > access control methodologies but have 'just enough' to minimally support > common ones. > I might have not been clear in my previous mails. Proposing entitlements/permission attribute to Group schema is NOT to motivate that SCIM supports/favour RBAC at all. Of course, access control is out of scope of SCIM and why I proposed it was, it would facilitate an Identity Management System to synchronize group management(which manages entitlements of groups) through SCIM if we have this attribute. And I believe it will be a common requirement for many Identity Management Systems. > > Another point, FWIW, entitlements are not obsolete=97 they have their pla= ce > and you may not have encountered their use/utility in your environment ye= t. > The environment I'm in, Research and Education federations, frequently u= se > entitlements across hundreds of Service Providers world wide. > > Well, I didn't mean that entitlements are obsolete. What I mentioned in my previous mail was user-centric access control model (for which the 'entitlement' attribute in User schema is mostly useful for) is obsolete because it doesn't really scale when the number of users grow. And several alternative models have become popular among which RBAC, ABAC and PBAC with XACML are some of them to mention. Thanks, Hasini. With the Canadian Access Federation dealing with 1/10th the size of higher > ed & researchers as compared to the US we are not one of the largest data > points. That said, inCommon as the US R&E Fed. certainly ranks up there a= nd > has > 800 Service Providers[1] alone and they are just one of 27+ > federations[2]. > > For background, a recent R&E perspective on privilege and access > management that talks about groups,entitlements, and more can be found > here[3] -- for the TL;DR crowd, slides 23/24 may be of direct interest as > this has direct bearing on the interesting bits of schema and provisionin= g > to the R&E community. > > C. > > > [1] http://www.incommon.org/federation/info/all-entities.html > [2] https://refeds.org/resources.html > [3] http://www.incommon.org/docs/iamonline/IAM_Online_2012_08_08.pdf > > > From: Hasini Gunasinghe > Date: Monday, 10 September, 2012 3:52 AM > To: Kelly Grizzle > Cc: "scim@ietf.org" > Subject: Re: [scim] Proposing permissions/entitlements attribute to group > schema > > Hi Kelly, > > Yes, I get your point. Usually most identity management systems support > authorization management and RBAC has become common. > Therefore having it as an optional attribute in core-group schema will no= t > make any harm IMO. > Currently 'entitlement' attribute is in core-user schema which facilitate > user based authorization model - which is kind of obsolete. > However, If the majority think it is not useful to have in core-group > schema, we can define a custom extended schema and use. > > Thanks, > Hasini. > > On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle > wrote: > >> I agree that this is very useful for identity management systems that >> provide group management and/or synchronization. I=92m not sure if this= is >> generally useful for the typical SCIM consumer, so I don=92t know whethe= r it >> would be better placed in the core or as a standard extension.**** >> >> ** ** >> >> --Kelly**** >> >> ** ** >> >> *From:*scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Hasini Gunasinghe >> *Sent:* Sunday, September 02, 2012 4:40 AM >> *To:* scim@ietf.org >> *Subject:* [scim] Proposing permissions/entitlements attribute to group >> schema**** >> >> ** ** >> >> Hi all,**** >> >> ** ** >> >> In the identity management systems that support Role Based Access >> Control, groups/roles are assigned a set of permissions/entitlements whi= ch >> are required to be synchronized across domains along with the correspond= ing >> groups.**** >> >> Having an optional, multi-valued attribute as permissions/entitlements i= n >> the group schema is useful to facilitate such requirements.**** >> >> ** ** >> >> Appreciate thoughts on this.**** >> >> ** ** >> >> Thanks,**** >> >> Hasini.**** >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > --f46d042fdb3e9a941a04c965788b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 10, 2012 at 6:54 PM, Chris Phill= ips <Chris.Phillips@canarie.ca> wrote:
I'm supportive of enhancing/decorating the group schema wit= h additional attributes that are relevant to groups specifically. =A0I see = this being =A0similar in function as =A0attribute decoration in =A0the user= schema from the perspective that it behaves as a container for useful info= rmation about the user. =A0Keeping attributes relevant and 'just enough= ' are still key in this context though.

I'm +1 for keeping the attribute= s relevant and 'just enough' to make the schema simple.

However, if the intent behind the enhancements/a= ttribute decorating is to imply or limit SCIM adopters to a single model su= ch as =A0 'SCIM wants RBAC' or 'SCIM will favour group based ac= cess control' then I would say we need to talk this through more as I s= ee this as a negative thing to do.
I doubt this is the case though -- SCIM should be agnostic to any and = all access control methodologies but have 'just enough' to minimall= y support common ones.
=A0
I might h= ave not been clear in my previous mails. Proposing entitlements/permission = attribute to Group schema is NOT to motivate that SCIM supports/favour RBAC= at all. Of course, access control is out of scope of SCIM and why I propos= ed it was, it would facilitate an Identity Management System to synchronize= group management(which manages entitlements of groups) through SCIM if we = have this attribute. And I believe it will be a common requirement for many= Identity Management Systems.

Another point, FW= IW, entitlements are not obsolete=97 they have their place and you may not = have encountered their use/utility in your environment yet. =A0The environm= ent I'm in, Research and Education federations, frequently use entitlem= ents across hundreds of Service Providers world wide.
=A0=A0
<= /div>
Well, I didn't mean that entitlements are obsolete. What I mention= ed in my previous mail was user-centric access control model (for which the= 'entitlement' attribute in User schema is mostly useful for) is ob= solete because it doesn't really scale when the number of users grow. A= nd several alternative models have become popular among which RBAC, ABAC an= d PBAC with XACML are some of them to mention.

Thanks,
Hasini.

With the Canadian Access Federation dealing with 1/10th the size of hi= gher ed & researchers as compared to the US we are not one of the large= st data points. That said, inCommon as the US R&E Fed. certainly ranks = up there and has > 800 Service Providers[1] alone and they are just one = of 27+ federations[2]. =A0

For background, a recent R&E perspective on privile= ge and access management that talks about groups,entitlements, and more can= be found here[3] -- for the TL;DR crowd, slides 23/24 may be of direct int= erest as this has direct bearing on the interesting bits of schema and prov= isioning to the R&E community.

C.


<= div> [2]=A0https= ://refeds.org/resources.html


From: Hasini Gunasinghe <hasini@wso2.com>
<= span style=3D"font-weight:bold">Date: Monday, 10 September, 2012 3:= 52 AM
To: Kelly Grizzle <kelly.grizzle@sailpoin= t.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Proposing perm= issions/entitlements attribute to group schema

Hi Kelly,

Yes, I get your point. Usually most identity management= systems support authorization management and RBAC has become common.=A0
Therefore having it as an optional attribute in core-group schema w= ill not make any harm IMO.=A0
Currently 'entitlement' attribute is in core-user schema which= facilitate user based authorization model - which is kind of obsolete.
However, If the majority think it is not useful to have in core-grou= p schema, we can define a custom extended schema and use.

Thanks,
Hasini.

On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle <kelly.= grizzle@sailpoint.com> wrote:

I agree that this is very useful for identity management system= s that provide group management and/or synchronization.=A0 I=92m not sure i= f this is generally useful for the typical SCIM consumer, so I don=92t know whether it would be bette= r placed in the core or as a standard extension.

=A0

--Kelly

=A0

From:scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02,= 2012 4:40 AM
To: scim@ietf.org
Subject: [scim] Proposing permissions/entit= lements attribute to group schema

=A0

Hi all,

=A0<= /u>

In the identity management systems= that support Role Based Access Control, groups/roles are assigned a set of= permissions/entitlements which are required to be synchronized=A0across=A0= domains along with the corresponding groups.

Having an optional, multi-valued attribut= e as permissions/entitlements in the group schema is useful to facilitate s= uch requirements.

=A0

Appreciate thoughts on this.

=A0

Thanks,

Hasini.


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



--f46d042fdb3e9a941a04c965788b-- From olds@rbcon.com Tue Sep 11 18:27:56 2012 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 6457A21F869C for ; Tue, 11 Sep 2012 18:27:56 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmK5UECRei1N for ; Tue, 11 Sep 2012 18:27:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B47E121F860D for ; Tue, 11 Sep 2012 18:27:55 -0700 (PDT) Received: by iabz21 with SMTP id z21so981052iab.31 for ; Tue, 11 Sep 2012 18:27:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=4y4tVm09SN7N/kpSY3X6e9IR8JHBZyJ74LM5YHjbsbA=; b=VIXjHHEBBroCChBdJYHtz7wBCdetc7V4GjEhE22wG12ibdjWqFvG7UA52LVjhL9yAq j8njhMriWcIRNDYfDNfJsQzfKjs+BtpMoZPRCbUt5CEZTtZryTjLZOIbfUudfn8aX7sz iBePoC1g9Q4fqEQG5kfpljmQyVkiprtlnl+8GAeD8AO2bSu4T/Nd3U5wltmhT27ooijW 7SGq7irvX4j5dQXl6W6Tyce+w/CEtd/LqO/iugAGFtMwQuP3JkdZzOA28GVeMQGHIbKh UZOQ2GyOZX1P0Z5uERtHU75QtrFCRzroZl6esoQx//98FNU3I3DxL9EWyL5kbGO/nE4u k2og== Received: by 10.50.36.167 with SMTP id r7mr24117igj.9.1347413273863; Tue, 11 Sep 2012 18:27:53 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id nh1sm3533583igc.11.2012.09.11.18.27.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 18:27:53 -0700 (PDT) Message-ID: <504FE517.60508@rbcon.com> Date: Tue, 11 Sep 2012 18:27:51 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: multipart/alternative; boundary="------------050701000001020207090500" X-Gm-Message-State: ALoCoQn5mYp2dh83iW4mYZPB9fuLxMuEuYJMbqXl8jvluOesgWCzqSs2ydnPlvON5e5CwLa4x99A Subject: [scim] case preserving vs case insensitive 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, 12 Sep 2012 01:27:56 -0000 This is a multi-part message in MIME format. --------------050701000001020207090500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit from my reading, the scim specs are very clear about case-sensitivity issues. For example, there is this paragraph in the API doc, section 3.2.2.1: "String type attributes are case insensitive by default unless the attribute type is defined as a caseExact string. Attribute operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching for all string attributes unless the attribute is defined as caseExact. By default all string attributes are caseIgnore." However, I have not been able to find anything which indicates whether attribute values should be case-preserving -- unless perhaps there is something relevant in the XML Schema Datatypes Specification referred to in the schema doc. I would think there would be something about it in the API doc for creating or updating resources. Personally, I don't remember using a case-insensitive, non-case-preserving system since DOS 8.3 file names, but it has come up in our implementation. Has this been discussed and does the WG have rough consensus about this? My preference would be to specify case-preservation for case-insensitive attributes. I think it's the most useful option, and then we could rely on it as we cross system domains. It would be inconvenient for a SCIM service to magically modify data passed into it. --Dale --------------050701000001020207090500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit from my reading, the scim specs are very clear about case-sensitivity issues. For example, there is this paragraph in the API doc, section 3.2.2.1:

"String type attributes are case insensitive by default unless the attribute type is defined as a caseExact string. Attribute operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching for all string attributes unless the attribute is defined as caseExact. By default all string attributes are caseIgnore."

However, I have not been able to find anything which indicates whether attribute values should be case-preserving -- unless perhaps there is something relevant in the XML Schema Datatypes Specification referred to in the schema doc. I would think there would be something about it in the API doc for creating or updating resources.

Personally, I don't remember using a case-insensitive, non-case-preserving system since DOS 8.3 file names, but it has come up in our implementation.

Has this been discussed and does the WG have rough consensus about this?

My preference would be to specify case-preservation for case-insensitive attributes. I think it's the most useful option, and then we could rely on it as we cross system domains. It would be inconvenient for a SCIM service to magically modify data passed into it.

--Dale

 --------------050701000001020207090500-- From olds@rbcon.com Tue Sep 11 18:51:18 2012 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 1811D21E804A for ; Tue, 11 Sep 2012 18:51:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl9k7H0wX5xv for ; Tue, 11 Sep 2012 18:51:17 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F17F421E8042 for ; Tue, 11 Sep 2012 18:51:10 -0700 (PDT) Received: by ieak13 with SMTP id k13so2252189iea.31 for ; Tue, 11 Sep 2012 18:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=4RjH6Zi/Y0hcSwFH8AULn/Q+r3/bdJLWlwNE/zVK9hU=; b=N81i3jMKKnA0hdSLv3cE0dDQwYE+AGWzpdfg6eRvLz0mvbRZnz6z6bkNAmvyIxKGon OfX4Wp57L+SK0C76DzQ0bco7pkeWdD+kIDfFpEUNDhLtsqiOVxXtUKijsF2wFqsefjrV jfNns4p7ZVF3pQKtO1LDwsjKidII4VUQ7Px13CdW9Lt2IhIjb2hpB8lJ9wPKm3zCr1iQ R6GEel6hETZR7JuitiVw8y97PqiUm1Owiv5XMxY863p6CDtChnumicOKR4Y3EwUB8+La G6KnvPEz+K3S3FWVyDakBLoYqk4Bq9EJXFz5xga6IY7wlyHPGPMuar8j0rTBwu5rLS4Q ZORQ== Received: by 10.50.160.228 with SMTP id xn4mr24051506igb.1.1347414669749; Tue, 11 Sep 2012 18:51:09 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id wg9sm3963969igb.0.2012.09.11.18.51.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 18:51:09 -0700 (PDT) Message-ID: <504FEA8B.5050505@rbcon.com> Date: Tue, 11 Sep 2012 18:51:07 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: multipart/alternative; boundary="------------090202000603090506040107" X-Gm-Message-State: ALoCoQkRSkeXS9wQfppKy2ZZ+//f+4OhZO0deWApPGalyJn/dbI38gZZ5MNDigwQ8Ix/WVRZ+grV Subject: [scim] evaluating filters: true, false, and undefined 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, 12 Sep 2012 01:51:18 -0000 This is a multi-part message in MIME format. --------------090202000603090506040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit section 3.2.2.1 of the API doc describes filtering expressions and bindings. It is very clear about what should happen if an operator is not defined (the example is 'regex'), but I do not see anything which explicitly states what happens if an attribute in the expression is not defined. The closest statement is in the first paragraph: "The expression language that is used in the filter parameter supports references to attributes and literals." I suppose that could mean a reference to an unknown attribute is not supported, but it doesn't really say that, and it doesn't say undefined attributes are an error. In filtering code for similar systems I've seen implementations that did not require attributes to be defined. This can be quite natural but does make the implementation more interesting. Consider this filter of rooms: True if contains someone with hat size > 7 or wearing a read shirt. There may not be anyone wearing a hat in any room, but it would still find rooms with red shirts. IOW, it only takes one true component of an 'or' expression to make it true, even if one of the components is undefined. "True if someone with foobar > 7 or wearing a read shirt" works just as well. This is not a big issue for us, we're just checking out implementation options. What do most implementations currently do? --Dale --------------090202000603090506040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit section 3.2.2.1 of the API doc describes filtering expressions and bindings. It is very clear about what should happen if an operator is not defined (the example is 'regex'), but I do not see anything which explicitly states what happens if an attribute in the expression is not defined. The closest statement is in the first paragraph: "The expression language that is used in the filter parameter supports references to attributes and literals." I suppose that could mean a reference to an unknown attribute is not supported, but it doesn't really say that, and it doesn't say undefined attributes are an error.

In filtering code for similar systems I've seen implementations that did not require attributes to be defined. This can be quite natural but does make the implementation more interesting. Consider this filter of rooms:

True if contains someone with hat size > 7 or wearing a read shirt.

There may not be anyone wearing a hat in any room, but it would still find rooms with red shirts. IOW, it only takes one true component of an 'or' expression to make it true, even if one of the components is undefined.

"True if someone with foobar > 7 or wearing a read shirt" works just as well.

This is not a big issue for us, we're just checking out implementation options. What do most implementations currently do?

--Dale





--------------090202000603090506040107-- From samuel@erdtman.se Tue Sep 11 23:01:52 2012 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 5C8C021F84F8 for ; Tue, 11 Sep 2012 23:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpJT0+HuBtWF for ; Tue, 11 Sep 2012 23:01:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 956F421F84DE for ; Tue, 11 Sep 2012 23:01:51 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1827668vbb.31 for ; Tue, 11 Sep 2012 23:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=evyWQlZ46gnTcD23q+Mg79hT3M42hlr6Znbkc//OdeU=; b=CHK+8iXlICV6vdjwqs4N6pOSUil/U7S+dqUnakaPtdCRVnznfdyxsTNynFnO/bQHeU IlSzo+ve2/mvvlMKkzctpVaO22RkwF+79dUIG7OdNEgR0O/U1UZZXsSaTxuaAHtdetNY NMCeCu7bS1m1KLvP+KjDcWykRzlz4X0jf7fm4RLa/dN7Ro9yKla87Ps93/76jBXCGKj0 8nGex/Kn8ovyLk0VuXKyenA4ZULj7npPU5aMaOzWSgQO5A6TYhI4srKH74QYgk3NP4C/ 1DMcOaRPx/VkbaDhE6EG9q/vvdGKkoUqRGHTTIBAUURJKqdUoMk0TKVhknig+Nc6yYuj q7qw== MIME-Version: 1.0 Received: by 10.58.65.40 with SMTP id u8mr30505477ves.47.1347429710684; Tue, 11 Sep 2012 23:01:50 -0700 (PDT) Received: by 10.220.127.70 with HTTP; Tue, 11 Sep 2012 23:01:50 -0700 (PDT) In-Reply-To: <504FE517.60508@rbcon.com> References: <504FE517.60508@rbcon.com> Date: Wed, 12 Sep 2012 08:01:50 +0200 Message-ID: From: Samuel Erdtman To: Dale Olds Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmQiEHkOWN4SAITNKt74hD0o7wjkC5gqEwYtKuPSKjM48buzh4qouDuQvMrlPmppni96Koy Cc: "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 06:01:52 -0000 As far as I can remember we have not discussed case-preservation. I agree that it should be specified how to handle it. have I understod you correctly with these two statements: * Case-sensitive attributes must preserve case. * Case-insensitive attributes may not preserve case if explicitly stated, in similarly fashion as case-sensitivity is specified, otherwise case must be preserved. Regards //Samuel On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: > from my reading, the scim specs are very clear about case-sensitivity > issues. For example, there is this paragraph in the API doc, section > 3.2.2.1: > > "String type attributes are case insensitive by default unless the attribute > type is defined as a caseExact string. Attribute operators 'eq', 'co', and > 'sw' MUST perform caseIgnore matching for all string attributes unless the > attribute is defined as caseExact. By default all string attributes are > caseIgnore." > > However, I have not been able to find anything which indicates whether > attribute values should be case-preserving -- unless perhaps there is > something relevant in the XML Schema Datatypes Specification referred to in > the schema doc. I would think there would be something about it in the API > doc for creating or updating resources. > > Personally, I don't remember using a case-insensitive, non-case-preserving > system since DOS 8.3 file names, but it has come up in our implementation. > > Has this been discussed and does the WG have rough consensus about this? > > My preference would be to specify case-preservation for case-insensitive > attributes. I think it's the most useful option, and then we could rely on > it as we cross system domains. It would be inconvenient for a SCIM service > to magically modify data passed into it. > > --Dale > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From samuel@erdtman.se Tue Sep 11 23:21:59 2012 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 D74FB21F85A7 for ; Tue, 11 Sep 2012 23:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaXysfKsxY6S for ; Tue, 11 Sep 2012 23:21:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8121F85AE for ; Tue, 11 Sep 2012 23:21:57 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1843961vbb.31 for ; Tue, 11 Sep 2012 23:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T9AGm4xfvVzHwnpP8tPSsYLAOPtGAIp3xMNK3SiTRfs=; b=CIDDFKf/k8o/Jsx4brKtD5TW/LbCxhZR5MLYsFl/aFO5vEvwzxF8+WfmBbTkQX8j31 nz+u1wcgJlTITFjEbLt7uAP397zi3aqD3sy2ht979J8CQJNmZTKYw8qtZ2nNF+Non2rA 7Rwx7HlzgnBqa0vXPNINC9jHuldmRS4BQUmrglEIY7HIXf9/EZ+flGX/rgNOKOzp3nPf nupkk1d5i956GdfsEw2ORLHbGvLpOEn2xZdPwK9Ac1YyYZUUJQovguStZXBV05mQwX9u 3t5Dc5Eg1U4X0D9QUndFZE1/RKGBoeN7+BbrXa+W7Uhahsnw4xzAReGM9Yt+gGNTo1pL Dz6A== MIME-Version: 1.0 Received: by 10.58.4.33 with SMTP id h1mr30682063veh.38.1347430917206; Tue, 11 Sep 2012 23:21:57 -0700 (PDT) Received: by 10.220.127.70 with HTTP; Tue, 11 Sep 2012 23:21:57 -0700 (PDT) In-Reply-To: <504FEA8B.5050505@rbcon.com> References: <504FEA8B.5050505@rbcon.com> Date: Wed, 12 Sep 2012 08:21:57 +0200 Message-ID: From: Samuel Erdtman To: Dale Olds Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnrdknwjvRaANERSIqfTu93N86VL520XuvEQ9HW1+uEirDVgdkvycOhLABTBi4VCsj6fa8z Cc: "scim@ietf.org" Subject: Re: [scim] evaluating filters: true, false, and undefined 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, 12 Sep 2012 06:21:59 -0000 In the scimproxy we will probably do it by interpreting undefined as false i.e. the statements would be evaluated as you describe it. However currently we only support one filter operation i.e. no 'and' 'or' stuff yet. Have actually not tested much filtering during the interops. If you would want to require foobar to be precent before evaluating rest of the expression you could state it as folows: ?filter=PR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means present i.e. not undefined) Regards //Samuel On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: > section 3.2.2.1 of the API doc describes filtering expressions and bindings. > It is very clear about what should happen if an operator is not defined (the > example is 'regex'), but I do not see anything which explicitly states what > happens if an attribute in the expression is not defined. The closest > statement is in the first paragraph: "The expression language that is used > in the filter parameter supports references to attributes and literals." I > suppose that could mean a reference to an unknown attribute is not > supported, but it doesn't really say that, and it doesn't say undefined > attributes are an error. > > In filtering code for similar systems I've seen implementations that did not > require attributes to be defined. This can be quite natural but does make > the implementation more interesting. Consider this filter of rooms: > > True if contains someone with hat size > 7 or wearing a read shirt. > > There may not be anyone wearing a hat in any room, but it would still find > rooms with red shirts. IOW, it only takes one true component of an 'or' > expression to make it true, even if one of the components is undefined. > > "True if someone with foobar > 7 or wearing a read shirt" works just as > well. > > This is not a big issue for us, we're just checking out implementation > options. What do most implementations currently do? > > --Dale > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From stpeter@stpeter.im Wed Sep 12 08:09:56 2012 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 C15CA21F855E for ; Wed, 12 Sep 2012 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq+WRE1v8hdN for ; Wed, 12 Sep 2012 08:09:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF121F854C for ; Wed, 12 Sep 2012 08:09:55 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C0BA40D96; Wed, 12 Sep 2012 09:10:37 -0600 (MDT) Message-ID: <5050986B.9010706@stpeter.im> Date: Wed, 12 Sep 2012 08:12:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Samuel Erdtman References: <504FE517.60508@rbcon.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Dale Olds , "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 15:09:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hate to say the dreaded word "internationalization", but if we're talking about comparison of strings then there's much more involved here than case. If we avoid comparison and just pass strings around as a series of octets then we're probably safe... On 9/12/12 12:01 AM, Samuel Erdtman wrote: > As far as I can remember we have not discussed case-preservation. > > I agree that it should be specified how to handle it. have I > understod you correctly with these two statements: * Case-sensitive > attributes must preserve case. * Case-insensitive attributes may > not preserve case if explicitly stated, in similarly fashion as > case-sensitivity is specified, otherwise case must be preserved. > > Regards //Samuel > > > On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >> from my reading, the scim specs are very clear about >> case-sensitivity issues. For example, there is this paragraph in >> the API doc, section 3.2.2.1: >> >> "String type attributes are case insensitive by default unless >> the attribute type is defined as a caseExact string. Attribute >> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >> for all string attributes unless the attribute is defined as >> caseExact. By default all string attributes are caseIgnore." >> >> However, I have not been able to find anything which indicates >> whether attribute values should be case-preserving -- unless >> perhaps there is something relevant in the XML Schema Datatypes >> Specification referred to in the schema doc. I would think there >> would be something about it in the API doc for creating or >> updating resources. >> >> Personally, I don't remember using a case-insensitive, >> non-case-preserving system since DOS 8.3 file names, but it has >> come up in our implementation. >> >> Has this been discussed and does the WG have rough consensus >> about this? >> >> My preference would be to specify case-preservation for >> case-insensitive attributes. I think it's the most useful option, >> and then we could rely on it as we cross system domains. It would >> be inconvenient for a SCIM service to magically modify data >> passed into it. >> >> --Dale >> >> >> _______________________________________________ scim mailing >> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI =BJel -----END PGP SIGNATURE----- From igor.faynberg@alcatel-lucent.com Wed Sep 12 09:15:13 2012 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 33A4821F862B for ; Wed, 12 Sep 2012 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpjiaYNHSLKj for ; Wed, 12 Sep 2012 09:15:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C021F84EE for ; Wed, 12 Sep 2012 09:15:11 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q8CGF9K2000337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Sep 2012 11:15:09 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q8CGF9Bu010289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Sep 2012 11:15:09 -0500 Received: from [135.244.176.182] (faynberg.lra.lucent.com [135.244.176.182]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q8CGF7ih023108; Wed, 12 Sep 2012 11:15:08 -0500 (CDT) Message-ID: <5050B50A.8010502@alcatel-lucent.com> Date: Wed, 12 Sep 2012 12:15:06 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> In-Reply-To: <5050986B.9010706@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [scim] case preserving vs case insensitive X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:15:13 -0000 A very good point! Igor On 9/12/2012 10:12 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I hate to say the dreaded word "internationalization", but if we're > talking about comparison of strings then there's much more involved > here than case. If we avoid comparison and just pass strings around as > a series of octets then we're probably safe... > > On 9/12/12 12:01 AM, Samuel Erdtman wrote: >> As far as I can remember we have not discussed case-preservation. >> >> I agree that it should be specified how to handle it. have I >> understod you correctly with these two statements: * Case-sensitive >> attributes must preserve case. * Case-insensitive attributes may >> not preserve case if explicitly stated, in similarly fashion as >> case-sensitivity is specified, otherwise case must be preserved. >> >> Regards //Samuel >> >> >> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>> from my reading, the scim specs are very clear about >>> case-sensitivity issues. For example, there is this paragraph in >>> the API doc, section 3.2.2.1: >>> >>> "String type attributes are case insensitive by default unless >>> the attribute type is defined as a caseExact string. Attribute >>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>> for all string attributes unless the attribute is defined as >>> caseExact. By default all string attributes are caseIgnore." >>> >>> However, I have not been able to find anything which indicates >>> whether attribute values should be case-preserving -- unless >>> perhaps there is something relevant in the XML Schema Datatypes >>> Specification referred to in the schema doc. I would think there >>> would be something about it in the API doc for creating or >>> updating resources. >>> >>> Personally, I don't remember using a case-insensitive, >>> non-case-preserving system since DOS 8.3 file names, but it has >>> come up in our implementation. >>> >>> Has this been discussed and does the WG have rough consensus >>> about this? >>> >>> My preference would be to specify case-preservation for >>> case-insensitive attributes. I think it's the most useful option, >>> and then we could rely on it as we cross system domains. It would >>> be inconvenient for a SCIM service to magically modify data >>> passed into it. >>> >>> --Dale >>> >>> >>> _______________________________________________ scim mailing >>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd > JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI > =BJel > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Sep 12 10:14:25 2012 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 5EE1021F8578 for ; Wed, 12 Sep 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G7OPswfyWhZ for ; Wed, 12 Sep 2012 10:14:22 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id D449621F8574 for ; Wed, 12 Sep 2012 10:14:21 -0700 (PDT) Received: from mail190-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Sep 2012 17:14:20 +0000 Received: from mail190-tx2 (localhost [127.0.0.1]) by mail190-tx2-R.bigfish.com (Postfix) with ESMTP id EC20F300153; Wed, 12 Sep 2012 17:14:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zzbb2dI98dI154cP9371I542M1432Id6eahzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail190-tx2: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail190-tx2 (localhost.localdomain [127.0.0.1]) by mail190-tx2 (MessageSwitch) id 1347470058429349_14152; Wed, 12 Sep 2012 17:14:18 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.247]) by mail190-tx2.bigfish.com (Postfix) with ESMTP id 5B4F32C0053; Wed, 12 Sep 2012 17:14:18 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Sep 2012 17:14:17 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.140]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0190.008; Wed, 12 Sep 2012 17:14:16 +0000 From: Kelly Grizzle To: Peter Saint-Andre , Samuel Erdtman Thread-Topic: [scim] case preserving vs case insensitive Thread-Index: AQHNkIXZtjAQLzd9VEyx27Dl0HS+7peGNycAgACJOoCAADDAQA== Date: Wed, 12 Sep 2012 17:14:15 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330EB7F2@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> In-Reply-To: <5050986B.9010706@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: Dale Olds , "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 17:14:25 -0000 +1 for always preserving case. JSON (which seems likely to become the only representation for SCIM) uses U= nicode characters for strings. This would handle the i18n requirements. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Wednesday, September 12, 2012 9:13 AM To: Samuel Erdtman Cc: Dale Olds; scim@ietf.org Subject: Re: [scim] case preserving vs case insensitive -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hate to say the dreaded word "internationalization", but if we're talking= about comparison of strings then there's much more involved here than case= . If we avoid comparison and just pass strings around as a series of octets= then we're probably safe... On 9/12/12 12:01 AM, Samuel Erdtman wrote: > As far as I can remember we have not discussed case-preservation. >=20 > I agree that it should be specified how to handle it. have I understod=20 > you correctly with these two statements: * Case-sensitive attributes=20 > must preserve case. * Case-insensitive attributes may not preserve=20 > case if explicitly stated, in similarly fashion as case-sensitivity is=20 > specified, otherwise case must be preserved. >=20 > Regards //Samuel >=20 >=20 > On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >> from my reading, the scim specs are very clear about case-sensitivity=20 >> issues. For example, there is this paragraph in the API doc, section=20 >> 3.2.2.1: >>=20 >> "String type attributes are case insensitive by default unless the=20 >> attribute type is defined as a caseExact string. Attribute operators=20 >> 'eq', 'co', and 'sw' MUST perform caseIgnore matching for all string=20 >> attributes unless the attribute is defined as caseExact. By default=20 >> all string attributes are caseIgnore." >>=20 >> However, I have not been able to find anything which indicates=20 >> whether attribute values should be case-preserving -- unless perhaps=20 >> there is something relevant in the XML Schema Datatypes Specification=20 >> referred to in the schema doc. I would think there would be something=20 >> about it in the API doc for creating or updating resources. >>=20 >> Personally, I don't remember using a case-insensitive,=20 >> non-case-preserving system since DOS 8.3 file names, but it has come=20 >> up in our implementation. >>=20 >> Has this been discussed and does the WG have rough consensus about=20 >> this? >>=20 >> My preference would be to specify case-preservation for=20 >> case-insensitive attributes. I think it's the most useful option, and=20 >> then we could rely on it as we cross system domains. It would be=20 >> inconvenient for a SCIM service to magically modify data passed into=20 >> it. >>=20 >> --Dale >>=20 >>=20 >> _______________________________________________ scim mailing list=20 >> scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI =3DBJel -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From olds@rbcon.com Wed Sep 12 10:50:03 2012 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 E2CBF21F8564 for ; Wed, 12 Sep 2012 10:50:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akXRiX5xDaDm for ; Wed, 12 Sep 2012 10:50:03 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4021F853D for ; Wed, 12 Sep 2012 10:50:02 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2655717pbb.31 for ; Wed, 12 Sep 2012 10:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=K3AukNjPmQDPOCoMAzDCK8k8yBrbHW9Zb5tmI9jXSt8=; b=QOOXDS/xdFsYCQCvP1r4xE4zFBFx2aUXAdgSFl966FiAog5n15E1KrktwjOoNcfNJm 4HHKFekDX5c0/JjNAKhRqHHDaV05roUvZLIiGhqEJR+C+N1DDxKfgQCO522tZk80S/V5 uPscJfIXatX/r7sUPvcLu2CazZjZCx2T8JhT6g02DtfdJk5App2revS2yMlVcl0xvulY sPoXin0WFJICcftNo3lSrRYHTwBeMqUqYHMCmAFINdIuH4MwYVDnKALd6eArtnG35jvA wSDu6MLI8dv28YHn1B31dNLXOybCOlcoT0YFD22jiTVrMaDvzVlo9OXiBcFB8CdAbKtk PvRw== Received: by 10.66.83.129 with SMTP id q1mr32893174pay.4.1347472202471; Wed, 12 Sep 2012 10:50:02 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id ta8sm5551449pbc.71.2012.09.12.10.50.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 10:50:01 -0700 (PDT) Message-ID: <5050CB48.6010202@rbcon.com> Date: Wed, 12 Sep 2012 10:50:00 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> In-Reply-To: <5050986B.9010706@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk8akPquIWAtYV9Oy8DksqEg0Z3g16esDC2Molw+3fBiGQDWZVoGzm3IAko+FA3Bw7iwmIX Cc: Samuel Erdtman , "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 17:50:04 -0000 Peter, thanks for the comment, but in this case I'm not actually asking for clarification on anything involving string comparison -- I think the existing spec covers case-insensitive comparisons and filtering. My question involved whether the spec should also indicate case-preserving. Another way of asking my question would be: Is a scim server free to change the data of an attribute value as long as the new value would produce the same matching result in a filter? --Dale On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I hate to say the dreaded word "internationalization", but if we're > talking about comparison of strings then there's much more involved > here than case. If we avoid comparison and just pass strings around as > a series of octets then we're probably safe... > > On 9/12/12 12:01 AM, Samuel Erdtman wrote: >> As far as I can remember we have not discussed case-preservation. >> >> I agree that it should be specified how to handle it. have I >> understod you correctly with these two statements: * Case-sensitive >> attributes must preserve case. * Case-insensitive attributes may >> not preserve case if explicitly stated, in similarly fashion as >> case-sensitivity is specified, otherwise case must be preserved. >> >> Regards //Samuel >> >> >> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>> from my reading, the scim specs are very clear about >>> case-sensitivity issues. For example, there is this paragraph in >>> the API doc, section 3.2.2.1: >>> >>> "String type attributes are case insensitive by default unless >>> the attribute type is defined as a caseExact string. Attribute >>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>> for all string attributes unless the attribute is defined as >>> caseExact. By default all string attributes are caseIgnore." >>> >>> However, I have not been able to find anything which indicates >>> whether attribute values should be case-preserving -- unless >>> perhaps there is something relevant in the XML Schema Datatypes >>> Specification referred to in the schema doc. I would think there >>> would be something about it in the API doc for creating or >>> updating resources. >>> >>> Personally, I don't remember using a case-insensitive, >>> non-case-preserving system since DOS 8.3 file names, but it has >>> come up in our implementation. >>> >>> Has this been discussed and does the WG have rough consensus >>> about this? >>> >>> My preference would be to specify case-preservation for >>> case-insensitive attributes. I think it's the most useful option, >>> and then we could rely on it as we cross system domains. It would >>> be inconvenient for a SCIM service to magically modify data >>> passed into it. >>> >>> --Dale >>> >>> >>> _______________________________________________ scim mailing >>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd > JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI > =BJel > -----END PGP SIGNATURE----- From prvs=160217FA45=erik.wahlstrom@nexussafe.com Wed Sep 12 10:57:50 2012 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 506E821F84AF for ; Wed, 12 Sep 2012 10:57:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cXZd3cBLckp for ; Wed, 12 Sep 2012 10:57:49 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2D49621F849D for ; Wed, 12 Sep 2012 10:57:48 -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.1.379.0; Wed, 12 Sep 2012 19:58:34 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 12 Sep 2012 19:57:35 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Dale Olds Thread-Topic: [scim] case preserving vs case insensitive Thread-Index: AQHNkIXZMRQ6iYIt10qtOKWvsKXeNpeGFaAAgACJOYCAADyjAIAAAhyA Date: Wed, 12 Sep 2012 17:57:34 +0000 Message-ID: <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> In-Reply-To: <5050CB48.6010202@rbcon.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.60] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69CAFDC145E9B64C9EF8DA0622412BD6@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Samuel Erdtman , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 17:57:50 -0000 IMHO it's possible to change anything on the server side. Ignoring attribut= es, adding attributes, changing cases and so on. The client gets the create= d resource back in the response and can inspect it to look at what was crea= ted on the server side. Should the servers change a lot of things in the cr= eation? No I don't think so, but it should be possible to do to enable more= back end storage types. / Erik On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: > Peter, thanks for the comment, but in this case I'm not actually asking f= or clarification on anything involving string comparison -- I think the exi= sting spec covers case-insensitive comparisons and filtering. My question i= nvolved whether the spec should also indicate case-preserving. >=20 > Another way of asking my question would be: >=20 > Is a scim server free to change the data of an attribute value as long as= the new value would produce the same matching result in a filter? >=20 > --Dale >=20 > On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> I hate to say the dreaded word "internationalization", but if we're >> talking about comparison of strings then there's much more involved >> here than case. If we avoid comparison and just pass strings around as >> a series of octets then we're probably safe... >>=20 >> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>> As far as I can remember we have not discussed case-preservation. >>>=20 >>> I agree that it should be specified how to handle it. have I >>> understod you correctly with these two statements: * Case-sensitive >>> attributes must preserve case. * Case-insensitive attributes may >>> not preserve case if explicitly stated, in similarly fashion as >>> case-sensitivity is specified, otherwise case must be preserved. >>>=20 >>> Regards //Samuel >>>=20 >>>=20 >>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>> from my reading, the scim specs are very clear about >>>> case-sensitivity issues. For example, there is this paragraph in >>>> the API doc, section 3.2.2.1: >>>>=20 >>>> "String type attributes are case insensitive by default unless >>>> the attribute type is defined as a caseExact string. Attribute >>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>>> for all string attributes unless the attribute is defined as >>>> caseExact. By default all string attributes are caseIgnore." >>>>=20 >>>> However, I have not been able to find anything which indicates >>>> whether attribute values should be case-preserving -- unless >>>> perhaps there is something relevant in the XML Schema Datatypes >>>> Specification referred to in the schema doc. I would think there >>>> would be something about it in the API doc for creating or >>>> updating resources. >>>>=20 >>>> Personally, I don't remember using a case-insensitive, >>>> non-case-preserving system since DOS 8.3 file names, but it has >>>> come up in our implementation. >>>>=20 >>>> Has this been discussed and does the WG have rough consensus >>>> about this? >>>>=20 >>>> My preference would be to specify case-preservation for >>>> case-insensitive attributes. I think it's the most useful option, >>>> and then we could rely on it as we cross system domains. It would >>>> be inconvenient for a SCIM service to magically modify data >>>> passed into it. >>>>=20 >>>> --Dale >>>>=20 >>>>=20 >>>> _______________________________________________ scim mailing >>>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >> =3DBJel >> -----END PGP SIGNATURE----- >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Wed Sep 12 13:18:27 2012 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 CC46C21F85B4 for ; Wed, 12 Sep 2012 13:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z+g+RxDSayG for ; Wed, 12 Sep 2012 13:18:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B121F85A4 for ; Wed, 12 Sep 2012 13:18:26 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26CCD4005A; Wed, 12 Sep 2012 14:19:09 -0600 (MDT) Message-ID: <5050EE10.8040200@stpeter.im> Date: Wed, 12 Sep 2012 14:18:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Kelly Grizzle References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <56C3C758F9D6534CA3778EAA1E0C3437330EB7F2@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330EB7F2@BY2PRD0410MB354.namprd04.prod.outlook.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Samuel Erdtman , "scim@ietf.org" , Dale Olds Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 20:18:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/12/12 11:14 AM, Kelly Grizzle wrote: > +1 for always preserving case. > > JSON (which seems likely to become the only representation for > SCIM) uses Unicode characters for strings. This would handle the > i18n requirements. /me steps onto his soap-box... Saying "Unicode handles all i18n requirements" is like saying "TLS handles all security requirements". If you made the latter statement in a room full of security experts, you'd get howls of laughter or shouts of objection. As to i18n, yes it is more complex than "just use Unicode" (or, to be precise, UTF-8-encoded Unicode code points). To choose a simple example, "AEIOU" compares to "aeiou" in a case-insensitive comparison, right? Well, not necessarily. In Turkish locales, "AEIOU" actually compares to "aeıou" (where ı = U+0131, "LATIN SMALL LETTER DOTLESS I"). And that's not even to get started on things like canonical vs. compatibility equivalence, Unicode normlization, bidirectional text, full-width and half-width characters, confusables, and so on. I gave a two-hour tutorial about these topics at an IETF meeting last year, and the slides are here (unfortunately, there are a few errors in the slides and they need to be updated to reflect more recent work, but I lost the originals and have only the PDF now, so I need to reconstruct the whole thing): https://stpeter.im/files/i18n-intro.pdf If we have internationalization requirements, we need to clear about them up front and understand what the security implications might be (e.g., incorrectly compared usernames could result in escalation of privilege attacks or denial of service). Depending on the nature of those requirements, saying "just use Unicode" is probably not enough. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBQ7hAACgkQNL8k5A2w/vxMZgCgl4WgghKqvUtamk9ZnjLonMad 59cAoIVA4224pZ/jApwKWHn6ppjHqo5w =nQxS -----END PGP SIGNATURE----- From barryleiba.mailing.lists@gmail.com Wed Sep 12 13:32:04 2012 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 7F3AB21F8661 for ; Wed, 12 Sep 2012 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj6cwZOl1Dai for ; Wed, 12 Sep 2012 13:32:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4725821F8618 for ; Wed, 12 Sep 2012 13:31:58 -0700 (PDT) Received: by lbky2 with SMTP id y2so1574172lbk.31 for ; Wed, 12 Sep 2012 13:31:57 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P3xz+ZbilkjhD4mUXdxAxGIydmgiUz9dIe7xlU0VDzY=; b=bYpqzIH+eFlqqYG0b7fdAIYVsJ5zT23Xe29F8AZxhSc4BQMocPS4RNBuhW6HxEyLEz Wx2i2jnPrSjNB895164HXIhUPticEVNW7pGCGw8KERcKJMAQWDVqDp7z57wbJQbAx6p8 WXWTaz1iprLzgOSTSLiGquABDK0soCpXOY1XXt5TMv7jdFH8z1Z40S7bCa+B69ewwpBO otGwTWPEMeMhNXxC2Dl0V1CVMaJNw5nw3iZCAsoBAs0YKK+95oa2coSO7ffKdZ7mjhfB Piw8D72Ww7rqtqjozK2WbR4Rf0uhLAbjV0vvb5rVqKRQRCzTMmQ95HK6e8llR4BNzzLp Do4Q== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr113815lby.28.1347481916923; Wed, 12 Sep 2012 13:31:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 12 Sep 2012 13:31:56 -0700 (PDT) In-Reply-To: <5050EE10.8040200@stpeter.im> References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <56C3C758F9D6534CA3778EAA1E0C3437330EB7F2@BY2PRD0410MB354.namprd04.prod.outlook.com> <5050EE10.8040200@stpeter.im> Date: Wed, 12 Sep 2012 16:31:56 -0400 X-Google-Sender-Auth: dHTpgzHq0yvJ13feLHKQPnbksrw Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "scim@ietf.org" Subject: Re: [scim] case preserving vs case insensitive 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, 12 Sep 2012 20:32:04 -0000 > /me steps onto his soap-box... What Peter said. > If we have internationalization requirements, we need to clear about > them up front and understand what the security implications might be > (e.g., incorrectly compared usernames could result in escalation of > privilege attacks or denial of service). Depending on the nature of > those requirements, saying "just use Unicode" is probably not enough. Indeed, absolutely. And also, to make things more complicated, it's not as simple as using octet comparisons. Somewhere, some identity is going to get set up as "Barry Leiba", and some administrator is going to search for that by typing "leiba" (or even "lieba") into a search form. Or an identity will be set up for "H=E9l=E8ne For=EAt" and an admin with an English keyboard will search for "helene foret" (or even "helene forest"). The extent to which we want these searches to find the right identities will be part of the internationalization requirements that have to be satisfied. Barry From olds@rbcon.com Wed Sep 12 15:13:42 2012 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 21FE021F8545 for ; Wed, 12 Sep 2012 15:13:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdUimt+96mBP for ; Wed, 12 Sep 2012 15:13:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3C21F8543 for ; Wed, 12 Sep 2012 15:13:41 -0700 (PDT) Received: by dadf8 with SMTP id f8so1281340dad.31 for ; Wed, 12 Sep 2012 15:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=yYRqOPuai/yiyYLeY4/VAixaY/l258D8vP7KKEzCwMM=; b=DCTyAT1xKkr6rRFus6xY1ORuxBgiFoC+KjXMsdnA9/OGZFnorrHsCQp0W+PwkWAaBT a9M9ftX2/R+NiS+ZFOpmxtzmu7I/0IjHq90Po0A+xZiQWZghDd03UnFWt1De3kItuone tqby5NSpTAbJMu7YuC5Q7W2PhiyK2s6u12zAVDbc9vsiWHg84FVzh+FK2Xrl15Jx+fCZ HC5XoQAV6oMmA+s/Qgj/xBRC8rr0TntozQnSjH/hPpWSD7JJwC9uBcaqQhvfsHVez0Ff eR9LLR0fbqQclwmoUcGUXjRYQSOcbOxnKV9Pk53aGGLfMLyUnVnfFXRQdpXMx1mzCzCI 9MyQ== Received: by 10.66.75.73 with SMTP id a9mr33747146paw.43.1347488020908; Wed, 12 Sep 2012 15:13:40 -0700 (PDT) Received: from [10.40.32.89] ([173.243.48.220]) by mx.google.com with ESMTPS id ih2sm10415273pbc.65.2012.09.12.15.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 15:13:39 -0700 (PDT) Message-ID: <50510911.90704@rbcon.com> Date: Wed, 12 Sep 2012 15:13:37 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> In-Reply-To: <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQlUPxBHZgHB+9p5G8FGvFZ7/9ECd5X4MHbl3YjnLiGJmfSWeC2yX7Jj1RT15cPxq8bH779t Cc: Samuel Erdtman , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving 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, 12 Sep 2012 22:13:42 -0000 (changed subject line to distinguish from evolving thread about i18n, which IMO is a fine thread, but goes way beyond the original question) Erik, I actually mostly agree with your point, but I'm also trying to complete an implementation... Do you think it should be acceptable for a scim server to force all userNames to uppercase (for some definition of uppercase)? --Dale On 09/12/2012 10:57 AM, Erik Wahlström wrote: > IMHO it's possible to change anything on the server side. Ignoring attributes, adding attributes, changing cases and so on. The client gets the created resource back in the response and can inspect it to look at what was created on the server side. Should the servers change a lot of things in the creation? No I don't think so, but it should be possible to do to enable more back end storage types. > / Erik > > > On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: > >> Peter, thanks for the comment, but in this case I'm not actually asking for clarification on anything involving string comparison -- I think the existing spec covers case-insensitive comparisons and filtering. My question involved whether the spec should also indicate case-preserving. >> >> Another way of asking my question would be: >> >> Is a scim server free to change the data of an attribute value as long as the new value would produce the same matching result in a filter? >> >> --Dale >> >> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I hate to say the dreaded word "internationalization", but if we're >>> talking about comparison of strings then there's much more involved >>> here than case. If we avoid comparison and just pass strings around as >>> a series of octets then we're probably safe... >>> >>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>> As far as I can remember we have not discussed case-preservation. >>>> >>>> I agree that it should be specified how to handle it. have I >>>> understod you correctly with these two statements: * Case-sensitive >>>> attributes must preserve case. * Case-insensitive attributes may >>>> not preserve case if explicitly stated, in similarly fashion as >>>> case-sensitivity is specified, otherwise case must be preserved. >>>> >>>> Regards //Samuel >>>> >>>> >>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>> from my reading, the scim specs are very clear about >>>>> case-sensitivity issues. For example, there is this paragraph in >>>>> the API doc, section 3.2.2.1: >>>>> >>>>> "String type attributes are case insensitive by default unless >>>>> the attribute type is defined as a caseExact string. Attribute >>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>>>> for all string attributes unless the attribute is defined as >>>>> caseExact. By default all string attributes are caseIgnore." >>>>> >>>>> However, I have not been able to find anything which indicates >>>>> whether attribute values should be case-preserving -- unless >>>>> perhaps there is something relevant in the XML Schema Datatypes >>>>> Specification referred to in the schema doc. I would think there >>>>> would be something about it in the API doc for creating or >>>>> updating resources. >>>>> >>>>> Personally, I don't remember using a case-insensitive, >>>>> non-case-preserving system since DOS 8.3 file names, but it has >>>>> come up in our implementation. >>>>> >>>>> Has this been discussed and does the WG have rough consensus >>>>> about this? >>>>> >>>>> My preference would be to specify case-preservation for >>>>> case-insensitive attributes. I think it's the most useful option, >>>>> and then we could rely on it as we cross system domains. It would >>>>> be inconvenient for a SCIM service to magically modify data >>>>> passed into it. >>>>> >>>>> --Dale >>>>> >>>>> >>>>> _______________________________________________ scim mailing >>>>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>> >>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>> =BJel >>> -----END PGP SIGNATURE----- >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From prvs=46034AE3AF=erik.wahlstrom@nexussafe.com Thu Sep 13 10:28:16 2012 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 032C921F8592 for ; Thu, 13 Sep 2012 10:28:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9EuogmcUmO for ; Thu, 13 Sep 2012 10:28:15 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id A8FC421F851B for ; Thu, 13 Sep 2012 10:28:14 -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.1.379.0; Thu, 13 Sep 2012 19:28:13 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Thu, 13 Sep 2012 19:27:57 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Dale Olds Thread-Topic: [scim] case preserving Thread-Index: AQHNkTPghZW9vplX8EGqfz9RZrqBvJeIZkmA Date: Thu, 13 Sep 2012 17:27:56 +0000 Message-ID: <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> <50510911.90704@rbcon.com> In-Reply-To: <50510911.90704@rbcon.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.60] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5A93F4722FECD44AB08DA147BF7D4A1B@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Samuel Erdtman , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving 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, 13 Sep 2012 17:28:16 -0000 Hi, In general yes. I don't think it's a very good behavior to change it, but I= think we build our selfs in a corner if we don't let servers store it's re= sources in there own way.=20 Best regards Erik On Sep 13, 2012, at 12:13 AM, Dale Olds wrote: > (changed subject line to distinguish from evolving thread about i18n, whi= ch IMO is a fine thread, but goes way beyond the original question) >=20 > Erik, >=20 > I actually mostly agree with your point, but I'm also trying to complete = an implementation... >=20 > Do you think it should be acceptable for a scim server to force all userN= ames to uppercase (for some definition of uppercase)? >=20 > --Dale >=20 >=20 > On 09/12/2012 10:57 AM, Erik Wahlstr=F6m wrote: >> IMHO it's possible to change anything on the server side. Ignoring attri= butes, adding attributes, changing cases and so on. The client gets the cre= ated resource back in the response and can inspect it to look at what was c= reated on the server side. Should the servers change a lot of things in the= creation? No I don't think so, but it should be possible to do to enable m= ore back end storage types. >> / Erik >>=20 >>=20 >> On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: >>=20 >>> Peter, thanks for the comment, but in this case I'm not actually asking= for clarification on anything involving string comparison -- I think the e= xisting spec covers case-insensitive comparisons and filtering. My question= involved whether the spec should also indicate case-preserving. >>>=20 >>> Another way of asking my question would be: >>>=20 >>> Is a scim server free to change the data of an attribute value as long = as the new value would produce the same matching result in a filter? >>>=20 >>> --Dale >>>=20 >>> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>>=20 >>>> I hate to say the dreaded word "internationalization", but if we're >>>> talking about comparison of strings then there's much more involved >>>> here than case. If we avoid comparison and just pass strings around as >>>> a series of octets then we're probably safe... >>>>=20 >>>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>>> As far as I can remember we have not discussed case-preservation. >>>>>=20 >>>>> I agree that it should be specified how to handle it. have I >>>>> understod you correctly with these two statements: * Case-sensitive >>>>> attributes must preserve case. * Case-insensitive attributes may >>>>> not preserve case if explicitly stated, in similarly fashion as >>>>> case-sensitivity is specified, otherwise case must be preserved. >>>>>=20 >>>>> Regards //Samuel >>>>>=20 >>>>>=20 >>>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>>> from my reading, the scim specs are very clear about >>>>>> case-sensitivity issues. For example, there is this paragraph in >>>>>> the API doc, section 3.2.2.1: >>>>>>=20 >>>>>> "String type attributes are case insensitive by default unless >>>>>> the attribute type is defined as a caseExact string. Attribute >>>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>>>>> for all string attributes unless the attribute is defined as >>>>>> caseExact. By default all string attributes are caseIgnore." >>>>>>=20 >>>>>> However, I have not been able to find anything which indicates >>>>>> whether attribute values should be case-preserving -- unless >>>>>> perhaps there is something relevant in the XML Schema Datatypes >>>>>> Specification referred to in the schema doc. I would think there >>>>>> would be something about it in the API doc for creating or >>>>>> updating resources. >>>>>>=20 >>>>>> Personally, I don't remember using a case-insensitive, >>>>>> non-case-preserving system since DOS 8.3 file names, but it has >>>>>> come up in our implementation. >>>>>>=20 >>>>>> Has this been discussed and does the WG have rough consensus >>>>>> about this? >>>>>>=20 >>>>>> My preference would be to specify case-preservation for >>>>>> case-insensitive attributes. I think it's the most useful option, >>>>>> and then we could rely on it as we cross system domains. It would >>>>>> be inconvenient for a SCIM service to magically modify data >>>>>> passed into it. >>>>>>=20 >>>>>> --Dale >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ scim mailing >>>>>> list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>>>=20 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>>=20 >>>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>>> =3DBJel >>>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 From Bert.Greevenbosch@huawei.com Thu Sep 13 18:09:41 2012 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 4ADCC21F8694 for ; Thu, 13 Sep 2012 18:09:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bXM06h3p+ba for ; Thu, 13 Sep 2012 18:09:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6139D21F866C for ; Thu, 13 Sep 2012 18:09:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKQ54258; Fri, 14 Sep 2012 01:09:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 02:08:14 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 02:08:28 +0100 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 09:08:20 +0800 From: Bert Greevenbosch To: "scim@ietf.org" Thread-Topic: Upload of SCIM/vCard mapping draft Thread-Index: Ac2SFWzMlMLOx4qvROWDYZxSQ+TJ/g== Date: Fri, 14 Sep 2012 01:08:18 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB6290D0FD6@szxeml509-mbs> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB6290D0FD6szxeml509mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [scim] Upload of SCIM/vCard mapping draft 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, 14 Sep 2012 01:09:41 -0000 --_000_46A1DF3F04371240B504290A071B4DB6290D0FD6szxeml509mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Yesterday I uploaded a draft that provides mapping between SCIM and vCard. = It is available under the following link: http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ The draft provides the mapping in two directions: from SCIM to vCard and fr= om vCard to SCIM. Open issues include the conversion method between SCIM ids and vCard UIDs. = When that is done, it should be easy to port the grouping function. I think the draft is also very useful for the discussion on the format to u= se for SCIM, and in which extent it will be related to vCard. I look forward to your comments and suggestions! Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB6290D0FD6szxeml509mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Yesterday I uploaded a draft that provides mapping b= etween SCIM and vCard. It is available under the following link:=

http://datatracker.ietf.org/doc/draft-greevenbosch-s= cim-vcard-mapping/

 

The draft provides the mapping in two directions: fr= om SCIM to vCard and from vCard to SCIM.

 

Open issues include the conversion method between SC= IM ids and vCard UIDs. When that is done, it should be easy to port the gro= uping function.

 

I think the draft is also very useful for the discus= sion on the format to use for SCIM, and in which extent it will be related = to vCard.

 

I look forward to your comments and suggestions!

 

Best regards,

Bert

--_000_46A1DF3F04371240B504290A071B4DB6290D0FD6szxeml509mbs_-- From Gil.Kirkpatrick@quest.com Thu Sep 13 20:01:24 2012 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 78B2521F863C for ; Thu, 13 Sep 2012 20:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5VGUP+kAwh1 for ; Thu, 13 Sep 2012 20:01:23 -0700 (PDT) Received: from alvetxw01.quest.com (alvetxw01.quest.com [12.106.87.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2521F8639 for ; Thu, 13 Sep 2012 20:01:23 -0700 (PDT) Received: from ALVHTXW10.prod.quest.corp (10.1.135.22) by alvetxw01.quest.com (10.1.100.93) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Sep 2012 20:00:42 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW10.prod.quest.corp ([::1]) with mapi id 14.01.0355.002; Thu, 13 Sep 2012 20:01:22 -0700 From: Gil Kirkpatrick To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , Dale Olds Thread-Topic: [scim] case preserving Thread-Index: AQHNkeIfpknLQ2WkTUOiDgGIRn/pRZeJI2Zw Date: Fri, 14 Sep 2012 03:01:21 +0000 Message-ID: <2975133F5CF7F1468951D6B2C49708D8104D6E4B@ALVMBXW01.prod.quest.corp> References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> <50510911.90704@rbcon.com> <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> In-Reply-To: <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Samuel Erdtman , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving 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, 14 Sep 2012 03:01:24 -0000 >> if we don't let servers store it's resources in there own way. I disagree that something like the spelling of my last name is the "server'= s" resource. The storage medium is the server's resource, and attributes th= at the server creates for its own use are its own. I think that you can arg= ue that a username is a server's resource, or is at least subject to the se= rver's syntax rules. But I would say the spelling of my last name (e.g.) is= mine and the server should not alter it. What sort of corner are we buildi= ng ourselves into if we don't insist on case preservation, at least for att= ributes that are not "owned" by the server? Cheers, -gil=20 -----Original Message----- From: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]=20 Sent: Friday, September 14, 2012 3:28 AM To: Dale Olds Cc: Samuel Erdtman; Peter Saint-Andre; scim@ietf.org Subject: Re: [scim] case preserving Hi, In general yes. I don't think it's a very good behavior to change it, but I= think we build our selfs in a corner if we don't let servers store it's re= sources in there own way.=20 Best regards Erik On Sep 13, 2012, at 12:13 AM, Dale Olds wrote: > (changed subject line to distinguish from evolving thread about i18n,=20 > which IMO is a fine thread, but goes way beyond the original question) >=20 > Erik, >=20 > I actually mostly agree with your point, but I'm also trying to complete = an implementation... >=20 > Do you think it should be acceptable for a scim server to force all userN= ames to uppercase (for some definition of uppercase)? >=20 > --Dale >=20 >=20 > On 09/12/2012 10:57 AM, Erik Wahlstr=F6m wrote: >> IMHO it's possible to change anything on the server side. Ignoring attri= butes, adding attributes, changing cases and so on. The client gets the cre= ated resource back in the response and can inspect it to look at what was c= reated on the server side. Should the servers change a lot of things in the= creation? No I don't think so, but it should be possible to do to enable m= ore back end storage types. >> / Erik >>=20 >>=20 >> On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: >>=20 >>> Peter, thanks for the comment, but in this case I'm not actually asking= for clarification on anything involving string comparison -- I think the e= xisting spec covers case-insensitive comparisons and filtering. My question= involved whether the spec should also indicate case-preserving. >>>=20 >>> Another way of asking my question would be: >>>=20 >>> Is a scim server free to change the data of an attribute value as long = as the new value would produce the same matching result in a filter? >>>=20 >>> --Dale >>>=20 >>> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>>=20 >>>> I hate to say the dreaded word "internationalization", but if we're=20 >>>> talking about comparison of strings then there's much more involved=20 >>>> here than case. If we avoid comparison and just pass strings around=20 >>>> as a series of octets then we're probably safe... >>>>=20 >>>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>>> As far as I can remember we have not discussed case-preservation. >>>>>=20 >>>>> I agree that it should be specified how to handle it. have I=20 >>>>> understod you correctly with these two statements: *=20 >>>>> Case-sensitive attributes must preserve case. * Case-insensitive=20 >>>>> attributes may not preserve case if explicitly stated, in=20 >>>>> similarly fashion as case-sensitivity is specified, otherwise case mu= st be preserved. >>>>>=20 >>>>> Regards //Samuel >>>>>=20 >>>>>=20 >>>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>>> from my reading, the scim specs are very clear about=20 >>>>>> case-sensitivity issues. For example, there is this paragraph in=20 >>>>>> the API doc, section 3.2.2.1: >>>>>>=20 >>>>>> "String type attributes are case insensitive by default unless=20 >>>>>> the attribute type is defined as a caseExact string. Attribute=20 >>>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching=20 >>>>>> for all string attributes unless the attribute is defined as=20 >>>>>> caseExact. By default all string attributes are caseIgnore." >>>>>>=20 >>>>>> However, I have not been able to find anything which indicates=20 >>>>>> whether attribute values should be case-preserving -- unless=20 >>>>>> perhaps there is something relevant in the XML Schema Datatypes=20 >>>>>> Specification referred to in the schema doc. I would think there=20 >>>>>> would be something about it in the API doc for creating or=20 >>>>>> updating resources. >>>>>>=20 >>>>>> Personally, I don't remember using a case-insensitive,=20 >>>>>> non-case-preserving system since DOS 8.3 file names, but it has=20 >>>>>> come up in our implementation. >>>>>>=20 >>>>>> Has this been discussed and does the WG have rough consensus=20 >>>>>> about this? >>>>>>=20 >>>>>> My preference would be to specify case-preservation for=20 >>>>>> case-insensitive attributes. I think it's the most useful option,=20 >>>>>> and then we could rely on it as we cross system domains. It would=20 >>>>>> be inconvenient for a SCIM service to magically modify data=20 >>>>>> passed into it. >>>>>>=20 >>>>>> --Dale >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ scim mailing list=20 >>>>>> scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>>>=20 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>>=20 >>>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>>> =3DBJel >>>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 From prvs=46043C13EC=erik.wahlstrom@nexussafe.com Fri Sep 14 06:14:03 2012 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 1F07521F853B for ; Fri, 14 Sep 2012 06:14:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMhGtRxwLQj8 for ; Fri, 14 Sep 2012 06:14:02 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id BF53B21F8523 for ; Fri, 14 Sep 2012 06:14:01 -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.1.379.0; Fri, 14 Sep 2012 15:13:59 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Fri, 14 Sep 2012 15:13:55 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Gil Kirkpatrick Thread-Topic: [scim] case preserving Thread-Index: AQHNkTPghZW9vplX8EGqfz9RZrqBvJeIZkmAgACgN4CAAKslAA== Date: Fri, 14 Sep 2012 13:13:54 +0000 Message-ID: References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> <50510911.90704@rbcon.com> <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> <2975133F5CF7F1468951D6B2C49708D8104D6E4B@ALVMBXW01.prod.quest.corp> In-Reply-To: <2975133F5CF7F1468951D6B2C49708D8104D6E4B@ALVMBXW01.prod.quest.corp> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.60] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dale Olds , "scim@ietf.org" , Peter Saint-Andre , Samuel Erdtman Subject: Re: [scim] case preserving 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, 14 Sep 2012 13:14:03 -0000 Hi, First of all I think is a corner and that we should not put the burden of w= hat attributes are case preserving and who is not on a standard implementor= . And regarding a specific corner the last name example you mentioned is gr= eat. My last name is Wahlstr=F6m and it includes the Swedish character =F6 = (sound confused and you got the pronunciation correct :)). Every now and th= en when I register to non swedish systems they complain about the strange l= ooking character =F6 and I'm force to use o instead, and sometime the serve= rs just change it to some random texts. It could be over ambitious validati= on rules anywhere down the call stack to the storage and wrong encodings. T= o enable all legacy server to use SCIM we will run into one of these over a= mbitious validation rules and the server must then be able to own all attri= butes. / Erik On Sep 14, 2012, at 5:01 AM, Gil Kirkpatrick wrote: >>> if we don't let servers store it's resources in there own way. >=20 > I disagree that something like the spelling of my last name is the "serve= r's" resource. The storage medium is the server's resource, and attributes = that the server creates for its own use are its own. I think that you can a= rgue that a username is a server's resource, or is at least subject to the = server's syntax rules. But I would say the spelling of my last name (e.g.) = is mine and the server should not alter it. What sort of corner are we buil= ding ourselves into if we don't insist on case preservation, at least for a= ttributes that are not "owned" by the server? >=20 > Cheers, >=20 > -gil=20 >=20 > -----Original Message----- > From: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com]=20 > Sent: Friday, September 14, 2012 3:28 AM > To: Dale Olds > Cc: Samuel Erdtman; Peter Saint-Andre; scim@ietf.org > Subject: Re: [scim] case preserving >=20 > Hi, >=20 > In general yes. I don't think it's a very good behavior to change it, but= I think we build our selfs in a corner if we don't let servers store it's = resources in there own way.=20 >=20 > Best regards > Erik >=20 >=20 > On Sep 13, 2012, at 12:13 AM, Dale Olds wrote: >=20 >> (changed subject line to distinguish from evolving thread about i18n,=20 >> which IMO is a fine thread, but goes way beyond the original question) >>=20 >> Erik, >>=20 >> I actually mostly agree with your point, but I'm also trying to complete= an implementation... >>=20 >> Do you think it should be acceptable for a scim server to force all user= Names to uppercase (for some definition of uppercase)? >>=20 >> --Dale >>=20 >>=20 >> On 09/12/2012 10:57 AM, Erik Wahlstr=F6m wrote: >>> IMHO it's possible to change anything on the server side. Ignoring attr= ibutes, adding attributes, changing cases and so on. The client gets the cr= eated resource back in the response and can inspect it to look at what was = created on the server side. Should the servers change a lot of things in th= e creation? No I don't think so, but it should be possible to do to enable = more back end storage types. >>> / Erik >>>=20 >>>=20 >>> On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: >>>=20 >>>> Peter, thanks for the comment, but in this case I'm not actually askin= g for clarification on anything involving string comparison -- I think the = existing spec covers case-insensitive comparisons and filtering. My questio= n involved whether the spec should also indicate case-preserving. >>>>=20 >>>> Another way of asking my question would be: >>>>=20 >>>> Is a scim server free to change the data of an attribute value as long= as the new value would produce the same matching result in a filter? >>>>=20 >>>> --Dale >>>>=20 >>>> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>>=20 >>>>> I hate to say the dreaded word "internationalization", but if we're=20 >>>>> talking about comparison of strings then there's much more involved=20 >>>>> here than case. If we avoid comparison and just pass strings around=20 >>>>> as a series of octets then we're probably safe... >>>>>=20 >>>>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>>>> As far as I can remember we have not discussed case-preservation. >>>>>>=20 >>>>>> I agree that it should be specified how to handle it. have I=20 >>>>>> understod you correctly with these two statements: *=20 >>>>>> Case-sensitive attributes must preserve case. * Case-insensitive=20 >>>>>> attributes may not preserve case if explicitly stated, in=20 >>>>>> similarly fashion as case-sensitivity is specified, otherwise case m= ust be preserved. >>>>>>=20 >>>>>> Regards //Samuel >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>>>> from my reading, the scim specs are very clear about=20 >>>>>>> case-sensitivity issues. For example, there is this paragraph in=20 >>>>>>> the API doc, section 3.2.2.1: >>>>>>>=20 >>>>>>> "String type attributes are case insensitive by default unless=20 >>>>>>> the attribute type is defined as a caseExact string. Attribute=20 >>>>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching=20 >>>>>>> for all string attributes unless the attribute is defined as=20 >>>>>>> caseExact. By default all string attributes are caseIgnore." >>>>>>>=20 >>>>>>> However, I have not been able to find anything which indicates=20 >>>>>>> whether attribute values should be case-preserving -- unless=20 >>>>>>> perhaps there is something relevant in the XML Schema Datatypes=20 >>>>>>> Specification referred to in the schema doc. I would think there=20 >>>>>>> would be something about it in the API doc for creating or=20 >>>>>>> updating resources. >>>>>>>=20 >>>>>>> Personally, I don't remember using a case-insensitive,=20 >>>>>>> non-case-preserving system since DOS 8.3 file names, but it has=20 >>>>>>> come up in our implementation. >>>>>>>=20 >>>>>>> Has this been discussed and does the WG have rough consensus=20 >>>>>>> about this? >>>>>>>=20 >>>>>>> My preference would be to specify case-preservation for=20 >>>>>>> case-insensitive attributes. I think it's the most useful option,=20 >>>>>>> and then we could rely on it as we cross system domains. It would=20 >>>>>>> be inconvenient for a SCIM service to magically modify data=20 >>>>>>> passed into it. >>>>>>>=20 >>>>>>> --Dale >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ scim mailing list=20 >>>>>>> scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>>>>=20 >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>>>=20 >>>>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>>>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>>>> =3DBJel >>>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>=20 >=20 >=20 From mike.angstadt@gmail.com Fri Sep 14 10:16:18 2012 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 BDCA321F852C for ; Fri, 14 Sep 2012 10:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IODR5Tr+Z9CX for ; Fri, 14 Sep 2012 10:16:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E18E221F851C for ; Fri, 14 Sep 2012 10:16:17 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7240023obb.31 for ; Fri, 14 Sep 2012 10:16:17 -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:cc:content-type; bh=CN1NbDmhPIsneFRSpZoIvPJL+j2KrIpv2N06NcKsB64=; b=fuQzO8F7RzFdOrN3lA1HcX0vNQpNgEPktPr/8ZoUrMJLB5s5GCq68G8WzOsZtr1kGk 5/0l4HisxyF7nPOeGxVhd+4wt17YBKjaqQHj8eaRldVg8O8NuAhO7Ppwdxa7jJRl7Vkm HGkQlMfWAcFvAFVIT2aNoPfyxy40ZiGEl4xo/21GSyKIw76fWfaY1zALVrZBvTi6VuIX 0LMc/cpKfzLQeBAqWfUKCYAFWTMzfaD6N72l4kgfl9dfE1GPmhYBg1Rjjm9jgLS7RFsu 8RlXf+xxpIvAxZMDvml8lmMUK7tqr8XIUbM2UquM047TcQyDDZmfYqqlPQAZMwqjLvDT tdQg== MIME-Version: 1.0 Received: by 10.182.207.6 with SMTP id ls6mr4497889obc.36.1347642977024; Fri, 14 Sep 2012 10:16:17 -0700 (PDT) Received: by 10.60.172.177 with HTTP; Fri, 14 Sep 2012 10:16:17 -0700 (PDT) Date: Fri, 14 Sep 2012 13:16:17 -0400 Message-ID: From: Michael Angstadt To: Bert.Greevenbosch@huawei.com Content-Type: text/plain; charset=ISO-8859-1 Cc: scim@ietf.org Subject: Re: [scim] Upload of SCIM/vCard mapping draft 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, 14 Sep 2012 17:16:18 -0000 Hi Bert, I saw your message on the vCard mailing list (forwarded by Peter) and have some thoughts about the SCIM/vCard mapping document. ===== 1. "id" --> "UID" mapping (p. 6) There is no vCard-specific format for the UID property. It is *suggested* that a UUID be used and that it be encoded as a URI, but the property will accept any URI or any text value. Here is an example of the "best-practice" format of a vCard UID: UID:urn:uuid:dd418720-c754-4631-a869-db89d02b831b However, the property also accepts free-form text. In this case, the VALUE parameter MUST be set to "text". For example: UID;VALUE=text:123abc For SCIM IDs, you could encode them as a URI. The URI could start with "scim:" to show that it's a SCIM ID For example: UID:scim:123456789 ===== 2. "meta/location" mapping (p. 6) Could the GEO property be used for this? The GEO property holds a set of latitude/longitude coordinates. ===== 3. "organization", "division", and "department" mappings (p. 7) The "organization", "division", and "department" SCIM attributes could be stored within a single ORG vCard property. The ORG property can contain not just one value, but a hierarchical list of values. It starts with the broadest organization and ends with the most specific. So, the "organization" attribute could be mapped to the first ORG value, "division" to the second, and "department" to the third (a "division" is broader than a "department", right?). For example, if organization is "Google", division is "GMail Team", and department is "Spam Detection Squad", then the ORG property would look like this: ORG:Google;GMail Team;Spam Detection Squad ===== 4. "manager/managerId" mapping (p. 7) The manager ID could go in a RELATED vCard property like so: RELATED:scim:987654321 The property can also store a plain text value if the SCIM ID is not encoded as a URI: RELATED;VALUE=text:987654321 ===== 5. "address/formatted" mapping (p. 8) Perhaps you could map this attribute to the LABEL parameter of the ADR property. The LABEL parameter is used to define the exact text that should be printed on the package or envelope that you are mailing. For example: ADR;LABEL="123 Main St.\nAustin, TX 12345\nUSA":;;123 Main St.;Austin;TX;12345;USA ===== 6. Description of the "N" property (p. 11) The "Notes" column in the table describes the N property like so: "Additional analysis the N property may be needed, as vCard does not provide an unambigious separation of its components." I'm not sure what you mean by this? The components of the N property are actually very well defined! They are formatted like this: N:Family;Given;Additional;Prefixes;Suffixes ===== 7. Typos Just a few small typos I saw!! :) * p. 14 - "CATHEGORIES" should be "CATEGORIES" * p. 15 - I'm not sure if this is an error, but in the center column, I think "x501Certificates" should be "x509Certificates" Regards, Mike Angstadt http://code.google.com/p/ez-vcard http://mikeangstadt.name/mike-angstadt.vcf From olds@rbcon.com Fri Sep 14 13:54:10 2012 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 D3B5521F8568 for ; Fri, 14 Sep 2012 13:54:10 -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.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxbl2kGoGI9T for ; Fri, 14 Sep 2012 13:54:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 983FE21F8567 for ; Fri, 14 Sep 2012 13:54:09 -0700 (PDT) Received: by dadf8 with SMTP id f8so2653632dad.31 for ; Fri, 14 Sep 2012 13:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=fscxO/c09yv3XKml1G3d3TMhfOa+py+AS9hPMEFZMQY=; b=Ye4bO0IxEaglY552b1sAtYevakzpbkBsaZcfWxFI8pkGuzAqev5c5byEN1JACyFHzF 8US85gAuv1r2PBv4dHWIJSQmlZg3mTybjzbow/bDCSz5PhUKNYDYG1Ub+tM5Vfj5JfQy 0MvEQbW/DnPyr8PmHTgc3MpZjE06VC7VeBh2z8v3tE0So/mm70ZhpK7z7lhyTeAtC6na p/0nSTX9wR/W9WvbkelKUz4ee8ZIidQeHlMFNmbYVPw5MZ5OyVQitYXnZKsoHIzHsANa NRGD95Lf6rYikqPJSjFG5D1hIc6gl00tNkf7jW/+ylz/WMWhkpP3uMf9q3r7v6tqvXa2 2B8Q== Received: by 10.68.239.134 with SMTP id vs6mr6689214pbc.108.1347656049131; Fri, 14 Sep 2012 13:54:09 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id wn4sm1554689pbc.55.2012.09.14.13.54.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 13:54:08 -0700 (PDT) Message-ID: <5053996E.4010502@rbcon.com> Date: Fri, 14 Sep 2012 13:54:06 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> <50510911.90704@rbcon.com> <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> <2975133F5CF7F1468951D6B2C49708D8104D6E4B@ALVMBXW01.prod.quest.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnjmzgKAcZoTMd533m7eMmC8B8VwR8ROi8dHqV9ttVeOmx0twME0K2nySol0XNM3sqmJ0gq Cc: Samuel Erdtman , Gil Kirkpatrick , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving 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, 14 Sep 2012 20:54:10 -0000 Erik, as I understand your reply to Gil, you'd prefer that a scim server not munge your name due to "over ambitious validation rules" or "wrong encodings," but you'd like the scim spec to allow such munging to ease compliance and increase adoption. I'd like to increase adoption too, but we also need to have some agreed level of usefulness -- hopefully a somewhat higher level than currently in the name munging wild. I can see situations that, if I could rely on a scim server not munging a name, I would be more likely to choose a scim server instead of some other service (or rolling my own). Also, Pamela Dingle has pointed out an attribute that I think is relevant to this issue: externalId. Mostly we've talked about human names, but externalId is significant also. I may be wrong, but I have not been able to find anything in the scim specs that says externalId is case-exact. If that's true, it defaults to case-ignore. I would certainly not want a scim server to be able to change case or other characters in an externalId. --Dale On 09/14/2012 06:13 AM, Erik Wahlström wrote: > Hi, > > First of all I think is a corner and that we should not put the burden of what attributes are case preserving and who is not on a standard implementor. And regarding a specific corner the last name example you mentioned is great. My last name is Wahlström and it includes the Swedish character ö (sound confused and you got the pronunciation correct :)). Every now and then when I register to non swedish systems they complain about the strange looking character ö and I'm force to use o instead, and sometime the servers just change it to some random texts. It could be over ambitious validation rules anywhere down the call stack to the storage and wrong encodings. To enable all legacy server to use SCIM we will run into one of these over ambitious validation rules and the server must then be able to own all attributes. > > / Erik > > > > On Sep 14, 2012, at 5:01 AM, Gil Kirkpatrick wrote: > >>>> if we don't let servers store it's resources in there own way. >> I disagree that something like the spelling of my last name is the "server's" resource. The storage medium is the server's resource, and attributes that the server creates for its own use are its own. I think that you can argue that a username is a server's resource, or is at least subject to the server's syntax rules. But I would say the spelling of my last name (e.g.) is mine and the server should not alter it. What sort of corner are we building ourselves into if we don't insist on case preservation, at least for attributes that are not "owned" by the server? >> >> Cheers, >> >> -gil >> >> -----Original Message----- >> From: Erik Wahlström [mailto:erik.wahlstrom@nexussafe.com] >> Sent: Friday, September 14, 2012 3:28 AM >> To: Dale Olds >> Cc: Samuel Erdtman; Peter Saint-Andre; scim@ietf.org >> Subject: Re: [scim] case preserving >> >> Hi, >> >> In general yes. I don't think it's a very good behavior to change it, but I think we build our selfs in a corner if we don't let servers store it's resources in there own way. >> >> Best regards >> Erik >> >> >> On Sep 13, 2012, at 12:13 AM, Dale Olds wrote: >> >>> (changed subject line to distinguish from evolving thread about i18n, >>> which IMO is a fine thread, but goes way beyond the original question) >>> >>> Erik, >>> >>> I actually mostly agree with your point, but I'm also trying to complete an implementation... >>> >>> Do you think it should be acceptable for a scim server to force all userNames to uppercase (for some definition of uppercase)? >>> >>> --Dale >>> >>> >>> On 09/12/2012 10:57 AM, Erik Wahlström wrote: >>>> IMHO it's possible to change anything on the server side. Ignoring attributes, adding attributes, changing cases and so on. The client gets the created resource back in the response and can inspect it to look at what was created on the server side. Should the servers change a lot of things in the creation? No I don't think so, but it should be possible to do to enable more back end storage types. >>>> / Erik >>>> >>>> >>>> On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: >>>> >>>>> Peter, thanks for the comment, but in this case I'm not actually asking for clarification on anything involving string comparison -- I think the existing spec covers case-insensitive comparisons and filtering. My question involved whether the spec should also indicate case-preserving. >>>>> >>>>> Another way of asking my question would be: >>>>> >>>>> Is a scim server free to change the data of an attribute value as long as the new value would produce the same matching result in a filter? >>>>> >>>>> --Dale >>>>> >>>>> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> I hate to say the dreaded word "internationalization", but if we're >>>>>> talking about comparison of strings then there's much more involved >>>>>> here than case. If we avoid comparison and just pass strings around >>>>>> as a series of octets then we're probably safe... >>>>>> >>>>>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>>>>> As far as I can remember we have not discussed case-preservation. >>>>>>> >>>>>>> I agree that it should be specified how to handle it. have I >>>>>>> understod you correctly with these two statements: * >>>>>>> Case-sensitive attributes must preserve case. * Case-insensitive >>>>>>> attributes may not preserve case if explicitly stated, in >>>>>>> similarly fashion as case-sensitivity is specified, otherwise case must be preserved. >>>>>>> >>>>>>> Regards //Samuel >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>>>>> from my reading, the scim specs are very clear about >>>>>>>> case-sensitivity issues. For example, there is this paragraph in >>>>>>>> the API doc, section 3.2.2.1: >>>>>>>> >>>>>>>> "String type attributes are case insensitive by default unless >>>>>>>> the attribute type is defined as a caseExact string. Attribute >>>>>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>>>>>>> for all string attributes unless the attribute is defined as >>>>>>>> caseExact. By default all string attributes are caseIgnore." >>>>>>>> >>>>>>>> However, I have not been able to find anything which indicates >>>>>>>> whether attribute values should be case-preserving -- unless >>>>>>>> perhaps there is something relevant in the XML Schema Datatypes >>>>>>>> Specification referred to in the schema doc. I would think there >>>>>>>> would be something about it in the API doc for creating or >>>>>>>> updating resources. >>>>>>>> >>>>>>>> Personally, I don't remember using a case-insensitive, >>>>>>>> non-case-preserving system since DOS 8.3 file names, but it has >>>>>>>> come up in our implementation. >>>>>>>> >>>>>>>> Has this been discussed and does the WG have rough consensus >>>>>>>> about this? >>>>>>>> >>>>>>>> My preference would be to specify case-preservation for >>>>>>>> case-insensitive attributes. I think it's the most useful option, >>>>>>>> and then we could rely on it as we cross system domains. It would >>>>>>>> be inconvenient for a SCIM service to magically modify data >>>>>>>> passed into it. >>>>>>>> >>>>>>>> --Dale >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ scim mailing list >>>>>>>> scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>>>>> >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>>>> >>>>>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>>>>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>>>>> =BJel >>>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >> From olds@rbcon.com Fri Sep 14 18:18:03 2012 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 5DA6711E8091 for ; Fri, 14 Sep 2012 18:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqwKd704C3EZ for ; Fri, 14 Sep 2012 18:18:02 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C256911E808E for ; Fri, 14 Sep 2012 18:18:02 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so6362081pbb.31 for ; Fri, 14 Sep 2012 18:18:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=pkkVY02v5S0rmxT253LKSWePZCkEN1IVCooi4/9TZKw=; b=fyqMTeKJLJy+IAeHStmoNZlPW8wKh18Y04jCdG4i65qxX/+ywx5NfXKfkO1y8Ecko2 VQ1A8IPNRaIcg2JcEY4XuouhPSo2oHueT75gVfI42DQS3yAMbmSGrjvu5v0GdXYe44X5 4mPP3cf/44D5XZPUwmOqmpi2ThOWjy9p6+9lPFYK+l1qUdQH1ZOtec8AzcScnlPXZHDT +s1W4czz4DavNVBCDk7KNOr8j9lYQSpvEMBh44u0Xd32Q6IRptoAabgkrEyxBL8uiSbB 1UwerJeXoRyxbvt5vgaNGkELBR7IFrgPn+eNKHx0ghIKQqG8gDmdWT7LI+Rev3zpu7rQ BanA== Received: by 10.68.217.97 with SMTP id ox1mr7532310pbc.138.1347671882366; Fri, 14 Sep 2012 18:18:02 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id iq3sm1934075pbc.5.2012.09.14.18.18.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 18:18:01 -0700 (PDT) Message-ID: <5053D747.4050004@rbcon.com> Date: Fri, 14 Sep 2012 18:17:59 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Samuel Erdtman References: <504FEA8B.5050505@rbcon.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmIwH7rajrv/6oMYGKgXbBg/lLKZyocq5+VLMMl1jBIt0/7gWYP/dN/MZEkVQTR3Q31911I Cc: "scim@ietf.org" Subject: Re: [scim] evaluating filters: true, false, and undefined 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, 15 Sep 2012 01:18:03 -0000 I would expect that if "PR foobar" on a resource evaluates to false it means "this resource has no value for attribute foobar", which is not quite the same as "this server does not know what foobar means". Nevertheless, if the server does not know what an attribute means no resource will have a value for that attribute, so perhaps it's close enough. I can't think of an example that's not overly contrived where the difference would matter. One of the reasons I brought this issue up is because there are places we'd like to add our own scim extensions, and we'd like to be able to write queries so that they work whether a particular scim server supports that extension or not. I also need to know how to handle undefined attributes in our own server. Would the working group support this additional sentence to the first paragraph of section 3.2.2.1? "Filters that contain references to attributes unknown to the server do not cause an error, but are evaluated such that those attributes are not present on each resource." --Dale On 09/11/2012 11:21 PM, Samuel Erdtman wrote: > In the scimproxy we will probably do it by interpreting undefined as > false i.e. the statements would be evaluated as you describe it. > However currently we only support one filter operation i.e. no 'and' > 'or' stuff yet. Have actually not tested much filtering during the > interops. > > If you would want to require foobar to be precent before evaluating > rest of the expression you could state it as folows: > ?filter=PR foobar AND (foobar GT 7 OR shirtColor EG red) > (PR means present i.e. not undefined) > > Regards > //Samuel > > On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >> section 3.2.2.1 of the API doc describes filtering expressions and bindings. >> It is very clear about what should happen if an operator is not defined (the >> example is 'regex'), but I do not see anything which explicitly states what >> happens if an attribute in the expression is not defined. The closest >> statement is in the first paragraph: "The expression language that is used >> in the filter parameter supports references to attributes and literals." I >> suppose that could mean a reference to an unknown attribute is not >> supported, but it doesn't really say that, and it doesn't say undefined >> attributes are an error. >> >> In filtering code for similar systems I've seen implementations that did not >> require attributes to be defined. This can be quite natural but does make >> the implementation more interesting. Consider this filter of rooms: >> >> True if contains someone with hat size > 7 or wearing a read shirt. >> >> There may not be anyone wearing a hat in any room, but it would still find >> rooms with red shirts. IOW, it only takes one true component of an 'or' >> expression to make it true, even if one of the components is undefined. >> >> "True if someone with foobar > 7 or wearing a read shirt" works just as >> well. >> >> This is not a big issue for us, we're just checking out implementation >> options. What do most implementations currently do? >> >> --Dale >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> From Bert.Greevenbosch@huawei.com Sun Sep 16 22:36:00 2012 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 72EA021E803C for ; Sun, 16 Sep 2012 22:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o33iDc9iGmK6 for ; Sun, 16 Sep 2012 22:35:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E419021E8039 for ; Sun, 16 Sep 2012 22:35:58 -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.5-GA FastPath queued) with ESMTP id AKS66352; Mon, 17 Sep 2012 05:35:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 06:35:36 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 06:35:52 +0100 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 17 Sep 2012 13:35:46 +0800 From: Bert Greevenbosch To: Michael Angstadt Thread-Topic: [scim] Upload of SCIM/vCard mapping draft Thread-Index: AQHNkpyoVLptjpA+IkGEfF+bZj9em5eN1tvw Date: Mon, 17 Sep 2012 05:35:45 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB6290D1383@szxeml509-mbs> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "scim@ietf.org" Subject: Re: [scim] Upload of SCIM/vCard mapping draft 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, 17 Sep 2012 05:36:00 -0000 Hello Michael, Thank you for your comments. Please find my responses (starting with [B]) below. Best regards, Bert --- Hi Bert, I saw your message on the vCard mailing list (forwarded by Peter) and have some thoughts about the SCIM/vCard mapping document. =3D=3D=3D=3D=3D 1. "id" --> "UID" mapping (p. 6) There is no vCard-specific format for the UID property. It is *suggested* that a UUID be used and that it be encoded as a URI, but the property will accept any URI or any text value. Here is an example of the "best-practice" format of a vCard UID: UID:urn:uuid:dd418720-c754-4631-a869-db89d02b831b However, the property also accepts free-form text. In this case, the VALUE parameter MUST be set to "text". For example: UID;VALUE=3Dtext:123abc For SCIM IDs, you could encode them as a URI. The URI could start with "scim:" to show that it's a SCIM ID For example: UID:scim:123456789 [B] I like the usage of a SCIM specific prefix to indicate the conversion f= rom SCIM to vCard. It maintains the information that the data originally ca= me from SCIM. I believe that there is also a need to include a "Service Pro= vider" specific part in the URI, as the SCIM ID is unique within the Servic= e Provider's space only. (See also next paragraph.) So maybe the vCard ID s= hould have a form like UID:scim:[serviceProviderID]:123456789 [B] Conversion from vCard to SCIM may be done similarly, e.g. by adding a p= refix to the vCard ID. The SCIM schema document mentions for the SCIM ID: "= This identifier MUST be unique across the Service Provider's entire set of = Resources", so as long as the vCard ID indeed is globally unique, and the s= ervice provider uses the prefix for vCard acquired resources only, the rule= should hold. I am a bit unclear on whether the SCIM id can include alphanu= meric characters or is restricted to numeric characters only. The examples = seem to indicate that they consist of hexadecimal numbers, with dashes at a= ppropriate places. [B] The above mechanisms would allow looping. For example, converting SCIM = -> vCard -> SCIM would lead to another SCIM ID in the second representation= as in the first. This indeed reflects the possible loss of information in = the conversion process. Of course this kind of tandem conversion should be = avoided as much as possible. =3D=3D=3D=3D=3D 2. "meta/location" mapping (p. 6) Could the GEO property be used for this? The GEO property holds a set of latitude/longitude coordinates. [B] In SCIM, "meta/location" contains a URI for the location of the SCIM re= source in the network. It defined to be the same as the Location option in = an HTTP response header. =3D=3D=3D=3D=3D 3. "organization", "division", and "department" mappings (p= . 7) The "organization", "division", and "department" SCIM attributes could be stored within a single ORG vCard property. The ORG property can contain not just one value, but a hierarchical list of values. It starts with the broadest organization and ends with the most specific. So, the "organization" attribute could be mapped to the first ORG value, "division" to the second, and "department" to the third (a "division" is broader than a "department", right?). For example, if organization is "Google", division is "GMail Team", and department is "Spam Detection Squad", then the ORG property would look like this: ORG:Google;GMail Team;Spam Detection Squad [B] Excellent. We can indeed do it this way. =3D=3D=3D=3D=3D 4. "manager/managerId" mapping (p. 7) The manager ID could go in a RELATED vCard property like so: RELATED:scim:987654321 The property can also store a plain text value if the SCIM ID is not encoded as a URI: RELATED;VALUE=3Dtext:987654321 [B] I agree that the RELATED property could be used for this. Unfortunately= , for RELATED there is not yet a TYPE "manager" in vCard, so maybe that sho= uld be registered with IANA. =3D=3D=3D=3D=3D 5. "address/formatted" mapping (p. 8) Perhaps you could map this attribute to the LABEL parameter of the ADR property. The LABEL parameter is used to define the exact text that should be printed on the package or envelope that you are mailing. For example: ADR;LABEL=3D"123 Main St.\nAustin, TX 12345\nUSA":;;123 Main St.;Austin;TX;12345;USA [B] Indeed the "LABEL parameter is appropriate. =3D=3D=3D=3D=3D 6. Description of the "N" property (p. 11) The "Notes" column in the table describes the N property like so: "Additional analysis the N property may be needed, as vCard does not provide an unambigious separation of its components." I'm not sure what you mean by this? The components of the N property are actually very well defined! They are formatted like this: N:Family;Given;Additional;Prefixes;Suffixes [B] Yes, you're right. I was under the erroneous assumption that empty fiel= ds were completely omitted, i.e. that ";;" was not possible. However, I now= see in some examples that there are occurrences of ";;". =3D=3D=3D=3D=3D 7. Typos Just a few small typos I saw!! :) * p. 14 - "CATHEGORIES" should be "CATEGORIES" * p. 15 - I'm not sure if this is an error, but in the center column, I think "x501Certificates" should be "x509Certificates" [B] Indeed these are typos. I'll fix them in the next version. Regards, Mike Angstadt http://code.google.com/p/ez-vcard http://mikeangstadt.name/mike-angstadt.vcf From alan.sill@ttu.edu Mon Sep 17 01:00:17 2012 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 44C7A21F853E for ; Mon, 17 Sep 2012 01:00:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oflj0LRTyOYN for ; Mon, 17 Sep 2012 01:00:16 -0700 (PDT) Received: from eurynomus.ttu.edu (eurynomus.ttu.edu [129.118.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id E04E821F851C for ; Mon, 17 Sep 2012 01:00:15 -0700 (PDT) Received: from empusa05.ttu.edu (129.118.201.58) by mxout3.ttu.edu (129.118.1.201) with Microsoft SMTP Server id 8.3.279.1; Mon, 17 Sep 2012 03:00:14 -0500 Received: from CYCLOPS05.ttu.edu ([169.254.2.98]) by empusa05.ttu.edu ([129.118.201.58]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 03:00:14 -0500 From: "Sill, Alan" To: "federatedIdentity-members ( federated identity system for scientific collaboration)" Thread-Topic: Call For Papers: Springer JOGC Special Issue - Cloud Interoperability, Federation, Frameworks and APIs Thread-Index: AQHNlKp3Ymm4BATV6UmQXZw99QAwcw== Date: Mon, 17 Sep 2012 08:00:13 +0000 Message-ID: <384D0028F888584EB202C371301DDA7F3B5463@cyclops05.ttu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.118.242.5] Content-Type: multipart/mixed; boundary="_004_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_" MIME-Version: 1.0 Received-SPF: Pass (eurynomus.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.201.58 as permitted sender) receiver=eurynomus.ttu.edu; client-ip=129.118.201.58; helo=empusa05.ttu.edu; X-TechMail-Edge-Route: TTU Cc: "scim@ietf.org" , Identity Management Constituent Group Discussion list , lsn-magic Subject: [scim] Call For Papers: Springer JOGC Special Issue - Cloud Interoperability, Federation, Frameworks and APIs 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, 17 Sep 2012 08:00:17 -0000 --_004_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_ Content-Type: multipart/alternative; boundary="_000_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_" --_000_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Call For Papers: Journal of Grid Computing Special Issue: Interoperability, Federation, Frameworks and Application Programming Interf= aces for IaaS Clouds The Special Issue on Interoperability, Federation, Frameworks and Applicati= on Programming Interfaces for Infrastructure-as-a-Service (IaaS) Clouds wil= l highlight foundational standards and application programmer interfaces (A= PIs) useful for large-scale, scalable distributed computing. This issue will provide the community with dedicated forum for presenting n= ew research, development, and deployment efforts in running interoperable, = federated IaaS cloud systems. Priority will be given to submissions that fo= cus on presenting solutions to challenges faced by current and future infra= structure cloud toolkits and APIs, and on frameworks that allow their use a= cross a broad range of platforms and user communities. Accepted papers will be published in the prestigious Springer Journal of Gr= id Computing (JOGC), which has impact factor 1,31. Link: http://cac.hpcc.ttu.edu/jogc/cloud-interop-2012/ Special Issue Guest Editors: * Alan Sill (alan.sill@ttu.edu), Texas Tech Univ= ersity & Open Grid Forum * Gabor Kecskemeti (kecskemeti.gabor@sztaki.mta.hu), MTA SZTAKI, Hungary Editors-in-Chief: * Peter Kacsuk, Hungarian Academy of Sciences & University of Westminster * Ian Foster, University of Chicago & Argonne National Laboratory For further information, see the attached flyer or visit the special issue = web site at the link above. --_000_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_ Content-Type: text/html; charset="us-ascii" Content-ID: <75CE3F20EC63C244BC5F2D339010BC12@default.ttu.edu> Content-Transfer-Encoding: quoted-printable
Call For Papers:

Journal of= Grid Computing&nb= sp;Special Issue:&= nbsp;
Interoperability, Federation, Frameworks and Application Programming = Interfaces for IaaS Clouds

The Special Issue on Interoperability, Federation, Frameworks= and Application Programming Interfaces for Infrastructure-as-a-Servic= e (IaaS) Clouds will highlight foundational standards and application programmer interfaces (APIs) useful for large-scale, = scalable distributed computing.

This issue= will provide the community with dedicated forum for presenting new researc= h, development, and deployment efforts in running interoperable, feder= ated IaaS cloud systems. Priority will be given to submissions that focus on presenting solutions to challenges= faced by current and future infrastructure cloud toolkits and APIs, and on=  frameworks that allow their use across a broad range of platforms and= user communities.

Accepted papers will= be published in the prestigious Springer Journal of Grid Computing&nb= sp;(JOGC), which has impact factor 1,31.

Link:
Special Issue Guest = Editors:
*&nbs= p; Alan Sill (alan.sill@ttu.edu), = Texas Tech University & Open Grid Forum
* &nb= sp;Gabor Kecskemeti (kecskemeti.gabor@sztaki.mta.hu), MTA SZTAKI, Hungary
 
Editors-in-Chief:
* &nb= sp;Peter Kacsuk, Hungarian Academy of Sciences & University of Wes= tminster
* &nb= sp;Ian Foster, University of Chicago & Argonne National Laboratory=

For further informat= ion, see the attached flyer or visit the special issue web site at the link= above.

--_000_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_-- --_004_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_ Content-Type: application/pdf; name="CloudInteropAndFeds_Call_for_Papers_Final.pdf" Content-Description: CloudInteropAndFeds_Call_for_Papers_Final.pdf Content-Disposition: attachment; filename="CloudInteropAndFeds_Call_for_Papers_Final.pdf"; size=53115; creation-date="Mon, 17 Sep 2012 08:00:13 GMT"; modification-date="Mon, 17 Sep 2012 08:00:13 GMT" Content-ID: <0CB85F818ADEF542B0BD917E1A9EB581@default.ttu.edu> Content-Transfer-Encoding: base64 JVBERi0xLjUKJRXCujEgMCBvYmoKPDwgL0tpZHMgWyAzIDAgUiA0IDAgUiBdIC9UeXBlIC9QYWdl cyAvQ291bnQgMiAgPj4gCmVuZG9iagoyIDAgb2JqCjw8IC9QYWdlcyAxIDAgUiAvVHlwZSAvQ2F0 YWxvZyAgPj4gCmVuZG9iagozIDAgb2JqCjw8IC9SZXNvdXJjZXMgNSAwIFIgL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSAvVHlwZSAvUGFnZSAvUGFyZW50IDEgMCBSIC9Db250ZW50cyA2IDAgUiA+ PiAKZW5kb2JqCjQgMCBvYmoKPDwgL1Jlc291cmNlcyA3IDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEy IDc5MiBdIC9UeXBlIC9QYWdlIC9QYXJlbnQgMSAwIFIgL0NvbnRlbnRzIDggMCBSID4+IAplbmRv YmoKNSAwIG9iago8PCAvRm9udCA8PCAvVFQxLjAgOSAwIFIgPj4gIC9Db2xvclNwYWNlIDw8IC9D czEgMTAgMCBSID4+ICAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiAKZW5kb2JqCjYgMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMSAwIFIgPj4gCnN0cmVhbQp4Ab1d25Lk NnJ951fwsUZWl3hnld/ksdbWhhze9XR4HWH5QTMtde9FXa2SW9b4631wOQcgiwBJSeHVRnQNC0zk HZmJBOqH8o/lD2VdH8/natDf/nQ6VvXpVI6D/3D9tvxT+Vx+9vbHuvzwY1nZ/378gHerY9O5f5sP ddcf6+o0lmOFN6tzV3z4vvyH+7J3b/g/99+Xn93f18eqrMv778rD3W/9vzfF/V/KL+4tcVMEO1A0 noEpESxXECwMguWbMgWw6c7Hcz905XDujm1z7vIAC0vxf5aHTz75pHz7zRvDv/Lwt9nf8rs35V11 7MvD5Vr+wX7GKI5++dYOLw7XH/lVCXBvyv8q73+/THY7tMdz141ZLIu5XHJk1+fj0ICPw6k6dhD0 EtlzgCD7HTF+uf7ZE/386OgpD9fy9/z68np9Jr2OO8WhvIgt5T9xoMA8lG8v33uQL6//7T+FSSL2 FHO1bSG7ZoTa5qgpF9lTLKpZ3Y9Qhr4vh2E4jqtaYe2gmLCHPPkwI2TKFKjml1ICfXj99k1h9aq8 PEOGabVo2tOxrU5ZLBeE+OUz2UssrxevlBAiMXxP3lO7/+yx4ssfc6i1deM1NsPBOW6HT9OG2tb9 LwCYMYG2Pu0HCBn/jqpL5j3wg1hHDpGDl2ewqkga9whhD3WdFWOsvdan5Vg1tnsAOp+Wc5LtOGwC WMTLQswqcYYWTpb9D5l5uf5V+m90Psmtrj1jpYLD2mqahlvAhWr9/JBT264fjv3YD1noN2qb0bJ6 PB9PdXUuh745nrY72s/JmJeXYH9utaFLIUVTbSsOq07jfOyATRajoG5a8bSOXS+PN/KkXKnxz4/l gpf57k3hlkWiTlKoDkEFtFRcrjl5tWNzHIcKtuPZuylgycirHfv9AKFeX5Ik/n1HARptdgt7YYK1 WTxTVcfqZNbhjHoEYbiAC9O9/Zt3xpfXBzAtvUR0bXeszlVe2jmFNpFfXS7FiufmWHcjVh9YZK01 ssjGikD9ifrKvy9/79fIz2Z/P3gayVJqy/HphR/590hg/Pt6pE49vDq4xeEvViQtorJHvscp+W/a Gtia42oLaXXtAKv2tG9Su7vM6ga/07XtLnjgpcyNZJNoLOjCf0Ht2jOivqaFVkxktxbnp+NyE4F1 9TkQsBRPxnps17CmqhtIgLF5Mi3pmvo49hF7lqBvUuIaStu0yJWGdjw2xh03DSLhkzNLpEnfmWSo qBYVnsnR0PTu3ZXcA8lRgeQoEDi3/rpvkW6ZxWETRL9Q/8bZVlqoSra2oVfWa8kWtO7cVyasRsra y2Wk1G49MBHA/jweh8TqCrWbByb33tM80V7gpO/6tj+e4hSHX9I5OGsrFErQWUQvL0fzbt2Ohtkl 2k1YHBYWym3huANL0//4aYnl1RPxS4PUkIGaDCSqDLTIiIZzU64weloYYIy65IGGaj88EEhfMTel FkF03dTnzQj6sFCMuglpKP1UiEpWf+NXqeeHsNIvVi4QQ5+HNovg3IfBxX/OOOI3DwSD8ZxQXdho jcBobyAIAtq+Ow4IknziWRzI3KvivPkizxEhJAxw9BLKK9B5QddzCVNv00qur7RmPnm9Yqp0hNZW /RHJLBRrE5dYEstoanVG0n4DD4FxVSFOu/9w4w4n3uvwDWhKWgHKOkC4ziI7V7JDZoVqmxYAkZvm qL8BCFkmMWxOKDyNMIMMO28A5jBsGwBsu10AocXvaFdUtOtPjKaoIfzGOG6vY1+bQN8VZ6iwAvT1 m2ggAnTnnl2ADumiAhh9771KoRCO4/k3GvtExB6f+G14QjWGIaSzgGDqcJOmrrsUQIXwTDmfDOry +vxAgjkjcbjMKn2WzrRB1Qh1RxRfyn4TLkp5frTJI7jI+YlPwOxqcqHA6nocj3Wc+Rue2odhDd/r VZE8mJqcA1MeXlwy7DTiey9y/qX+wEnpBTLttgTneR1Qm6vhEm1fh/VBbpkxSHFwGunZ8Kr3iZek +0q1ihDVl87HeiAcSN5fTfE3rXe9qbH1HYwzyLpY309Iu4+gyNAiU67fknjB2kU7mUoCSBBLrgii YOxwUt2GlwjkfYBijB6l7gDkgRIXCtRflb7fq9xNyZhQwmFRHIhxtjp+1Avl4Z7B7WzmCVqz7yJi UX0O8arnhGIg91pxu+NBfK1JyJOqNBqhR/J97D3B6oZWmtLrMxHm6x8jkDfOlIOeMCitnUGZOqTz Ca84X4ugTKJKsiXeVAjOT1Y6eWLFG4tDZFivJM9pnfm+PMx4HfydlgHrgFoHjTNNMhn7nZEE57/R PXLzkR8ucA+mOMdVyuHyDmK1z5a3e4zQ3cDZxo/zh7QKKyk3LtoCCi8vbQbx2+KQ3xaKORdxdqPc Yedmd2ejE1ngJxksd85NEhRAQcIJaW55eOYoiTZ8dysiDmaccYVypXW4qVBW7mt4WE9LYmWfxJDQ 4SfLOIef9Pknzk3JXV6oofwGhDrhRu9T620G5GkWTJWvLx+TsAI7OI1EqQ+XK1Vdyhxeo1uyluGI ur4+y2fEwqDCS2KccroH5oicOfbyYKhOCyM4lLqLiv2rJVERSVzEPSUyjviQODmPgk02VCyytec7 sxOHQXRREu0rQCB3ct+Kpx/1iewmTpSeBrg1x73/BzoPLWoXfSIg57HdeFkCxUG03F+/KLix74mB kbfHV35LKuuconuDM16WKHx9T0o4tyjSB35zedajCBTBP1Hx+SBCUCK9kPEh/opArezVBIWq6qjG Ps0QF1aobZ7KLfPOOFoX8Pgl4EJxKDJZ5AjEYV4j+WC3f+JoLg7iEOHxL0UamgciRnsgYiE9ITnJ l50NGAzeO90yHzno9SrXKlP3+IUQ23ksS4RmE8m2MBBWRAOcXHj2o9HDQR0Q/uRGotIwBUhso+0c MZGALpLGXzk/v9KkeElu6aY9QlrUnXzRe71w7bZMnRd0XOrRKBOVo27SDecc79wwciW8avYlIyRv dsJqu/HW9uU2JNdrw2bntTshz1wBOF8ZpQgSLf0F9U7Oa7ZpbWkvZA5SfkrLSHbKHpoD/14EmmMj cJyeSmDTSgcv+BYO4vsh/eVu2vUirdGH29HhyfvrhdK0BmdmjPQ+WHB4ZRrlORQVBxCY48okHiaj M3hZhZKq32hRUHX0QJgdho2h3S0DryVt0ydexYHo3SYjFAm5LwKOeZVHdtx257LbgWyuTyNQD56b 7ZAt1G8DiL0vUyLeAhDR5Vc+haSsbZlAnq+pOqNCM/6W4i+5aCJf+xLZS3A0F6NxM2D8CmU3fZvI SU37XVqTGtNy17Rlt4PyHCubAaXZU93sAghWkmbnSS21UbJOIwqj+GlWC/MvXq6PHKDo+H8nwgoO h1y3QVCaUV01HvtzM4qwpQxkIUaxCYRHS5ZF8dFlAofMzF0Nlo61Zt6inblqt5E1Etp9ACGjJe9B 1aQEi8NEgr+MYtXTdmnl3YZ6Wocy+taGX1C8rkcmLHThQ9AjY5H1MC5FUlHjoZwnlcBEUg4Un0xD Mw8StdjbwlPUY8vJ5+Gff31BiFkH0TbocKxrBCw7WJfzEG0zAuAZAcsOgJGHULwbsdnHEyFvpIHR taqqSKcbvUxu27jec0lVots0isNXIHAYyllOqJJ39CJ1Rt/pgylPpl1Cj771AQ1Vu3iYE0pft8eh HvZJGUIhlYZ3aXTDgo1C+Y5y9qKqW/aZbfCSNUbE3Fc6Grp9KkA0WtUGMZnaoRz+5daYNTiCNA38 aocMWaESJQWf7ewz6+UIN1d2njVLy8q8tSMnyWbsjuMJfY85gAvrFA3j5xudJGH8wmXSnmomrc7r +4eQ20sIvwnZRCppHWlPaHhFKwbR3rLIQQElHmWPSmyJr1nYM5uGxg31Qw9/lJeA7/nQpqGtC3mC 731sIdlHykI0nqVtZAh5Jxo09JHqaxL+NM+CXSHUNJX9jUwjdBrLNG5t0Rts1ymfFuvggyHKfWkM II1W3WNfqT8h4PdoQafXt8MAPbWbXg/18XQeBgHcSCc5/nQhZ/kkeNeFph00+JnGN8RHAf/140FQ siT+aNs6jRN+rMGzpcEUPDQUolkD7XzbEJTKUt7OWJ0o+ewnfiCr5kriD0qETTEOpH9wxSmrPBMH mVaUBm2K566C89unv0uV4PQsLarUzdAEbm3RnpyLbevxOFbortyJNhmVrXSF3akMRehSq7sOPj6v oPOaj0o18jjBpCl+il1D7NKePKfQnpHvwdjXUFHH3OycAqfj31AaopfMLxtdV6GR/Rxsa4twsW7Q ESiaJP0UElfvfDmvM9W3ugka/GuX7+5kNroik1gCuLB8TyzOe2nSKN7aYkFarbScmL7pHRuGQVU4 0941uEb7PpxBW3LmJarnjTs5E62hFlUPtVgBOLcQaoFPYlt0byrMjHI3RpvUUeUfrlSaZnHToCN9 xEGOPXjlCG0a9Fu245gFuKAvktnr3I2TBTebgsZXoKl8trmvp6b8RFhaTGhNZFQ02ofjxUEl08Wt 09CkYedmnQHbza7yZRAyUzOYotJzZqLE5ySPqhphZFJjL7qFqKAba3MYoptzGp0DqY7GSch4+BZT pVZ0Y/Z9W90An58ymesr+TrdH/Sc2rrrZs69mTNbG12nVIdWMGcpd3mInKvgm91ZvZqSBl/RQETZ mdi9HnDsZ0A7NEnY4jfg/T+HKtuSq+YxamD74kmMHmiF0Fj0kU3rNLbGZ9+es+Q5e3q06U7Hpjdu b4cEst6gR2DY1MMugOAHiZ6LRSnz97MiFweKSzQzbhlGzlJ8o0muFLrS3rNFUQ0Bx0nkOXGvNh4I A6pXqgnWRt3p+W241Y2BvRvVbbGOMS3ZWe1RfCZz9vwtguWQiRSZ+kVIm3WLFhyHTooz6W1Tc/o+ HHCbbr6HtVeNqiyVKOelCrg+0N6snMRAe4yh0YCj3ZDQIOz7TievTwi42QyzPZtDD9/pCdjox8jB h+wZuNoc+Tobk9oBPWejtTnDMyK73AMwili5cLmtn7SyNqiz9s2AyGAH4pjn1t/hlgPau1OySB2N guLIeiRrI6zZo7SKYPXXfKpqmyY9759JrM0t3TzU83mh6nZHxxeqLHYkgEKno34JcwW8GUv4opYF IJRkpELcWpxD7lEhENOW5ZsXQqiNiznsAb31XgVz84Ic8pagCSin1aPG2U7UCuFLPQZbrOZgil6p GKbGWadT32Ix3gERNN374plVnAbJOvovJs1Q9lmkczrbQqFSJSQjfVCXg3q/sVYXd34WDRPEpxzL GqzS/WBi7SC0X1XXahD11Th+KIBbZACOCe+VomdodJ0T/HQRQ1wY7dhO66DZhYmmXEurVXtGSIOj NCJpaYmc5yOH1xec403pVVebFGcnSHAptFIay/Yc4IoklxR9x4aHqFmDqxQ1jQwiGH7vVi0/R5yL Z4LX4ANwInPrMVHQRVwoJPYAoMYYIrn8/Q81blRpbBrqp96oeDxHnr+toEYUOphDXu0O6NklE+fq zgC2C+Ayp/4uZ+C4TOrYDmhe2IM45pl6/TssvHGu4420OCxWRcJBnrRRNaj3oeAIo9rBUOBF7bRN ow4rKrBVe+AZuVV6UQ7hEkk94/dyCvgQ4WxSovgkLQ6zD6dIZkuOYB5WuptxlpfMtsHhyp0As1V0 c+ijqnG7Abmax1BV9BCxaHUhaxTnqnhiAxfHekmDkbPeWjoHPec6BRadnHCCKg7ZHLNDztScTPy6 w8sc0NCVdMfY7twCcFKqyFm3aQsb4DOyGM6XDGi3WjMVcyWasWfsz1YUglM2+ps4LBPUVkoho6BQ 5/Kj115eOcwVCUNxeyiGUPjXaIEdOwuR/LO4X9zv3kVvcGofoWNGFM5o7eFmLJGiV0NoreCXsDQG sWnoAafrIDOi1uSC+HNiBtkOHQXVwmIBhudBaFXkGMLUy6GDxgfpdhbKQl0h4IJjl1RJECa98WK+ OS0YOz9TpYycX9AidI3taCg0ZUxX8CSK5DOdB1uEOE6KwQGhAHPbFDEHhqgF/wfLHfFzmAQpXszf J5KfGhgObzISeEVrw4w9DUqppxGXBLSePQnPO3Uhd2mf1KCr+jRCAjmACy5EfciXKxn5UIrcTdF1 tvW1hVk3dbWTUKhWyvlKsdCkmjzhPCc053wDQNyQmLoYcg4QzvdPXt6Uu/UDtqSq1I0cpRq5ocVh Utyq7TtULJ39kwwCXL327I9uutMzDoAEyck4Of8GOMIvPKLS2jjJASRdP1PH+YAA+ZfPpy7OUqUc nYY1hxUwIAOca7Zv+wwl7Le/3A6fZDEOcc4h30ZfbLIbZ+eczBVV7GSqKyikISN1qm8+O469kPbw FWdPHEtJu4Sgh7hIcUcrixSFRJHX/Dedm63RoxE9qqGEIc53qYlskXa8GyWGiuXDCmO4YCd41EkC KomwJBbz5kz73stKpxjOzQ7NUDaeQ85prha/KSThwAeRxlrEA04q98ke56yinPk8cMFP44zTkkWJ uIXePrrBJVWQN5csFI6r0kytkdRsEiQnsLYLix1YsBK5CVm5Jf3NeVETwp7GatwFEF6U7LNmP2EW Gaz2URIpNwh122JOKPOFm11XlUUCD3dwfCxlDkTX4YLTMSuJSxq/Gke0zjXuR8H21+ZWg5wEauNA 9gKEBKRV5K88odQM6VqaELQsom0RvV0kJBHKzLaC0yu8uait77t6DeA0NsIWRipkaEzetwZwvsLn WG2u490NEKymStMpmrqVVEtyENvlI5gu504aYnBaRi0uweux1yqWbjL3TArcortkP0AYbEpGYfUD b7duxedkFADiyj2zqbeFZMhIOfW//Su3YPTIPynCnUJf+CDwHzm25JP/4JPP+eFf+EHwvvLhCN/J OjRbWjUVy8YT5O3Md18UC/dJqeXM3t5+D/RT7Df9EmgvbQR8L7e+fPsup4CNucUFNddd8LeJFzcM mu2jLQj/v15gj/2EoUWHYuMRzLvFHXcqmu3TrcXy3CEo5E/nbsCJhxWAUz+bs2GsaKsA534WJqfr 9eXwuBSFTJQL76uuYmFYq5fia+flVfkeISYWbJcWYFDahzboFj5XaH34rdjV4ErWVYAL7IqiSa0Z JG9p7SZNCx1dDfq8cWtTu0bT1JGA80k/gs0vhIGrOiWA9ibRzNqNjrA9AF01Muc4TH1kC4YTrYeS Ss3yNRFuZlBIbsk3gaIA6EPJ8F07kdRWqq/yZ8o3W7nt4MTrM/odVjR0EomBNM4WCmdLIYjPELVR TFxN4uPMB4SlzadDm3Rfjc0achO+5wTZ40KcVYBz88kBVMRQ4wqjVOH7BuBdelENDnYPwE0OdgdA CFghyN5L8Owd8wpXcvfBU0Gvy9fBG7PoQ3rNQJhvBZOg3SBV1kNqWviO5ar47LN8ISrT0mi+yokW 3T+rQgzL+TZf/liGmcMvvhBkcLlO/Zf37nB/Oi6pQACUU66wq2J7zEy7C2cmLsQt35RvbKMbkZNx tk3RUU7zeKEzdgs3l/O3BR97AOYwVPCxAyAY/IWP4H8O2z/kMSWMc2uKD2ytMCjB1RQZ006vhtSb DmUWsg1B4K/ql6lx59UE4BbBgsqFMsVco9ArRkP45QuBWyT8jRqhcItEV9YsYwpPtAWnVs44lrug AOv4X8K0uWZetOESpEGBBZO8NR8Hae2qA8RFzn68Mi0F7zdLQU47ZT9IhFL3st4A3LS27AGYw1D2 swMgNCusDuQ1nftcwfjcjQvKUVJseRN0qsWxQXmktIKjgv31MdsY0HRIpFqTAAWS160zI5QGbT99 iwI1AW60ThKlJUwf6IrogfhvvqEjtR+NbVzIcu1LXEtt9ogr+nEWAuNbgaea3/o35/MoPq6Spngl UMQnZ3lOgLZPLO0x0WiM333DMZA9LNwW1eHuz60n77etXHsAbrK8HQBhef/OehLlKO/5SlPkMQ3M nma5OXp2Nr9xUvv5l5wdQpNJZI756Yk5GRVEFXRpXH56rJG4I9z8JuF2AWF6qZqSpMXTU37lIJJ2 CybNiwYHt/vBhGkZXsz9dMQLiiL8cBKNi99A/2VnSCUdetpLC6MwKI1maxzNDM11z5XRQXPr+QTg Rs9FtlL2i2kunVfsOd7HF42r54RuJEt8hzX5NHTwsjsUZpuLMNdBb64lbkn89gDMiAcVP19Z2wEQ avk7uggyVkajDJ97C0HzcopXm75vtK3UHo8lVzE3j5wzNV1bTY+jIHsAgjDqm/b4FULO7U19iGBB +sfmmsr8HFwLncoQFqdna7+Ag5L0HoDpLrrMvjCN71GhsBPzbVeYNrrlesw2fMa/oEiG/US4wX36 9o769pXPqj7nA02M8N/5PHjiH6KFykUH1EJK0TRoZNBEhaU+4V69nWhG7enCixZCfodr6/hNFpWu AyrmCBZR2WIZsSJLRFdTYEzTbAoJdY8fLuREWzx1zvvh6sz9AIG5OJe7SdiJGkPTBPX4KZO6PyMK z5veJPzIERTqeNiCCTv/0+N8e5xUqOPtAbjJne8BiHgvVXav4b7QtY/K7w6AkCHNbSly9Kn8cpSH 1ie+G6I8aQS9s9KQB1W49dajrwPY6/Lmk+iHRnTzDkfQGGUuKicwlnq87YF+4ttZRUQIjOwNF1GR ib/WssxvVu4GGEnlOV/ZcLZFT0nGRHXTnGE66Xp+pEqWqNlW+Ckw8mPJpcVrov0ZvJzaqwiCH8NM /URqAOj3cu7Sah8MMw9wu+tQnJUBOHcdkNimOGu6wiEPiFZCmcVcnImCtYPFgNq9HXrU86um+SV0 F+vvI1JWzbiD0/MvVTDcFOw9AlrhoiWXxkiaf+Z7D2V8jIizIE7gzDRxU3qQs9ms5cu/uN7hBt2+ wd1I+H3G37bxBA1epu+k2eRGtmj5LoA5O6SW7wL4Nm2HNX46Db/3OJR7AMJsopMF1Pt5i9PkWLxU IhdP1Lj+Dyf7zkJmyW0t2PCDSsuahh9yq5DzwrF+55BrcEK4HxHskFMbkaMFTPPrdFDVnPDLpTg2 qnl+rRI25nJCc8sOEd8CECJ+UIZGZtLsTau5J2ChM8EcTWvMj4dxviVGhbVCdzL8M3+fQnXpt6WO 1WfCHGEVSp90z/I0KR3FvcDKwPyKmvI1IMochiBRW5gYh7p//D/YOu3hCmVuZHN0cmVhbQplbmRv YmoKNyAwIG9iago8PCAvRm9udCA8PCAvVFQxLjAgOSAwIFIgPj4gIC9Db2xvclNwYWNlIDw8IC9D czEgMTAgMCBSID4+ICAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiAKZW5kb2JqCjggMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMiAwIFIgPj4gCnN0cmVhbQp4AcVdyZIc x5G951eEzWGsIEMXc69M6SKIQ41ADUcjosdkJkEHAi12c6ssFlQctr5eL5bnkWtURKNlIx66kIun h7s/32LRj+qP6kdVFPu+z1v523TdPi+6Th1a9+P8N/UndVSffPqhUO8/qNz89+E93s33ZW3/rX/0 +b5v8qZRhxxv5n2dvf9B/eZWNfYN9+f2B/XJ7W2xz1Whbr9Wu5sX6vZb9dmtYWZGsN73ddsmElQB gocnEPyL2r16oW7Amtq9f6HH7P8Ol+Pf3aVvXmTm1vEeDPxV3X6+Pqaiafd9VYmM1LqMsrGMwMFX 7ivHO/WN+3n3N17zLFju+O9H9YN5JPOvk849X7ZPqB3/LeMJjqLsin1ZHnoZRoyqMYwPFOTwvWP+ QmY5rOH44UVmpR1koSoP+6btD8JCpCT5vQeKgheUMHc5nYazXP7a8NxoEVkNi+DPcxJ+DCETqKt2 X+ZdLZzHCC+Ek7qG5eV1Gk6gDeqAuv+JP3hDvci2LRnI3DdlDUfh4L6hAAf3zMAdX6XFDSJHfg4K 2P5ckxd7uCX/uSiphZwB3VXb1/uqfEZ3lUQwxCHdVQpBSPh/iDLq8yw2PJwXLoE+jQ8r/viJ5k39 XHiB2LD2nu2GYxCqZdHsy6o6KI4j0lL4OTg9MjnQek68eSboBL7ghjffO8ieB7kbNLKqrPdNBSSF OM3mISygQuOlUgmOQHKh7KciV7sTb1BbTgPZaiStDjnGhSgfGpeajisDG2I3/IpgduH75AnRFTkc Lnfwrc6nP4oiOCK+SM3KA0GbqpGmdFVRy4iezx10+b5+zuylTSEYsKVe3EECQSjxv+fu4P94QZ3O w73TZCaOmYogsJDR8NKqz54H60ynlYhIo9SwLPt90/WloizCHsCmhmD9KyZV2oJcDka7IcaPd6Gw UR7ge2okpfxyjJ2YL9tc6nwnHw7aY9l38HEH+Lg05QjChrNkdpKDWWhku/NwIkoEd+8IL95Zxd3M b2a70yLhgnpliFHodDF6Rc1NXiElaL0QYtS8Q5axWQFIjEaycUCMvkYwiy0p2iiCNmkBh9s1ioAy THCe0L+hOVNDNGeqlf9+RxjyBgsN4uBR7EbUKD8uNA65MjVindCOYFp0FYoT5Fhx0hnBVIMl2yUH 6ji2YFH7viyqVLaGr03UQeo+HfXcOQGxfVnBOaWp8I6aEQzLD4r9zB8CaYfSTJJvHR0X722HWX5z OIrXWwFirYFYd1eHNC3FA0CscyT7KQQ1EEdu9IRIQ4umxT9QOLCC7by/bpG6FF0v2olx4EHEik9p yn33rIE+hWCUT0kgCGG/oU+hYCnpiyTJf3cB9VGH/kUIYZgXWL6UoKLLcheAaYIwUlsQ65i0rUBE xX1z0BHYjWbDh889JP0bPzfiQPJ7OBxha9xSsHytvSlQQ7x9eHwngrmTHIdv/WylmO3u1OkiouJd ivYT18c4CSUpmzgA0NkOmTU6KRZYYenEI7VDCWOQGknQIZUDYpiBX4Jot9XaoKjrDtrF+O9kV7t9 IasXXFb9vnjWejyFYIhDifUJBMe4pEUMksVJHw7mZ42WXvLIH/II0Ul0S0x5GdJTib5Jn/eAXwLT If+JTlM6QUjBI4+mdhHsElXIRVG9M8ORAXLENg/etslKh70G6YsbKjzNVZMEZ6KNdyFBVgUqzi6H wScIEtQ5NgKL/6YxPMKbWdXDm1HHm3W/OGSS0/mDNANIiRKm4EiW/9aS3RZjjc5/VzdF0khDJiMz A22Jaiw25IaQKL4C0xdNpK+ALl5TEKMGL3HmrC3bqf9gpOMtqoriCzrGAtJr+grSS+AtSnoNOgBt rPRu/jX/267V6qrbt0V+UGRzI85LJDO1WoySG12WXC3+XK32i0CthqkXM0F1heAkEwlppigNxVaF CM7bhTBDadDSwHx5Ly7RW6EUcb8MteOLDtBqkSeHePEtvuuVbYGOhhbXNYLR0iorBI5rBOfSCom/ RFcTBJPFLw2xQWY86BfeEeLnkIOsSnid3ov6Y0sS03ZOpVfl25ZeYYopmcGXCrlCgKYuxFKZLEP0 nsBjlLuAWURPP0e5ixSCAQ69u0ggCHfxW8Yjpg5n8RKMTOpLTEXfwWe4NjvMeDu+l7nGDWY5GsfH hqeeIBt8MKsgG8IFL4xKtF9OGND5zajPpEvCtsSVKwxIqDArBYxk1+c3vCcIj2hMUM9viGQJ+3dn meQ6P06GMGsaYerBudsEXYacWVUcnkCwuAba+ilUqwBqm+oJbAZAIblhg5UR0dOwUbBNIRjg0MM2 gSCM6wvCllH+W3OhUjv0Hr60FpftfiJ4QmiSFq8UUepIk+VfacfcTbE3M9yyoUW40cSAP2S4HnsB gvOwDvG8onh86wQ1TcBr9Vg20elon6CGION9/wSCBnEBfJTARzKXobCLqbN0giEEV0gUkzkM4MMj uC7jZ06jEJxCMMChR3ACQZjoG5ooMcYIOCDWLiMugtzHBMkFUBGl67xTTQLTQXtHpLLpcgJBSOFz SuGifU4IoKVeXocCMIF+kOG+eQLBqyERPYh0NoOAQoftOcftAVV2ZtYzqr6IAlQKwShAJRAch0QG vaMPhYqhMPPLBPnYKLGMDIUaTGqHUBhYwaZDYV+1qOPcKDZCocsar5fMPhSGCc4Ta48wdvWCuWdp DETn7wnSDwMNDRZTEKQQDAStEqE1nWATCKs5QJvM4bXkGKE1nWjQEzyFywDOvCdAuRE9VxnlCVII Bjj0oTWBIDyBVF6EuMx3EAKTYjY2tIZTX9S9bd4hQCXwGsSNdLSei6CE6ASCkxBN6UU6kITPBAXR 04GkEAx2sATwKRSjAZ9CNArwKQQDcPKA18udIyc2dlGATyEY4NADPoEgTFR63ttz6Zy9YlOLrgFT glenZMLAL1zrMoHloLkL7p+LoOA+gSCEuihQTpQdKxZOK8c2tkt0d+AgHRtrCdG8lA8JqtLzfan0 wl3oWvefEjkMIbhGeZ1KLwAPAXDdoc+CybqPFaEneNCLK+MIjvEmfRZB4GduzcqXSuznf1nj/eYL tpBfy0358foPfAxTKIFCENPwfYf1/rVjOap+iRJq0/8/zoAG5j7h/tuqLlXtGFzTup98U0X03Gdd I6X0WtczG1iCcPt+uqtugclXl+1cukBobYu2VTPak316c4qwKLqWh8HPP0BpN9h91PsdarLkkbcy WQFxlF4nSdFL3fFh/5XBX/pAq7u8oztjaCAh//AgC7Hu+dAytXRcjzbGjTi4HFfWewkPsmpx9AZX 1XE4bBM9HMkCr7AVzDTN8y0bWjAXbJeDeCnv/WOCZlLgX/+IsLoUl9ySH2RwXGGHsO3dUVVGz7LB eGTPAT9IvvkXi09vaqzd2UmkMiPSV2R2nPINTs4WDdZfdE2l6gQOQ9vrirYEQWw1SSGIIQsSxOzJ vwiDqra2pMdKA0GDURupvvStMX9MG1zuZC2Yv2v2XukHM5mfG87yadodcSKzBmIA8uOlfFBDyJrg NoSoRhJ+9K/zEkfLTViRaNBDFqZISwZ0vCfYHvQXt4OQN1Ss29LzSmsuecXLyac5wnsBsUy+8Bal a5WG9e+8wKEbocAeMaQfZWKRFk8qHOOjVoB9eLJy3V07iQyERX5GFsrRekjSfkJv0BtxwoesidkP Cm0yR9KymtWNLZOdwp5bfs24bEuPl8Rb+qeFe3F0lBoFQgbJi3+XTwgN+YFFMtZk/cPkYTjxNX5I 3vIPQ+J6ebPdK2AkPopboLRtaDVWZWH3D2J/mqFRwiJ64YqMa7e//V1v4FiQGbthDW7pjRkomqM6 PNg2KeXDDxNiZNF4mxKrsOCExnHKvu3jlBane4ykWdMZ43b3jgM/NHpB9mPrNTnboy4bLDuue1Un DDpUoZRw7tjEDOeeQBBSpI2eJDjxiugTUssoDkpYb5TlNbS+/T8mUc/JCSs6qAE8KrRoxaOQTfL+ eXJDSfMJHS6Ektj8hBW+6tUkKNYcb+tGLLLCL71bKybvH+cGw/k7AcHDcDI+q0TPTs+qWXQPR+FZ RMMfC+9rxGted+Mzv2mR/q4E2OFyXuSKIyb0ZIXWmCFjDdxnkNbAzS3KXMQ2ujfVs3lc1IyNfp6+ mNF29uAfHjPmJJgF8W2RS8lZfE94N77cjpQC+wh7OLSme40QHLMeW1Q8nC/0I3qsBUrqAyZ1uJ0F AVcftsHrC7GP7l2VJpb9ekrYG0OQUURil/LDJOWOpTd417Solyk3ueJfEjQyd69v+9QJW5QFAWrM ypHwyhmNg9/62Y7Gx27eGDNR5qM3ZZT0G8d7RmO8+9ds63iTusMiHqzRqLzGrx0Bk4Vy7xqepMrL IpKgnaKDSxH+RbRzhQZ3DTclprL1UlWOI8aThcKMd41tFd3XxTjuBt8u1YLfPlcG607M6usq4QMh yRc4X6XN206lEATHlLPfjkWzNbGvyvt9jW3ItGGpaERj2gr1U7rgkYveDEe3izw4u4vOXt5WfgBr BYDvybjZ3ZvtvkmJpW+5XgFLiWwQnM/ungbhnk5gNIjFEP/hkjKLUesAnDy8Y5SMf0TJVoLuUdTA PxfF6C5LOomSD6Obcep4uyv+zTq6CVfUL1V69lWjDO7tCx1Ht83X40P3YyP3OMDaRLI0O3qpi+zO 1TFCZzy6SSUC5Hv3F4kMwquN+OZ56otDwzZAm4fQga69xIdtfWU/LF8RDlivyB1RzIL2r5xFaIVZ ct7bj63E3iPPklDzgn+dHFJo/Etii1kEmyAYkYipSOI7z/+1oF2Hw9dQ1Av/emZ4hSr5juPnDVc6 7Pts2huyw5WEisMcNVemWY72P84CV7ZMewvE+ritPrt3F7L3vWgUy6UBC+iVyGfp2V4qyc9FeMex nQLBTLaUFN7Sz6RcONBHNSpaxa6mus2ka2uattsA1FsQ9AEdVWD0827JTqdAW0c3VFWeTjBAz+sH my/0Lqg177vgMIpgro8XiCMIl/MFcz1K+ujDFIEkOhMkyQE44Oim0LLxJ2H596na0UNi36Nrcq4B j3Py9Sgp8C+NRiN4W/slvG530PmOk0VMvgNZUASE6uAScjs+y0O2kzpoNIT7C/EumCAR3lj2KrUj d7ITe7elj7tKfuSQk4fZXIV7btpfcxcpsjV2P6fS10rEEVsjRHo9/ydfFrMIa0NMHUaZ0mP/1J+O JQIQYdpKCZ3sbPd2N7YFfTpjoVbOcyywsbvIy1KRjRjEwSgeKEj+PWFy3lRH3CzPv+KqJVzIlb1E Vr88/Cgu9bwn0mTIpOmKefQ8V4p5PoRtimU1F0K+JoQK8821niyjEGKQsXv7Aqa+6Rkb9Bnbskoi OQKbySu2sVwdcLhm1TWp5JnGbXgjWI6Zm/Fd1sJcEj2F2onTQGyrTmOKw3ET9cZZmE9IgwRzKhM3 JqZrTFXvBCx7zEp18OVFjxMqO/3dOsMBpl8vjqTyIMPxL1vzA7N4r7cMPc26t9VVYKte35RQl+Mj xsDAh0eKuHhinbjz8zj0ixQ2dc3r0vUKI8zq/t67sSgIlegFlFVzkBHCj1xtA4WK6bJDdV5g3W6i yCgfn3PRi1AOzOTkyfBhrjjTEDODLZAcsKF5TgLdUUGrKTraJzo5kGeoXqTBGQpjc5P8SvGgwTJ7 UZ4RnZKkpagPNlm+Zfp+M0qTgOjufUpT0ucPjMtwwaQFGCB56Mz0hDI7lC0klYGkPRd4JfJ4bOJE poSpjd8y0FJmklvIEQ9zDSPlFg8mSTnNgmZAUXLMbg36aKG60JDN2vsxNhbn4eHIVOzTrlWZMMAQ JLzEELRjW+9xBLGtP3blMUxbch0RhIiG5qc+c0W0lD68c6VG0Wcnmx5X6Xj6WEfipYZ1atGrLf81 ByvcBFYX8WSF0rG5loiNQ1X06qISR1RsLVLzBKWr+ob4ikfKa1G/+4F5CaJTxRmLTR5WjSW0uQMt XHMMR8oYoxBRYMI30CCYtP+iluaGCM6jR4hDWZo7I2gXjWXzRWNewbaZsXv1/Vc4VW4rbS2QtiKU H5Ba2fHHJCpBdvVW4hWCG2vcFuy++eZ7OORNdlu9uQN51bOxe9BzAokE4RHfLqpkhpMji5ztNtmv g1EE7qBtDji731vk1cRqlH7Q7V72ROQdlg1KqpotohbWdrRN4S3gmh8y2/ZN63fzhE8cWbJv60M3 HkNwxsgdV3Y76ZKr3c8UqvgbNX+EUf1BudWumD9khJeDQHwzk7copUf17yPhLOoJPee9Zs2TVZUL G0YGtmXAFfZUJBOEdv+wcNJH72hd6q5zP0mW7CyrqH0xsvqgl0jjZJmRmS1UlOKnJOzq80ajW3m/ 2BYVdobr2TpgPYVgQPbekyYQHGc/tMZ3w5W1iuBcH7hKxj/ep8LrpRIE47+n0dATECwCJ7TlbfnH 2pFPEh/Ay7YNlQUOe9FrKJ9roGWhT5ROJag7X1t4KzGD2hwO3ohidAHRyXzFmshs7sJVyysiM32x /f3IXuDy830xmsLmhKAVtF9x8h091J4qoSpIbf8w9ucLYFemjsYERpJS7FTelhQrNGD6XMckh5xI KX5BA7x1jv0VL/hNCn92Frh4RKz39Uv1O753OYpUw0e5NAUcbVnBvyWwHEpsvH/TOQgahzEyiCOI Cij2aCOY5mdOlqu5M9G6MhdW6MSiqKFE972oQB+oYFBb2cptRhCLZlb3MyBOTtPob0KJKcqjvq6R lgS4XcSnm21PUOD8AnPyQgpBiPvTByKSQMcsxbZPRAfLrrDgZ57PTDCAZz1KR0skmmBUXE0gCMnK 1iUKlp6O/z6r36M7Zpwpnd/CHV++2/AO1BrfPKpXJEYivCUNJbrcySTsG/oevmYp+3VXa3P82wZS NThjKm8RNJ20PrbfgSbslGCMxUH8SHyNaJk4q/XE2SmA4qSOJiL6kyNFxUl+waetYH1F5M+d5hN8 NZhZ1cgJO1TpIruYocb5YKw7iO1JxpX/KQSjwJVAENp9TeM+jmqCmV68CZ9fXrGC2Snh1Jq3Aiwe 8p6SSCEP94Mus6y1vSKczvchP6pPYzT/9wBF2riHo8wwK+xnnHoPy7Y3w0GmSKQJ/F+OT7KOXJ8/ OehhlHmsxFm9Aa87YP6AnEfFWbTbmX398Z8cuMiTCmVuZHN0cmVhbQplbmRvYmoKOSAwIG9iago8 PCAvV2lkdGhzIFsgMjUwIDAgNDA4IDAgMCAwIDc3OCAwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMz IDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDAgNTAwIDAgNTAwIDUwMCAwIDI3OCAyNzggMCAwIDAg MCA5MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5 IDcyMiA3MjIgNTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgNzIyIDAgNjExIDAgMCAwIDAg MCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1 MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgXSAvQmFz ZUZvbnQgL1ZIVlBCVytUaW1lc05ld1JvbWFuUFNNVCAvRmlyc3RDaGFyIDMyIC9UeXBlIC9Gb250 IC9TdWJ0eXBlIC9UcnVlVHlwZSAvRm9udERlc2NyaXB0b3IgMTMgMCBSIC9MYXN0Q2hhciAxMjIg L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nID4+IAplbmRvYmoKMTAgMCBvYmoKWyAvSUNDQmFz ZWQgMTQgMCBSIF0KZW5kb2JqCjExIDAgb2JqCjY4MzIKZW5kb2JqCjEyIDAgb2JqCjUzMzgKZW5k b2JqCjEzIDAgb2JqCjw8IC9Gb250TmFtZSAvVkhWUEJXK1RpbWVzTmV3Um9tYW5QU01UIC9EZXNj ZW50IC0yMTYgL1N0ZW1WIDk0IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvTWF4V2lkdGggMjAwMCAv QXZnV2lkdGggNDAxIC9YSGVpZ2h0IDQ0NyAvQXNjZW50IDg5MSAvRm9udEZpbGUyIDE1IDAgUiAv SXRhbGljQW5nbGUgMCAvQ2FwSGVpZ2h0IDY2MiAvTGVhZGluZyA0MiAvRmxhZ3MgMzIgL0ZvbnRC Qm94IFsgLTU2OCAtMzA3IDIwMDAgMTAwNiBdIC9TdGVtSCAzNiA+PiAKZW5kb2JqCjE0IDAgb2Jq Cjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9OIDMgL0xlbmd0aCAxNiAwIFIgL0FsdGVybmF0ZSAv RGV2aWNlUkdCID4+IApzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKG hCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+99 17oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS7 2yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7 yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJ MkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0 tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2 JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y5 95nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlo u4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGit ka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAA hIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6B aQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH 0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgI A9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWY Y5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJu Na4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAa COcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRH chhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mz l/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKI YppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99All JWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWP qkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+ GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1j qLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/ YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8ei sNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq 42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7x jOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2 xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh /QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJ NQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gs WbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/ iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/y geSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M 9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5 Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3Waz rWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czy ovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+ HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHj ccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf 6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZev XvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972 un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg 12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7 vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn8 8ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoMSA0ODgyOCAvTGVuZ3RoIDE3IDAgUiA+PiAKc3RyZWFtCngBpLwJeFTV+T9+ zrl3tkxm5s5kmTWzL0kmyUwySSAhkJuVJWAia4JGwo6IkrApCiUuiMQFtC64AVahWLAOiUBAK2jV Vq0VW7VqF6hF60ZLLW6VTH6fcyeg9vtbnv/znztnP/fec8/7nnc7772rVqxeSDJJLxGIPP/Kud1E +XmOI/nt/DWrvOmytJMQzXuLuhdfmS7b1hGiLl28bO2idNlXTshDe5YsnLsgXSbnkFYuQUW6TNFO gkuuXHVNuuxOEkK9y5bPH2n37kT9XVfOvWbk/uRPKHuvmnvlQqT4PbsVUVH38pWrlCL5BW9/qnvF wpH+tJ0QUxPqeLlbSHfCLZCZQD4nNeRhoiGMSCRGZmLkIfFTokKZt6syX5tluzs+x1TzhdauVc78 yd/ynueZF/d/ufXbVUO3SURrRFGn9OcNOE/jSzWRWRL5dtV/TkjpO/GW878Jh8l04bMBodBTW5cj nCJdwsdkh/ABOYEgEgk1EnK1CN3IDyOoho8Jfx1oaiqTB5FGS5S0P7+g7DBv6He4yn4h/JXtIxHi QcWJ/lyn0vKX/vr6kUzl6HRmoLC47ERdhvAX8k8EJvxFOEHy02cN5JeUnakzoIIKPyImSomH7BT+ TJIIjMjCewPBcNmOo8Jv0P6K8DJZoJz2cr/BXIYL/ko4RCzEIxwUDoy0HBgwmstI3UrhdszJMcTH EU4inEEQyXLhp2QDwhaEJxFEYkLsQYghtPIaYa+wF+PchfNNiGMIyxG2IIiYwp+h/goeC3uEpcSP c28T7iY5SG8VfqykjyF1oPwT1LuRPoIyT3eMlB9EytsfGKm/H+VclLeNpPeh3onyvSjz9J6R8hph tXLeqpF0p7Cy3+2R6txo9yLEEQTk7kbubkzd3SgRxFS4UVimjGA/0jJc8cp0Cqit7/cFFBitH7Da y3ZiStdj6tdj5tZj5tYTEX3Wne+zLt2nWFiHPuvQZx36rMOsxIWVuN9KAIwglhC8CALmfSXmndcn ER9DOI4gkJsQb0XYyUvC1ZjHAoxqs7C0P98DZFs8UCWX1T4tLMJUy8KiAXte2ZbvSroMjoiLBnTG kdTE+y5U+i4c0GXy2oUDjrx0il5X1BmF+eQ6BEayEQcRyhEaEURhfn8w5jkiXESu1BLZ6NnANggb xA0qMd5ILUeFMtKGFeghFqGY1KBDgWdODR3VpevW9eoESefVxXWyrk2nWi5sELYIgkeICbVCqzBH UA0OH+vXVCeQyOPV1Ymt+p36pP6Y/rhelVQfUx9Xn1SfUau86rhaVrepu9Td6l71VvVOtW6requG dem79b16QdJ79XG9rG/TqzwaurNuozAPj0kQSwjdCFsRRMzxHNR7hcsQ5gAaczBtl6GeICYoSQjH kT+JVIWSCf1M6GdCrQm1JtQSxLylDaELoRuBt6ovtJw/h/c/w1sQImg14kpGwnAdI+qRQ5iEkgEl A0oG9DrOzmGEEmIvQhuCoNSdRA5Yg/h8W3ykvQupmvD2MwhMOY+3yQgCOyfPjRwroMkCurOAbi2g ck1tXZnsR2SxWOYE5oTm5M/ZJS4PLA8tz1++S2wNtIZa81t3ibWB2lBtfu0uMRaIhWL5sV2iJ+AJ efI9u8Qtk5+cfHTy65PFOZOXT94wWRgF0A30R+NlSuoP8fRAv91RNspUN4Y9iceZg3gHwgkEgXgQ xxBqEZYjiOxJxB72BGqfQO0TpBVhDoIKZzyB802IeTtv4/U7EFRK7gRy7AftYIZsX391orVuEkju HIQdCAKuvQ/n71N6p3NPKvVJxCeV+lbEvP9OBD7KfRfOEUDgZvNxIPYg1CLMQehGUJHXhVlgDrP4 lRF7ELoRnkQQhdk4Zgmz2BM49rF9QpFsKM3xkNxccBuLWSvVSSwTOGCge5R4mxJvVuJaJQ7KxkmG LycZnp1kuHmSIYIMyyd1OOFuJfbJ+jrDU3WG1jpDQZ0BV7MSHzGwHCVW85h+qsQXKXGRnO0zfOMz /Ntn+JfP8LDP0OMzjPXx81xYuwaWrcR6HtN7lXiSEodlvcfwkscwy2MY5THUGeh2ijGQeiV2K7GT x/Tzp0yNJqJ7mn5OGnE92l9T4BlkREnocH9NnWeQpvprxiMZ6q/ZjuQ//TU/9jxDv6EKS6Nf9gdP eepy6Fk6UQSLo/8eSf9FJ5K9KJ9BuhjpblJDQ0gf66+5nvd/FOc/gPJPiF/Lz3uEtCnn76ATlfqH R857qL9oHu76YH/RWtz1AVJEee/7+otOofbH/UWbkdzVX7QMyZb+EB/g0v6aQk+dmS4mQcb7zich xkcyeeSOE3DlZSiPT5/c1F/Ez2rkNxikDf2BUiQRPspnaIC0Kbfz9AeUh8wjAWVwLhJQBu0kISU1 UpMyeAPxK6m2P3A9rqJ+KnTK81XN0/zByRfU1L/d87dn8HwzUXyfTuzf63njMJ+ufs/rRYM0dNDz 28DTnheDg3Rmv+dY0aAWDUeLBhk94NmPSU6iL6MHPU8WLfY8EVBadwXQClDvqCn2PBiY7bk/hHK/ 5/qiZ/gwyJV44plo7iga55lcs9fTHBqkaJZrcDM5w1MdWOGpQvXoQTpxYK+nNDjIhxLHNfYe9BTi juGAMpQZo46wCqKhq+UizSrNPM1MzcWaMZqEpljj1eRpXJpsrUUraY3aTG2GVqtVa0Ut0xJt9uDw STnKxbVstSK1qUG2KRGVvATSSLEAFWmOUS3D2klmCS2sZVo9TVpaSMv0+uSoaMugZnhqcnS0Jalt u6R9P6V3dKCUZLcMUjK9fZAO86qNzqSlof0woTS28XYnT9dtvL2jg7Ykj80nLfO8yS+n4TkyLp6d VAXqbSR3Ta2t1jLOXNXc+L+JupTKrsbodz/bd1nkbHnJe1umtSd/lteRLOOZ4byOluT4ad5L2w+z Hra8qfEw6+ZJR/thei3raZrK6+m1jR0XuhE/60Y3UsMT3m2A+Hk34qcDSrfJytWApv6mxv1+RLzT 83Qi7wT0eV7ptFjpBBzv4ddq4wm6MTcJKtcKMjfvBnxIX8z0/YtlEmpSLmbKJMrFXLzT/lAI9ytC 1NG+f1QIHfaHRinNe79rDijNh2kH4R0OkxDtUO5DlfukL5Gf7gMsGOnDtOjzg2n8/1tYWP//4Qp0 YO6fFsxvWhho6go0LUToSt66Zokt2TvP692/4E+8wZsUwl3z5i/h6dyFyT8FFjYmFwQavfvnKuf9 V/N83jw30LifzG+a3r5/vrywsX+uPLcpMLexY2D3hoaWH9xr84V7NWz439xrA79YA7/XbuW8/7pX C2/eze/Vwu/Vwu+1W96t3Ktlaj1taWvfryX1HQ0AIE8HmD4D66HL6euoz5W6xymLY4zP9iPnEZGA bemjHcnMQH3SgMDXTXFdcR1vwurkTUZUm0aabD8a43MeoXtGmiRUmwP1JEpsTZc3XvivXLlyFQ+r V0cRr1rNG5HBovVNa0k2Xzy7PVmTrGlKyl2NHZRDbfXIr6Fdlo7WvF7DltdsqNlSs6PmyRrV6tUd qLYc9b/uZ3P8y/0b/Fv8O/xP+tW84dL2g3LNDv8//cJqYBNdhV8TvxVujRR/Xly1GoNZuZLgJisR 0reLro42tNf5yXxIuxSSeTHJQgggJBCmIajILxH/HuFvCP9GEMmNiH+M8CjCAK8RioXiJtvljfyO HbjiYWITygbiFWWjB5HOXZROp81Op00XpdOaujIb2vtrExl1JgjelBxB/ArCewifIPwHQSWUCWXK xTFm/utYSVZGKWaLoLCKRyujq2gUGcqne9XKaBQdeBkVKGFulelFeeRH6MrVBFMBgCBBJ6V+JT8N 98C5Iz/eAFKsugNhMvEguKBdOQkZ/ivCKYSPUpOGz6muIIHU0uGTQhY6PzESCAmRe8kOEiRnaCl5 nhwDJd8NUaeN3E3Gk9fJk8RI1tJXMZsBSBh7QC88oPvNxEpV5H7yLrmUrCAfkJPQmlvIX6gF12mC ZSGXVA1/jLiF3DJ8GL0ySAP5OTlCl9FpsCs0kAmsCDMRIluGjxEryR9+bfgdlB4mH9Dg8H7YIR4m HxIzpPMN5E6o0UvJK8PcShIk88hP6Tr6MWSrLnKrWC72DV9BxpAD5C3agtwUslb1ju4ApIM7yaPU So8Nnxj+O3kWvHQhrnQDuQUj7ifHWInQoNpJvCRMxpKLyFy0XkfepVm0VJCHI8P1w/ej9qfkcxZl LwkajCNKJpI55HbyCGbjbXIKooCeVtCH6V4cb9B/qN7B2FrIanIt6cXId+PcfeQwLaWlzAr5kOEJ C8gMtG0hu3D/AXKcttAOeow+J+xSxVO1w9nDOcN/Hx4mhaQdI9xBnsM9ztI4+uAOgl9YJbrFVaqy oevxhAvIQ+Q4eQPj+Avm/QvyNS3E8Vf2I7ZheNbwnuEPMBYtZIfR5GIymywna8jV5CeA6vPkBfIv +i3Toefr4ouqa1Vnhu/C3IZJPcbeit7TcO1bAaV+MojjbTylmXrxFKPpRXQqXUy30HvpIH2XvsvU zAdW+YmQFF4V/iRWqlTD1bhSLtfkgSWzyBJA4EeY7bvwvHvIi+RlmkPDtBhP9DbO/5KNYY04HmWv s78IG4Ut4jnVzamTqU9T3w73wfbUCLxrx2z+DLPwT5qLMRTQpXQl/RtGvpU9JRgFSQgIFUKdMF3o EG4R7hZ+LfxWXCHuFd9TTVTNVe3VzE1dlXpjuGX4JswFha7mBiYVkXIyCvizCNh0BcbXjWMFWUeu J33kDuDLXWQn5N1BcpS8TN4ifyafAQKE+jDmy3H3K4F1G+kdOO6n++hz9EX6Mv0r/ZIfzI8jn1Wy WtbAmtlithHH3ew4e5t9JLiE+dC/e3FshynoXVBpURxWleGYoLpV9VP1q5p8zQTNPO1vzp0eKhzq GPpLiqQcqUtS96aeS/19eObwWow/RIpJCUa6CaO8Hzi4C8fPgIkHyUvkN+QPylg/p4yqgPE2GgA2 FAFqtXQ8RI2JdAq9GMcMHLPobBxz6Ty6BMcG2ktvoDfSm+jt9B7l2IZn20UfpwdxHKJHcLxFT9AP 6Sf0cwYkZgKwOcQiLMaq8KQNbDxrZVNxLGbLcXSzFWwNIPRTNsAOs7eFLCEEajtX6BHuF34uPC+8 KXwjMrFIjIk14kxxsXij+Lr4hviO+K3Ko2pSLVFtVz2vdqrL1TPUS9Xb1E+qP1Kf06g1bRBX12ne 1AxrQ6BYv8JzHwBMv/vF1K/Tlaps8Rp2AuvCJnSrNtEZmDE1my4sE+4QfqdaRM8IXvoe7RMuF64Y flRoZl8Ly+lMdpT6BY+qGqac28gw3cv+ys6yv4s5dDr7mOaLd9JDbLnQwGBjAE39vZgj3qj6CNaA P5Bqtp4eYy/CcnXj8C9ItWo7PaHazt4gXvEkyyInsKo3sftw0m/Z5exW0i6Wq74ll2PeH1ddg/ke x26hhcKb4nbygRBg/4Z2dS+oxmt0khhkl7EquhcUd4i6yWnaQ7rpPUSmT9M/00HIxHuEn9LJLBPQ SjIDHQVjy2uCj74pZJAOPkYaZjm0jZ1hM4Rn1MeFCqg9x8nvyLVUoHHgzvlfilyFFXA3i4CmNYGa /J6WERu5D/T+bOoZTrFV76huBZ49IhSRqSROOtmrpBpr4wMc7eRm2OiOAAdvIXG2jawb7qULQPen gH4yAr2NxKge1NKKsW0Av8hlftDCObj116D/r4Dqt9B/kKupFyvrGMkXecttYhMoUxfo7604FpBO lB4id6kPqH5PWqmVENGb2g4s/xO5DDznb7i/AxbqO0HZHhGLMGovKHMPzngoNYHIOG4mr1JG1mPM 47DO28QJoLz3Di/FE14OHjUZPPFlcvnwfaQBsJs6fOPwrWTO8CPDl0LDnTa8B/R3zXA/qSSbVB1s pioqloPGvkxfAD/6I70VdHsCeQ/0KERt5BMcP8f4x6meJn3iH0A7a4dvG34LVtZ8WF7vB52ZBOp1 JfkH5m2CcIwkUhex/cPNQjc41Aly8fBPhz00gywZXgbK+wzZpVGB9vQSt2oXcPdWcRGLY7wFJJfG UHupagchcv2M6XLtuLE1Y6qrRo+qrChPlJXGYyXFRdHCgvxIOBQM+H1ejzvP5XTYbdbc7CyLWTIZ DZn6DJ1Wo1aJAlTpoqZAc5c3Ge5KiuHAhAnFvByYi4q536voSnpR1fzDPkkvP28umn7QU0bPRf/V U073lC/0pJK3htQUF3mbAt7ka40B7yCdfXE78rc3Bjq8ydNKfoqS36rkDcj7fDjB22Rb0uhN0i5v U7J5zZK+pq7G4iK6X5/REGhYmFFcRPZn6JHVI5e0Brr3U+s4qmSYtal6PyNaAx4x6Qg0NiXtAZyK ywihprkLkm0Xtzc1On2+juKiJG2YH5iXJFxqjipdSINym6S6IalRbuO9PImnIbd69xcd67ttUCLz uqKZCwIL5l7anhTm4hpNSXMU921MWq89ZfuuiItDPt/0/Van0AcJ0cs79/Vt8iZ3Xtz+vXOdPn6F jg5cI8lCzV19zbjxbYBTC1ffkmxjR3uSbsQNoWGElGdKP11a/Ql1LfUmdYH6wJK+pV0AjKMvSaau 9fU7HPLh4ZPE0eTtm94e8CVrnYGOuY2u/dmkb+raAbvstf+wpbhov2ROT+t+o2kkk2n4fmYhpjzd puSU7jzXMvXCvFI+xsBEKA1J73wvRtIewDON5tHC0aRv/mhMP34dFGclFwAelyd1DV19UjXqJTwi TapCUsDb9wUB/AOnP/thzdyRGnVI+oLwRo4lFxAtCSY3gnTJaDRZWMgRRNMAiGKM45RyRXHRmkGW DHRLXiTQHkkb5nZuR3UMk+/zcfDeOiiTeSgkey9uT5e9ZJ6zn8gxaFmsi7ccO9+SM4O39J5vuXB6 VwB4/BR4OCE5SW34wt8k5WY1LalO0tz/S/PCdHvLtEALdDBvU1/XCM62TP9BKd3OJxTzhraRHE2f iAlPiqGkOjQxANSbCmUOFfirQs2Bpsu7JmCpYYzJrIZ2wclwAZ5jTkG5FPD30tnnr8cL7Zn8WmJI reD/gkGNFgis1FBvc1LqmpCOOzJ8vpHl9f86aXD4DD9LSb47beSZk9XRkadKP2NyzA/KPxheZp/Q Mh3UibVMn93Xl/GDtmbQvb6+5oC3ua+rb+7gcO+8gFcK9B0W2oX2vu4mUKw0+AeHj9zqTDbf1oFH WUKrgeSM1O8P0Fsu3i/TW6bNbj8M45f3lunt/Yyyhq76jv1BtLUf9oI+K7WM1/JK3sXLC+B5WBX9 TKv0dx6WCelVWkWlQinPhzVMqUt3Qh0l82HEVeqk8/0Y6sR0nazUdeDHKUXD9PaR+VIgjxnjmECw d1tFXdxEJzSSjeoq0sJ+RqYjlIiE3CneCKsqIVehPA3pnayKCKifhHAGoQhhGsI8hMkI69CeRLhD cxmZq/oVkVQziR9hEvIB8W+kUFxJfMhP4GVcMyHkkULk/Wgr0OSh76+GP+Dt6MfPCyDtRds41OkR LJrbiROpCXUO4XYyUSTD3yJtxr0bkU7GNVuRH4tgwDhqWNXwfOTNyI/Fs5mRz0RownnfIG1EfwPG sADt2SgzBDOub0DqRMjENQswNRDxEaMMLeEYUi+5RKnh08Z/AoII24IaeokWu9oZRI++BujEJrQA GyDvWBBnkWzE6V8ONCErpCo7ZBUncZE8RS/yQmf1QzsKgsMTaF0RSAoFkDii0EwIJPzv/0qgI8dJ KaSdBLSWCkgko6DPVUGqGQPpZyxkm1oiQ/qph0zVCDmuGRpT+jcGPQ7RN1gW5F8Z+8BfiUGxTdys 8qvuVq/TXKEt1e7THdSlMhbq3zY4jPtMl0t+s978N8vJrKHsO3JG5/7b+iPbPvvLjlnO6a7H3D73 bzzHfWb/ueDXoYcjD+Q/U/BpdHpxY8nN8d+VLU28WP7hKOdoXfVVNf6x7eOerf20TmhY2Li16f3x ayf+rOWrKTMvmo5BMeqCBO1S8bnUkCn7GX2aPcvnkx3tJypxkD37lEAyNDxzgBK7Vq06inZGBFpA dPQKehmxRaUva4ZqLpLO1kwZqiG1yEvnEJXGfWafOYSIukRyziscOyeryLeQxI/h/I2Qr5+BxcMA KDx0aND+a/tXmULm4PDXA4FQuZIWx8vp4PBHA4UV5WRw+NdyHjJ2GyLHaERfZVJNpjWTZbg2GhdX GiDfTh/QCA4j0v5sgQwKFU8ZDBmiERk51+GwmjOuFH9pvZKYqXmj03W3b+m1sDt/2Tn05WmzpSqW jkjtUA3+pfEo7elM227oCipEwhXllYmy3JxsjeATvldgcmUuG10SrcqqSs0blQumVe2oFAI0uNZu r62uLp0xP/VHmn9tkVw9pjRyR+pdPsctw39VfYvnLgWeTKQdcpi0nGxhUgtVG3VOvTfX6PTa69Tj C5c7sf+YWF5/rVMtltEWvpWYnVvOU7nIaCkvkBOReEtDZJ6my9VV0FW2cGx32aqx73kzMw3RLPW4 sroCV6aBFarVg3Sy7B/nyh43ziWIRSXF8ZiGJlyF6qLouKw6na50G2HboIwMChc/Nbo5IOgG2QZZ L41/PTdX0pcCOwZpfIA0hdW/oI+QcfRXWDUF7KVDrlpPi9XqMAzSG+UsuydMw9d3VdCKp8fsX+7p 9jDszRTLzsaaOfbl9g32LfYd9iftR+2v20/Y/2nPsNsnteC8Ad/02QDBRWc7p5w+28n/K6Shi5oW Nn44RTp7mv+/BCJxfJJOS6drT59VUou1iiJsMpZE10svUMAOfyVIL5fGKaBGejpp54oe6stRq5km NzdRVjnKqlYH/OGIEgOWo8IA4qg0SNWaXCvE9Ug4EqpEGg741TnZuVlh3hsZnA2l87FZ05JXddw2 vqkrOxR67Mqpjy9Y96ueXc///EzM/6N566++987BDX1Jd25B6oZ113XUz+rwv3bTorHXrO1bXbta uDykqU0937dkWstE5+03dyy9akby2rX/un7JxrF7ZzffvnjpzjnvP/O7rSVBp0o/5t5LJ1y2trp0 7ZD9qd3XNe2ee8VPyjgNnJ6axNbBephFquXAveafmtnNmZvNLGObzky2wS5GSIZuj9Hfpqbq3uzp l/EF2Xl6qEaZPcxcKfRE2klzwpEwq5DIKD4xOdlWN2Pr7lu49SFa9uV12y/yOSatTy0PTV50J+17 k1bS4asKGz9L3fvi20/2/fQBjKEEY5ipjKFKDhaIhdoJKgE3N2MQWVB/dRkYQNopQVD35rQ/9j8H QTuzKnKtuZYciWgqKistmPQSVrJt4ZaHUq9/dd2OKT57yzrVgsKWRXelrn4r9UqKXhVq+pRe8eJb yb7dfAR3sjbYD+6A3vuJfHvO9I2mSyoPG486BpoPTX3d8cvmvzjebNaOUo0xjjZVO8aEK0ZVNiem arPzJL9Uk12XXZ/dUOQsahrrHNt0kfOipjnOOU1rbStdKxvWTrjFdrNrY8PmCdts97ruadg24We2 3a5dDXsnvhJ+ZZT34okNVWLZ5PLmStERjQTzrJLoyYBjQmWZmBEVPbUl6/zY7jskByzlres0hGwz vJVT7nkrsq3yrdpa7+Q4/AKOTxYnb5zGCQ7gUiMNDQ2dHTpNas+eHao5BQy2jqCwkqax2VqlwAxE iAJo56mPWlM5qvI81nK8zQVJUhA7HEFBySu9K0epYZvhLRzZ+YGrnL9OLv2HaPOXBj0lFepRRY31 fl9x/U1TEuUta1uK3e6J4wrGspxg3Bly55RkqsYUTQw5XP54QYGza9yYypbr8oqL3b5JV4nZTY3z QuWVlWXFjzQGylrDxZ5QdZ4512nMrY+4iwonlkarGtZE80fl5ZTENyXKIvGpuVKJyz7KkpltsDtN jhxfzFlcuIFjd4jcLl4i/hKce4fsiLGY4NV6dWKMeOHkEtMvJ8v18HKhapj2LyYaIUIykOqxxxCB yeticDAtcjrh4oN6PelSUdUvUAkJgsdC5BDt0lLt02r9oBCRHaou3O5pL4szGfaw40zlhZx4aWZ7 esX0nO0E1zrVSWKnT0mnOqWaETJ0duhUZ3oJhcy+Cp85Yfbl+MzMmjLSz9vo2VTm7fTfU+m/Uqap KQN/nqtSe+k28mvIGNPkSAfrsL6QK+isXfbjdkFHiUYUTVoLOWiRM/VitSnHk9ObI+QM0kLsI5vm mJjJbnsIiwfctHPKUCfQ5PQpS5WCJZy80Z4sLB1OrgL+8wBWOJP6qsU9Oo1GH7Jkl1a3VNYv3pLa W+Tf0pZl0GXrqhOlzSvnLN7PRzeN9rJ2WL0FUit7mao3b0HlBhUYAPe0EgiTaBs0ta10Jz1O1SD+ 5QcgB3JCDWoM3K3B5CBWKG0WpmEaUw19y6wwqGF9Dp+iy2Ef0pOo7CKyWi/IOrm6QifXVszR0R26 J3VMtzEzvQx6VkSj/NlK4yHOV0dQlZKYXFdSUlf3vBKXxGR+XWH4FBuHdS+QqbKOqF71LK4EweEA NTAhmzEMG3xKDwnAI2d7hbjQJXQLO4WTglp4mj7BXhUH6fL9J/gTcCYDflJbs0mlsA/O6GGQZeNS OW30U9Ud/5mp+hmuRSYNfyQcUi2B/BgkR/rnamESUferVICSut9gcAxSk2zROUhYDjM53BXeGT4Z FsNmXm2cA5P+Bmwk7IRQag8doW5M7Qg0T18kdfZ8OYU/Nn/whrXyZBoMBP1B2OthBmRqTcjlzHO6 nYI6K2wK6cM2u9XO1D7RPI941I55NNuIXG4mckHqnUedWkQWKWcesWcg4vKKsj9ViExhtLDw+qxy C2dy1lxzNsMMR8KjJCtnaKMqzZzfKSjEJt22anbXQ+sevOX3856//soXmqp6Kle5S+LBqoLqxooJ 5Wz7R7R1at2OF1NPfpY6eM8Hz32V+mj/PXNX7KNVHz24Mu4bOy31EGB0BgtOjRnLJffJ2bKty7bT dtImEptsY2tg9GPGuizY6esgMe6ElC0oeS3yAQD4azhvXg5bWh3yn8tw9TBhE4SqdNpMJmBL6it0 nyhbjEaTbK6ImzaYtpp2mkST3XqEBempkcmN1kyRsGq5tFBbAxpKzVXki9Pn6BfR6AglzQolzNm5 udYcX8U4VsEngD//GTrJl1VzaYp1jc7N0IQcoXrxV498u2nFaDcLhVhe6bXsT3cXet0ejofQA4S9 eEY3XSLfoLHpq6w219hym4zIziOTOze3QFOjmah5XKOWvZeIs7WXWGfbrtCuMq+yPKR/2Hi/eZ9+ n/Fl1cvWX9vetb5rO+n9RvzGmpND80S7ypljz7Vb82wanVVv0+eV28fbN1u3eDU2O2NWhz3TrjYI dqZSw3gIOTRLhOi1RNbp5OzM2l4d1Q0KCTlTUjm22CkXtpj9iJDAxN0+QFmme5DeLhuI+v3WrDlZ y7M2ZIlZg1QjZ8l4KAfxyt5er9Dl3ellXvvT9BusMwOV5ew52DTYwLawo9gGOsH+CQ3Z7jmCDZYL +HyqJo3RnVOwrCS+sE4PdfZAgO7Zr+ZK76EtOnpU97qOkc6ejuipEUbHRbYqJqW7PLXefrsd7R3G mk2Sav0LxhdAWXpWdEJeARKTKBV8FYSkpTJNYIT3gbUxja+ssnKUsHfOuZMwJnm3X7VgRzhkf/3B XX+OT9r9zTg6b9msZgdVpb4N0Xq67fHrd6/uOfzSm1sXL/7JgdSZ0VIp36WehlU+E/Aso5MPk4zh k/2ZVTouXtdkVtXpmjKa9S1+8XUdLSgYXSCXd5W/Xn6y/KsMDSmndboNgWtLfhY8HDxS8nLJicCJ 0B9LPvF/HMqcqC0YpLcN5OdLZJCdGjgep/FBofyAoJJyae4g3XEgT47GyvPgBTUgGQryn6ZLoJbq 2N/gpwkYsK0KDADJgWQmzRykW1Ff3FvMthbvLGbFqD8wR7MBzz7IPpAz5HK6s/xYOYNuRMcdkrOO ZrEse4ITnI/OE5xTnN50nu4EY0N0CvoZSE/09Ira052nuc6j0KDKkpg7nGES1X5fwBf0hXyiWhUy hsMZIC4xsXgedZuQ8+kj82iGrkQdn0c9hjxObaSake3wwuvxA8R6OleQnmg0i4NJQVIunmjUPkUK 4VWQUUB9FFkbiy/A1yGXtzVLqvff9Ois+iPre7vvSn26eX7MZ3eYr7GGChfdF3B4ovde5G3dMeH6 rgeXiJM237O0dfbd20sPXpe8fk9jJK9Iq6pV67cva20ZnZdf58647KbWxRt289U6D9Bdi512H3XL DY+J1NLhvty9QbVBvSHvNvH2PE0Fq/DNEGZ4Z/mucK1RrXVtYn2OPtejwh7dzsDJgAmOaCbJbMnK ybVqs8FnhEHqks1eHxiM6PU5nC5BYxNVqN0x4PX6so5g3diELDnTYKDvE/a+zwcZ5AgdR5x0/IFe zU4ONfoFoBagcqArwAJAh28OSmynj/r4RWSdV5Z2Skyy+49gs+9jBYSnOkHUJHBdRByQpy7oQgr4 QOP4mtqkLYmqoAsRXkgvK9mwgq5gK7w30BvYDV411hdfVlhVsBDK+ivE5ZYF7m5Vd56qswMihcan ERXp8YLICIliBFRcbqTC2otSSzqo7sGNs266eOXaa5eXBByRWMuU1fu333rlM1RUTf7Zwcj2Wwav ONgbGTWtzBWVfOX7N1z3VnWxhsEMQ8nk4VPYSZ8MyeC5w3AMPzmQ5RwHN+eTchQZu5aqhEJdPZEN XYadhlfoy+wd+g47adA7CPbxiUE2CEwlgov/WHYILFsQmCgYVPL4CtX7VI1E/T683rAK7j+4U0/1 9kzVEfYREdjf5Uw4w4ky7Cs7RZX4DPuQZI6wY64enVIkrLOcakWl09G0TLDJuP6FkSnUrVKtUt+k ugledenpA1VaAaoEqQcigw/SlybyW/aHVA22AVO39sSnJ/JUk8P/eVZ80VnSpQerwP7bR0If6Isd 1qQEvVY+0gE1KeFJFEaWJ6719+p7M3sdvc4bQr3hvsTjtl2On4YGMp9yHAo/HXkx40X9Hwy5GpJB 1Qbm0EVyDVZHyBAyttDb6I2GjcbHiXEMqaZw46MT8+fQSyKXJpaSpfRytji8NLIkcR1dF1lTtC6x Rdyi6tX0am8w32DZkr0ld5t4r/Zu872WB3N3h5+IPJEYFA9qP9Z/kvmx8ePIx2UFGoMuUk2q6Ogy VaOWZDoiohJJVkX+UauKufyTZcir01G4tFJZCXHkJbpIlkiFXMHkiq6KnRUnK8SKwDNoELACCiEW ZcStsnWrVbDay4/Qf4ygt6L4K6h9+tTZtFTEUZhy5QfCUVk05vabc0VtTsinCkAE0uTNo0XZhfNI iQVUyC+CLLm5CBTNLZ5HYmZE38lAUU6TOMrjv4JydR9EiQuaXGv6TlH6vspvzTqv8HMKRTc/0vmb xx/79bK9yarJ7+1/btnMtbT0GnnNokW9FaWV09puv3LZDeHxbO9NO2fedLR/xeTtV9xy0aKeLa+u nbty9v63l61vvfzqNa3lS2Kpvzfv6rr+wWtnTahaymVsyMhbhSRWghWWa8HOHUXzDIsrt9p3QtST iSZTtuhNcg5E5/KtOTtzWM4zNARb5e+g4yvqI8wi5wVIGDvo94TnrO/lqQ9CNBeki2J19TwVkmmJ uqRuKEupKCmp55LuHdBVBoX9GE+AzJedvtBz5sWVL5le8LNMgzMrR9JlHrRl8nFlDwoXyR63bINU b9J5IMpXOqVqk8/j6/UJvl877UEu2GNNcaUFugsGOQQxNyZxDbeqCn9Ogn4wYOH/oMlQx8jgL/tv lUbYL/OHKSmR//Of/6ncMDI31awpgqZQT6bTP8tLd5PddZ/VCViALsme42qzz3CtydVQieR/RD6p OznzyyaxvW13zu7c4zNFb5v3Yu/UOTbRR7wUklCruIQsZIvzNhFxLTxQvq0T9mvr6usT9aR1aml9 HSOiXnQUttYlmNjghPWsXtZJ4+i4JaSBNqB0qN7UDM8djetpoR73dwrjD0y+vtLdbIWdTa7UNJeU V2ZMXSyOLi2dMVPfXFjreMLrjDtlp+B0zKwabZrYO5FN3JNV7fXH/bK/zS/67TNmwrdnwPfQZbZB OmrjiN0Mc30RiBkMaIoBcwivYZ0dAooMfSh9UFt7Wvqic6jzA2VRcTuZYmCQXt4kGaHAYYWNaWwZ NVYVHz+heULTBEE9prqmmqmLwrpQTtgbMoeC4fyQIdw4duIq0jJqYh5Rx8Q8oi3Wr6K5HgiQqweI LQ+60OpD1OW0O6QQr5PziDGCHhOqG1bRSaMn5xFVHNsLGVHNKpLtsypn2V3p1BIwoXyAZhaYVlFl 6Y6oMNC8a3j2ux+UGWU5d+I3ejTkSSqcX6wwIzFsrouwaFnEhJdkJRjxQaeqkCwkUSZachTdh9v7 Rqx/ik6Uax2l4SR8xMQHlQiiiKp3dZ0r6p342l27Ur8/+PfUqr+/SrvfpBr6+Krq2alw6o1/pJa8 /zU9+u3rdMrPHz23efIUy939jeOv+sVDKy9p6JB8z7dM6WkbM76ouvc27+iJwrOpnpPXBL1Fd9EJ /Xup/8EvUuVff5i65TnqoKbUP1L7/kof/ppq4ahE96YOHT6Uuv+xCXWjLxlYumHpnXRJz7Smpquy Wle9uLW9trX90KU7FtRfhPWKHQ1VEtZjvJ3AbPuxnTUdzpzU42buPOJyYy/DQ90ulv2s8D6xImgQ MoT3ZauWudyCSevKzSOebngWMUq1JqYlsVoIgp2vHX8tFuP4IZ0+/Y/PaCz9k9ZveuEFCaGUY6bW aDIZpAy3ztPmU+eYsiSH2eF0umx5ah+E5v5QBU8G4u3lShotUdL+gnS1N5yudrjT1Valuj9HSeT7 pKxyg0mPi1eZJpmapYnuVl+HaZY0I7vdvdS0WFriXiP1ipuMfaZN0ibLZvctngdND0r3mx90HzYd ln7hOOx+1fSK9Ou8V9x/NL0jfWr6SPrI/Y3pa+mbvG/cRTpTi5N5oIZjkkie2+3SGTOculyX1Zmr ZRqnNsec7cy5xm2SvJLb5fKbpWxzN/YI4JxhHGQvy2bmhonB7cnbhZcxlYkbpAfkTK1kEnJyc7Va ndaFVzZknQnnsF1G2TzI4gOtbuoeZJ/JRq9sbDOeMQrGn3qv6FPot92BNWtzcJGOa0wc1RHD8iQN 1XCjNpfkNnUaS2zRTdCHojYinabSsf8Zb5LWv1CjqcFfEe0uLBW6AjKdT8Frrupy2x9N0LTeqxiO 9Ex4fOjfl/rHzEvNmGFPjKN/DtB3qjqnDX18cVX+VR9+Rl96uzXiiWlCIZMt/mPx0m+33XKxKhQS S3xFc6iBBYfwuqoAHZ6IH0Kic2N/bDRbL8dnk9nuzeQW9+bE/Y6HI/sc+yIfOz6J/D2WOZpcG1mb eKDs/sSu4M8S7zjeibyTnyFWD7K/D5gWV1ZzpHH5y3kq/y3HWp6QfUWI7O7yMjmQj8iZV94YbAxt drxL3w6+l/ggpBGDNGQok4QctdOR7c4N5ubnxEvKmoKTymfRdvvsyL3MLBGpegadHeyq7q7urd5Z rXXEHWVtRJA0jqA73x4T1UxwW92tiVuCDwTfTWi81XJ1W/V8Nl/oUnWpuzRd8TXqlY6Vzm73quDK yLX5N6lvdt7s3pLorX4l9l7s0+B/gvYOrcnj1Pn8kseZ6wskgtieLSIVUU9Q8BeMLkoIJf78igpd bkG+1ZrLSvI5pmzFNglfK9UVSlLPk96B2rpyXhxoaFZSORv1k+e4aIY77mKuGWLUM7qolE+P1FRh kSHLgvfsFE+KgsgrMwzmciJSr0ghIL8hh4rUWVlsRlEmjCiIDQbEfuCySWIzTF5eNG2vqn6GvkF8 ZC61QabABkwU1pPTwCBo79HOHu51XSoUf4w3PZCc7oCih52Es50reJdodIWihPBNGfD12GmFqYCx pE2U3NoCxlIXKw/k29xU43DanUytDgdDLJQI59vCCRrTlCZowB1OCOW0NCFEnAUJGleVJEgoz58g 7jKhIgETAxgAZwEX/K0VHZOC7q9YsYKs6Lkg6MEhrZOmRTp1wFeRKAMh57YdaJc+rnFC1AspW0Dp rR2NOa2BctuPWiP03948t/fEB0O9iRkha15kSoJNemz+vdvXDV0XmlN1148vev7IgrZVPQeenfn8 lnHtTvaUu/7SjQsPzwhVBlYIy37kKwrZgoeuXvSISaOpvWHK1Xtyv13ufPSa1rumi9hNpbAi/lVl Aq0OUibX69wxym3bMc+9pvvdj5oetRw0HbLotW6Mnq4Xrsu5Jvd2oS/3YeFexz7haUGXKRhFljcB DrSqmFYyByFjUNUB5qT0CKSNloPeB1T5LoEOshMH4NwkUWlQqDuwxbDDwAyDQkyOZevYPlhJaZm0 70kz9ZhrzczskIGAuhqvjZpsHhuzKehhmxhaMF+R3KKdK6Zwi86XK3ogUPRwCQ6Wg7Mf1p7+7CyI EGQMvsUG8HpznOpMGMvC+nBuSO3UFZPMHERau6qYZlgN2Cu/ALm0EL4CW3JZAWXSOZvmMMCWnBjw 8j0JS5DbBjjkRolveDzjPnxk03vr15zedtMraz2LUmeeTj15uO8grf3Fj7cUWpzZDr3qilTi9YOb U2+eGEx9vrVnT/aBPf85cu5VOv3pCblZzjiXamFVVHHdPxfavyB36J36vJule6S3JNUaaU32Jmlb 1v05LztfzntT0trMluw8t6DJoZsct7hZvlbtcUJ+0HicBl/A6rN78o1GA7Pn4wVFraum1UKJRbJ4 LXGLbFFZBof/cpCvKcvEAF+L42oroN97A7Q7wG0IQsBnVVajVVmNVmW6rZA6MiWsRrVSqXbw89Xb /XNHYMDX4hAwH/bMThjJv1SA8t2Sq6oaWWIuh9uUI4Wyw26TayZ15CDKM3tmUmeWfeb56edWGayY zp7EDxeGF1KRBMNMBLNOQCthggkkZgZzXXwF5MOjeuxz+55Lrf7jhpkf0bLUb8/MXhka5VspLNvg LQr1pZ79feqDZ9+c56LN8Ge208Y8juuF4AdPYcYTtFKulSsWu652PRh/3LYv/nT8ZIV2pr1b3a3Z oN2g61X3arZot+h0QY8zz+cPeZxRX0Ar8wnR+oxGj86p1fCp9PEajY8xj9qpcUlORgOQP/ISZFe0 hBRL3BzGfg9WURQFQu3Kc37kcuVpdfvwdty+Wm4jIxpJ06oRcK0P5TblWmtK9hVFPcUxnLrMsc8L ieYEpO1pbRXdUFiFCiIpoJIUqEgKqCR/KKiAKqhUBhVQBbeXnzxMNynKGAeTAiusGb6BfWoI4OrE /ojC2T8DRweZTCmsHaQSe0tcFZJOf0akL6JYT0o6Yp/upGYfXwEJcwAml3DAx23VCcVWPyoBIyhf Ht9RNr6WQOPg6V64KlKuDoWMRsvUGam3pfzRH65cEh9Xl7/620/j8ajX6ghOj4s5pkhOoix/oYoN fRQoWZXKn+8K5KfqZkes3ti49al9Iaskzxd6rnfnh1J/uKItR7HZ+ABR/qZKMS3cnx8bhBVtVGhB pU7UZSRjwrbokehL0XeF30c/Fj/O+Fb8NkMHe5J6A2Dcq+pVbwGMtZoMXSHstJkwZIZlg9apyfM4 rT6/GkDlNQUqp9qo8E63xxn2BaJF+RnaTFHFAGpMvxVvD4VJvpTP8jmkQxHsXcMUF4nm7yMFlBTE C+SC7gKxYKtajRfcWzX0qIbCxHZALiFGBZJGBWhGBZJGvztPgWSeUpmnQDJve8n/WHRnseZqoFD1 DHFbG6D3j05AMQ08wA5/DkJQNwV6Q+dTbDFwpwOot2YOMgCxhAUC5mwrN6MlIIZd4EtpzpTF2+mj X81oNYRCNNLU+JUhw1sULx06Ep8ethkyPGCjwr8MAUfTwqUA2qcty1MVrZNCqZmLfXaLLRQq9V4r LEvnU2/P6cjnK3ACuM3PwG3Kaac8PUNsLmH2iCOfSTbJzryVcmVX5TXablu3/ZrCrbat9qQtadcX x9boN+kFW2WJo62yu/I28QnxZKWYKdysP1YpTNACLrZ/+y0caoFyhf8MKPwHr1MSoUVuKH2gyGqz +dX5RYIx36+jUY87kwsfbmWS3WpO2WDBMbdZtlqYydJqYZx2brAMW0SLyNekBQT0FLx0kBtkX8v6 jJq2MDWFPWEGgeiMLHEZJizx9vDEigWQn2FeiHKCiHUWg6QCUCnLD7CCqYFDSTrPqUaoZLk3qpG0 ofxIQaQwIqgzIYiYfOYx1OuRzJpoRjExBBBJXljTdBF1MdWHjMVctoDcMaKEFsKSxJ2BFA8KLnpw RgYoermIneZk5nIs2ApfDsioOsesVqfZGhZz5Xk76ijxYwgk09c+mxra1HPvv3tbbqvz1E1lBvtF edkrT25OXf2b+2cu6r/n1Ulrl4/OynIKYHHTd168+rUn/vl86tg94RC9ZVGtLxwuD12Zmjuu+twv vhp47JeXz7IV5AQSgDzndg9jpTbRq9Ma4aHxMp80Ehoc/vIAh0iofHD4nGzh2XIF98sVEJVnoYOc xauzqF+BnV9ZL364XWE3CSDyKx39jjoJmmQeQhFCDKEELnrvY9v9fbz7/z6pgY6pH0uCwZKxrMSV wUhtTNEsX4NC+dlnSkRjmNfosdcAuWj0z9Fj2Ht1yj3d43eOPz7+5Hgxa/x2l1zZhiwDxul9fr/H 6fL5yz3OEp+/yeMc5/MzjzPDF8jyOJ2+ABhHsS9Q4XGO9QUwA4Fg0Dlu7Fi9PoOVFBe7XE6tJcvP ZD894afchtLt3+k/7j/pV/sHmVd2SOO7xh8bL3jH0/FNIX9FG3Z3WPn25rl/skXhe7SCu7FJPSsU YqA4tI1oadDV0qSAPwn/QfWCDY4rXCMbqufRAHjw34sfFP3/RA4UzFHn0F1sDehANB5njQrxBiEo iseHnolPC9uH+pSm0qGnR0gEWlgTJhGC3B/oTUvShMEq1S04d893VII+nJr/XUm44nvdOM1IQFi6 BpjjIc/Jy30KF/YpqOOT8yvsvrnmBZVaj5P5/DaP0+Lz2z1O6gvoPE6zL2Axg1BrsTnJsceu5UvV LnKss/t13dpe7UmtMKylcW2btksrzNEe0x7XClqRd9MqGKiFp99T/FxkUnIexzXtXG83rIknfULc 1+br8gnHfMd9jAPlIqx1vvSx+Huw6tMCkkKg01Dgceh/ktmRFZmed3bNf00dJlWZ0tAP6Cmnrefu VuZMkWuG/yqYMUMB8rE8pslC52TNyWYLrN3WjZl7TcdCKouNxkNyiDm06YkCj8MU5dpcUq4dviXx bDmbtWVTWE8zDtjzDbo81+Dwf5TnRubsU3w+eEb28alz+XW6uFbWbtHu0D6pVR3VntAOY9aUKcY0 fSJnK9OUy/tqHaETkPpPBvE1gdIB38mfcE0OTitfKpME6VGhjCCM2PnDjrjCt87LjpLDmZHpyHSN ofoMp94+Bvus0Lc4neM7r/AwOU/LskHM+O7dd5RMUa5A/n4D3JsWtjU8tuqyZXZfkTcRsQadMWU+ VRFlQocuv//Z2ztrSu2ewksq66cL2y/MKWwHeItpMmlgSXnwOuOzRraM0A1kNbvOuCa+tuLayqMZ RwzaKwm1iE0lQMFKNoMtZL1ss7yV3S8PGJ4yHkkcaXjL8Icyg0VPBSPcJ1Rlt5JNZdvJPrrT+EaZ Vg/NhzBVpkfnNhTijdiYrlbXqruNvFT+Lvm83KTT2/VxWsEScr3c1rSbPsp2yQfZwYxk/Wt4kek4 fROvx31KPsXLX19knMn83GDLTeSWl5fFy6fT+8ndhnvL7inXjewS+WImv7vG3dSYQ3LizBgnQsSW a3fa1DZtQdgZGRMBKQSXelGJuIWtRzGHx4ZqnHKV2qBxqjmX9fljHme+z19TN9ZZg60upwq2BXBd j8cZ8QXGlFc7x8D+7zcasqGM1BFsLr8sT4+XZ8fj5YQayutUTXFSVy5WG7DZjxeKNBpjt/GokRnD GlEDD0j7PlvNmDH5+ZGx1dUFBeF9EZsVDpGqCFNpa34sGuPxmNirot3wnRpko+VM2dBmYL0GmjRQ wyD7Ri6KmRSJyqTwApPCIUx+MHuOjSPMXlnT7u2NTc/QGsW0YD9vWjivz0CoWsHdAzgtlcCxa5UM N3uNZHiaLkDE6oxhrvD/nq8nrGM27vM5YhIDh/7OMjZS4NucUHdIzwq8466LJYrrYvXFDWJnR2eU 73xmVNpyDbUZ3uwqfJHn5EGpSpaMVdzFuN9YBQ/jk0hQOtYv8dKx/Ug4YVGkgY70XhIdsaTxXWxs jP4/Sbq5chRRTMvcHpFjZNx1YQE9e93PZw1dV53IqkgVKUumZOjZ71H1+pJYkceWvZoWjHMWlnno 50UTlkzOPcDOpEzXdUDYj9hs4XL6eqrle5R92WK/jUuGkOQXpOZmLaPSJfluawDSZW5tcza+2QFf diIewqrzkqTshH2MerHRIftn4fXQq1mf937v497D3kzqH6R3yAnjgsoZ7FI3A60XfP7cUU7zWH+G xyn5Al6PF67vMkyAf3eZ8ZWcABO0WHbL2CB7QY7l/u8UXp0uQ0GVDAV/MhRUydjum9s5ItBxXVeh Vmf5LmDNaayVU51c0eX8dQX4K7WOaEAXTDs5YZj/+ewrOlKleK9v1bcfJmaGchQVdtGyWV4ps+zG +Q/9aAm9WpPaGhrtXSVcwdXXEC2U157bN82Tk12yGrMCWqT+HLMSpy/LH5ls1Ei0VqPdkG8qMBWK cY1lLB0b67Atp0tsV8bW2u6jD8Retb1n+4h+ajMYbDB2qOPNcaHSVhkfbxNy4xFbOC6obaq41SpE SQFK2KW1Vtkq7BXx2rLWsiV4l3SNba19VbyPbLZtjN9P7os/TnbHd5Yly35jfdl2rOxPcAs6Xnba +ontE/vJsi/Jf6xfxUP4oI61OTabdlhnxpZar7G/ZHsx/rbt7fgHtg/ixrQV0utxOnz+EoWKQE7S +gJpu6RPoSBcTCc0m9jshNptNk4+xsVj2XGbNR6zwS6FscPFyG5lOi2+WRaPR/K18UsgG9hjJX6v 17fTl/RxXnzSp/Ztl8toGQW0X5YNkslrMnOLYqnCpMGhueQEwwW8XJEB14mlANCRBQ6w4sCSNl9w WYDrgk2xeIN58R+Xp8Dhe7CCFVcFZ0yCexNNR1KVzWauskmWKqK1VVkHh48fsFZZ49lVaVch5UMN cGcgnT5lXf5Q7+ICOoVLeFpGB+J8r5kKzUNnnaG2eCo/DitItrEFPpL0M3qK9sZmwSoSaosNHYvP CuQOfSGuPrdmvacwFCr3rhDWzM7Pi4S+/aOoFM/1XWjo+/ZWyA7DHwx/Ao1sMonQ5+SWPgu1bKGU ya0VWxi15DEaYcVZo7OuydoG76phpsny+y2AWYbPD5g5fXj5GdblQDaHa8BiMVPG/BZ/tsXixwr9 iWyK7IM7jo4yp0Nr0QkKPDIt08xmrxSXZEmQQM6eMgM4yKTFDJ5RjFXS9gJuYZFgrCqgXv4ZtJMF rCArm4M0x+eL++kxP7QBRfpXVDBoA2dgZ4bQ4bfnz4WgoahhEMX4uuXgVuxUkM2Q/5DLy4rmDCvI 6U0jnilQm6sUEGu46yjp5OQ5X2exWwpoLamytJJJljlktmU5WWq51vIgXnF/mh6wvEr/Qy3/ZJRr Xh1wLKI9oOGHCRveM+C21DI8wwCoOVTIjw4CqWRXFc/2jyROpXTQXgUZlWffkU2WKkuuBZ5nOQj2 Kqg+7/Trq3CZ4+nk6wPZVUyG22AaFS+YnlHuIJ0CkGrErDyCQ4H/xjLFJOOk3cJYjjH0HY5LwXM3 OMOtQCyOSGPGjskbo5p8TiMYz6PKt5vFxnO/OF8SnmwqytLBfsl1+Wugy2cSJ9kvl95n2aN5PONx SbyartVsordoxAatIZ8IOflqna2GfzmQYWtD4K6vsqASJuZx+DpqK7x5ch7LM9fwrw2y9Kb9RNeI sZfbeqdIPXgDBpnvPFLLqJN7njrCWWFjprkY7ku2YpqtQS5XhZyUYSimdobIos0pJlYREZ+vC3b6 67GAwVlgVPTxeFQlt3eaFbdTvPAMG85p7HjemLoWH5P4KHXjn45+dfCqzXdcOXD0m81XQeldnnoz 9WpqCZwMa2jDb/ZP3LQn9UzqqQG8kk/r6KV7b+G2XVBsMYpV5cGXyq45TErwqD+uroiVrLatcq5y rcvvLrnHpVlrOxQ8kv9H5x9d7wXV9ohUkh+uClVFxuTHS2ZHLo90l/SW6F8i1OEqcLW4/mD/o1O1 J5++EnzX+l7wXexPfRpUu+RAXr4WBiqtz089To0vAEKb4wuQPG9RYV5+baAVTlwBTU4hLMM5TKuB S7dDwi6T7Oh2qBwTSzgIYA8mJVQuSZawHSXHSo6XCCVFVBGlqMIKqSJKUb/JqKy2EYuVwh+N24tL BunVAz5uolK2aM7LUSPrrXMK36cJp/dpkJzuUPSh9K4Md++Dy4VCUWGvdwULrC5bKD9cYMUGTNCF KGIvTNCQE/aDEeDBVjxx+lpZcoP8BMaIfrd3DEDoIdAMoBuQaNqZBm5lfDnCzvVDEnp+x+XCCwlg zIqMxN376GOu8JTyoafBn7OdMDHTfx383dY//rp0RV3F1Lwl9024aXqijV2XWt3rAX8e7VklLOO5 lv5rdx83js/IeKS3/b6WLECe2zmWAPL5pJwxuT9o49pTSJnJTX5q2Rh+MfBisTAx+NNiZvNYSxYF 4W6vC4VD+FoJxRcwgtfR69hKz0rvGv81oT66ybutGF9vCR0KP1M8HMxRe2+itwVvijwQ3EUfY7uD TxYfLX4n/s/i4WIDvpxCHcySD+iWVpdUxxcFL49lFGJH3UVzPE6Tz09C+U4C/c8IzY9bLQIyKwoF g35Gs6EkB/fhTVNNYcEuxbBt5YOGcbpN06URtmq4YyBx7nOVD9I7ZVNZfl6ei2HnGeqL1sI30vvb 01vkTa0VxPekj7WCGTPfAamSyrDYHa8UKsu1CkZplXnQKhil9efmKBiVo1TmKBiVs71i7mHKxfI0 +R7RoqVObueIKt9aiqWxCYmCTRzyYNqn4XEEgXxFLMqlczh6nD4viVNLlQPYqcjhUcV/tzRu4/hW XOrGtzGLA7EELXUjKvEXJUggGPeWJeDoAXzi9AL6JvaFYFHjrB7fOVMccCF/n+nPrsrn8jnoMQg1 smcOSFVxyQTSrNAZEgWbj0Z9Psq108j/DRU1XF6Hk1QaGYGLqiX4dEtFwmtwS67w5AoFKRWhkf7j nde2PLqX2rr6lp8bm+XSPf/ijhuxI3wtPCVSa36ImrWPr14/GE5dd3N7Jrub7rlhww58sImS3uG/ iipQ7dFslmy33FOEjwOamB6fyhTxJqkq2kpbmc5cPUib5eOVoysdglOcY5tjn+OY41SrDCojKTxW La7SrzKsMq4xdbu7Pd2x7vhm7c36TYZNxptMm6J7xD0JyWJIGMoNFXmJvPK8Cr6lWCx63V5PQUEx tvLHsVoxbo+74x445pePrZhgmFA4XT/TMEuaWTAzCt8QD3MmPBXOyum26fbpjo6ySxOXll9acWnl 7FFGQa8vyNI7CwJ6b/WYgnj1CsuKrM3BbZptsfvje2LH8p8rfCl6rPpMdfZF2tFOfKbU+SR9HW4k G+jIjqRsqHigFO8vLPc43e4jedijlMvtD2TjZYSaTGN2ZqYxmlloFMM6JVEH6BAk7/xSIZDPdyqp 7PaXw0WDb5DTgCzFzEfN7ISZes1Pmk+YBThVbDrk2eeOStzTHR08O0ro0ZJ/lgyDpMIDVC55HQWB lHhL4iC0YskztBl+jM3KBjfQvbMz2gM2t+Isd1BfMbSiKqa8fFLLt2oU7ygece8LY1q/PG9FJtye 3EmlHux9KjuflcG4Jis/rC/SJUiBiRPTLESaOIoZxZkJos8sikYkkFaTsaAwZAF51cbUHOfT5mSF lqZ5JbAfuN/J9dT5+kWGxdL8KNdTYYLBC4xpR91Mvc1UJcZNVQkEzmY7qLKxwF9QhCnRjZ0vLAC+ W4S97IA54WZpNI+EgyMOj4oTL7zkQ5bOfZcuuSU67uNnb2355zNjyj2/dNjz4OLhaD+wbP2do6oj qcd+PPnkE8vWjrY6fBngxNFNOy/bcPG4RMv6RVfeffEDJ3SqWmxgv3HXnV03zS5bVOT+5arbpt/1 +wq7J8Yxfxx4clLhyf+Sq/ERIzY7b7b7CnoFuyLvCrc25qv1tfq2qe5z7lHtdmoYzXODTEo+P7RL ky+gsQXgzCSZtL5BdkzOwj4Cka3GWosJLL4Nn1GCay/Llx1anULndApJ0yl0Tue35nqibs5qjfwM 4pbcc9w73aL7CL4Jmzv8GV5khYkiV6F/ubj6gHcBlE5uIzuLmT9M3CCw+gp+gX69qRwTHMUrJGlV VIEMkfUVCOebPlRY7BAcE6j0cvp1U3BDZT8ADgf/RYe4pgGwZImPmML6LM/i6UchCcaGnuNi4aNz 8ssnacKSanLq+enB6lHfnj0vAoqZxqxll8JrFrOqHz6p2o9ZLaE3HiZxiLuFsfI4xjrgDSqpPD3X VZ6vrlZPVq81iaFAKFIWKIs0BZoiuyKagkhVhLXFV+mvMz0QORr5OqyuMaZNlDAq2X3+QsVQCWO6 zReASgg+xUKwTxZCN/jXU3zWkPlQsU8qGS79F/yvxt4EsI3yzBufd3SMNLpG9y2NrNs6bUu25YRo TG4nIYacJoS4EK6WbpxQzpLGW8qRtkvcu0C3pt0FCv22hBBCAsvidlNKt02b3aUs7be0af9ZCoW0 2W7Kn5bY+X7POzLHfrv//zqR5tVoNBpJz/ucv+f3UoSgWK0Wzd6yoKlLtdRBRErZS7fPh4wkLyBY zPRi2ntIT/bSFWtL2k2lzibq99f310/UjfWkyn9Mlf+YKv8x1S6PZ4+X7fAyL7ddXtR7UZdI0Dt7 w7Uz78YdFGfwH4n6qVAhxx/MwfxO8mVhp2Bk8NdTX3XhzY8NWGCUcqmC7KYeB9HsyuazGaeKwo87 Zy+i6iOnlGxFKNhwR7/tQjJR6KGiOYq5KOykKcv+U1YU0AUUfnhepxNU8vnXKdIa/pGd6Bst+S88 9cOfv1JXlxK0pLE+E46v3nf17f+0BmkKSpMuTu6c/dkPf/m1ez8+9gfRs/uCbLaZ2TX72Nof7hr5 yBMviVlkLCAHHkQD36LZJXoOyi5zUtSrPAcDLKEA7PGrJ51JMSAhucTRfG1l9vjxGVYj0J7do6RY wGJrPRxg3JsI6XC8vqYOxyvX+Fa7TU03/sPzdvJ0yvBU8Ejo6cj+1B8l08Ph/xX5W9Mh8xEJYexD 5oelR/wPBUz3SVOuKc+9gamU6Rr/9uBHjDfLkynTxYFNwdHUFeZrJNMWacyyRb7UOeY3aalR8N5v Mq0zm9RUwzjoXyasdJqy5qJUsBT8hYAJLmaqjlT/8ZSpk1CNCc6UKgcige6AISA56CNGnWbUdi1J J+VS2yjIfve736UUIc+kRjWfYGJRAWCIqMtpwcHJYCKaPHzuTs0dkMyqRZLgDaGY7jehFx4CjBZk agNLuuBmCUjIWd8OsuCv6wEtMBU4HTAGXq37Nf+of7//tN+k+sf9E+jPNPoPi68fUlNfTBGKD8pj axjV/q1CqBPp8n5Csh3oKwxxI/LfA/coR7mTcKydPxJTAR71LspQWuWQp4XmwhawXa8iQWmxeFtw G1865G3JBS/tfekxF0940MvAwYuuboBYJZamPuFcHjJKuNggYzxBiR2mb63INotz+eycMa+EVy4S uy8drIK4UKsNLTXZTauzjlTPFW9/zPiZi33JNHB+1mqm94Nn/83g/kgl3rRBKZAmip77pbQbEtgy JHTZO2Rlg8Wczw3po8AapHMxaz1qtHlEGzClKP0FW0jwQhDfEcWwFdluEBhbJVmum1uSxxnytuy4 RUmjWawNbCdpi3LIpPYqBv3WZm3EOmbcbH3Ias6ZS5ayrWAveAuRYrS7kO/pN7cijfpy8xJplW1F dL15s7TZMiZvtm+ObK6v77nGvF261nZ15Oroh/puMN5gvkG6Qb7J9lH7RyM3RXfHblKvr91u/LTl k7G7anfV9/Z8VrrH9jnv50L3RL4c/XzhC7XP179hecT6iO2RyDeiD8ceiT9Ue1x63PKkfDhysP69 +h8tf7Sdjf9RHbm6dkX96p69VuNg9NrEjuSfVYxXSFdYrrYaVllXJ1cUVtWMY9FNtQvrhlFp1HKx zWBEQwfcrFig1h0rJnuklm2+jBAXPAuGonVrzGhz699s1GOR0M1iaeVRNkcOrb2Vygj013FYWq2o VrbGYhakV1HwBLLVIpgxEbwRX9RbqBWjBY/dHfXkEyhDtHoGo63D5yYej9pk9fC5HZqvbpFUu83W BQRlNBqJxRJWWeYJoGgMO2K1uMXSRRnCeq3HLKHh7PtarN6Dhz1eT75QQHApgAUXbNSSdcFXzQ8A njh5QGsSShHgRg5WzIG9o94z2TPVY1jbs61nvGeCPzjRc7rH0vOq5dfWi2zRJyK2p0RViAA/a9Ps o/bjIAB5aGjBYfGDj+sTjdp0wsrJkDJ7hgcppVkywXpcwjcKn3nUtcNn3rsDS2cPTUpwSv/f+Nn/ e48EWLwF/5Cjojk6Pz+h/ylEhgmgCeorFJB0StCdWsddMuSxtfkBFJSMMT9cMT4dOzNSLwjzKekF hEX/956dnXmabkq7m+cnfKW5OwrIgBzLzH24YvctXcDeDDUHy8z2y4KKKM4bDnuLopIZbFSYkYnl eCB3HmZwrpH+xNtPGy4/+5fGKz8WzKGeWe9Kf2xWEu/ctaU353V4LCga1It9e2aT4uu31oNIa/BZ DZiP6VHM6rYBPEqEJD/oNkqhKOb0QfPQQCFLk1vJuVMgJMqFB8WcCPIXC7J77TaJIDczytl3Jrhy s5s5wtbcELtJuDFl8kAFn9CcrhZSuC1lWCtpw4ZhcgX2JdONG4Sb3Ld0TZRuqdzbdU/6Qfag8nDq 4a6H0w9WHq49nX46+3TuqcFD7eeV70a/qz7fmhn+iecn6h9tp4djnpqierrUTKlQrdXOU+qeurog 1Z+vl5YLCNOH1eH68PFh43MV9pHKrbXbS3trxsWlMftYymBNh9OBRe3hVZHFebPHV2WZ6hWpB1IP VI0du9NljAxrRXeuKrqFVNUYzdJXEY2YIxb6KqK5wVynkvddvZanz8N5G7SqqtZYJaXWQNejdHna Aqt42mYF5b2IirPkKwVMwvZQtGViKO4BwxMN57rorDUw9FS6FKWLVXyMVaA5AYVBdl6t+VS1Vk25 BQCvcce6WoODhIFCmh6lO8vVbdYuocrpYirwepegZX+C7Qe35QkULWWgQv+kuZao69TtqkHtFQB+ EAF8+PtD2nDHgr259Qw6Q3bChM1PJ5pUXLPogRCfSRyFjrn1P5o+751QLvxhDglb4UUfwDdDbYb4 QwZ386EaK3bVFhkQ61Dsc01qe2lHbXyY1+hQ7BH4LHNdmb9mUOymal1acVCS9lXNa2+l0XNdxS29 ItDK1QO0f+ZQoNVVCJBlPHEg0CJO/EM2XiTAk6c1m6dVsXhaXaqnNUjZYVcrr28oJYxHUIa0Kemb Re83r2Ri+R/FXtAB9CnQCzhfAwS+B0YWM9rAeC9KB24PvD36zd6xxF6vfpS+h0ICwxKWvvn6i2ef Gor5o1ap/srcyYqnf/Vcsi+7aGIF0+b+8OEvXy5eN7qgfvzfu712V3UF+2Ur03/xReLv5i44uA02 mtmsWW8w6F7OLpn7/FDer3YbslmTEtm8hX2e3Tl9OR4ZqrHs8rnvs57+gt+v+N0Mu1zBC64hax5B tEZ1CdQUDno0+Ns0LS/zRhqDrkFliWnEdYdxr+NJK/VWWLPsAuCKLpC3G0E05P2IcZc04b3DeJs0 6X1YeFh+wPEsYMnPyocdPpdiMksmg8HsNpmp/N5llX2wTFbFIoPBwezmLeqa1meRbWm3W0C8kZYI E69TxkybjeZIzdv2rvUavO5eFciGuy1hj/fm1IcQsCH/iRZzNGxufQWsHBBZFJcgt0hHvdKhxoA7 iFoDdL2AxCf8QqindwO0ErlWBwXFTmVdyi7JwJ48pteN8Guik3yACowM2EQesN179naxPLm3mdLe 3m+4cu6Caz/Q58/FTKvfNk980zx3T9b4Ym3sFvBki8LKc6ew9tCj4AE7z7BS16Ga2uYImjZwVeIG f1SqZi02G+UpKZDJCnas60Ny6RE39AXoEDz+OQ+4MDij+Sno6ePH9rUkvpWQCcYPpFrxEsDkE8Zi ud6wa1ac1K7F43TvxlOgzHpBS9BBdrtxT4iF+N4QPyKkZBPSwrIR5B3tU7CHWwFjIpE+VpvFN9d6 oXQM6KxjfFdpZublUumo8sIxYIuA0Nphi32yT/Ss62ceNdmabH/Dekg2eEqe3cLuvjuET9k+1TTH PYEhpT3ZNlpjq02rzUvVpV2rh7T23rhFdkqq0LWSrZJX2lY2Vw0sHlp53ibbVbbbrZ+QP2FzrQ/c FhCT7W1tcdwCIrWF1WKl8TRcGLtgx8S2tuwFWwsfC7WMoaYC/0AkJ2HcblD55ga70b4whCmrFW2t taFtoR0hQy20B7j2jyUhP/jE9YXaQhEfe4Ka6CtNfG+HDcs0t9FWnamwynhW6HPY7Y0Gvviz+AXM G/qeZlcJ4H+jdwQiIJvMTmanskYtezorTmZZVqGDsk+Li0GU5oerk2yBEeQqLRGttXokzdlSkdWd lNBkwk5LbBQxy+JFi/+M51uRddpVoi69EiJXqpchy9BxYIgSiLr2gN05tbN9ijASJXeLjimVarpx OmCwowo2Rg0X9HPxTNTy5oJY2uQdGOwfFM1WLAwCopAutUs0N20tVF7i3pjg8bqSjhjrSi8wtWLC oKWhsmbD5okpMebswt2QeWGMVBsuBO5NJ+rt1lvtdjHUYJGMQiZq84G2h+u+ksAnUg8+KSTyBGAS tDnkbA2o+OykV+20OaHZoIFV0GPgBm/+tBaxIXqxtQZwkwsytjK2Vmyt71TbSBrpD6W2sSxcqA7s qH9AZwgw+4PzHDHULIAWXo6PJsS0X08C4zXwspDoFZf/Rab/vG0fTRR/8Mamde1sTqzlsrX907dc sCDmkYMuxe5fOHFlzxD7Unntko2Dqz/xYXf44x9c3LPkpo2ZvVd2dZWHqr2NysapYvL80u1z379t gU9yLBz84pLPsa0Lw+Xx1grQIovn3kZH+xHT3egwyLB/0mf+Ywm0tJ8BiA75D5PPLoR4yTQEAX6F A74wOMvBrnxA8xyDM6ii43i7PRTEsk9WL/lcbp9mha7w+YVo1mpLjSGwJ3xr++WSnqzk8xQISuU5 TFqE+R0PJodTGHAKvI5eQ69NmEw5dA9DjZg3hESSXrqct3AVZnrz3z5Ju+z2XBZihbNi4s/Q6Fjn /Y6RIqU8ws1Kjv21+ZD5Cek3SaMpt9ixtV/NXW+4wXiH4U7jg4ZvWqTlEhuy+PKOYW/CtyQUROd9 NCAg+fDOlfQkTVMmcdw0CZfTYHrdjvWeQhm7XQHWaMIx5TBO4m6/A9QjikN11DGccRx3SA7M/icX Nh3j2e+s0gsXmBiU6aHJM4uWJH6lu9ruYIuzvfCpUQirBpuUUw0JlUXkUEwIh2z2mAWPksaUysK2 KPokzVGVt4uT4PNsDwpgO1FWQEJvF+Jqgu4SeQUvMBC+t0vKg0DGPV/XopQPW3D7vX/xT1//1DdH H9joUkOxbifzVvo+3Nryl3+5vdksiG8e+fd/PPOFyaEhwxNfWRFR0hOzhdl/7e17/tn9z0R9sMPL IEMjsB4p9ocDFiObtx9i5H0NItwGmANZl1UaT02g+IOvhIN6UyjzvnDQi8wbBv9wiCxKvMcAFQ/1 XdraPnqKI26PUffmYx7en3Jdd6UhpOnXCzo2mcSYd71xHXIz66XN0c0x6SrTDaZJYTJ1EE73cfWE 8G8m6wA46jeGNsS2pcdD47EbQrtin/Tc7Z1yT4UeRJHs0fTjYNr/nvS98GuWk7HfqGdYyCyOeDZ5 PpX8lDqZPp2W3Cr7W1Abq7gloTDAtEkKuA65GE9NpkQhpSD/Q1DPidQUClvzKJPTKUfqyvgvUD75 XiBrlfDxXoLVpo026GnhQ9pSP0za2Vr7PrtorykcjzSO5QKmhP3CDGjErQRQEoVHrovcFhFHI2w6 wtCnjM7602asNqCYdZ/DZF7ctfiI+Bm9IkY9T2ANnN259eROLlalErCTO1E72LnrpKczxeR18cvj 18UNn4tDH+8cw9wYHBzE+gtErYHKKFS27mmEKKtxGkkbk6LMQ8qgGd+BlDFK3eyE25juAgUK2pTn KQkQIPJkIiky6DbDSPal277yKmMH7/xWT3lBwm1LpxdtP+/Cr+297IKBBrvkib9n5l+8xJz71uRq Of8NycTIZV/767cXV2/Gp19y7iSqUXcjiV4RV3VkK1fjGN+iGegldB1x1G5H2AQ1HuAKK2DDlSKl S/Kk8pSuyo/G3rc0PV8bIpWlxp4C8DtOhhqP4kkPDxe9mtWJfK1PQCZJKpdJHHXNVYP20iHgJTgY R5UZ0mLkY8yrr4s8eJWg2gzwXq1SbCLOtPg44AtJG05jC3AdFkDbgHkDrhBAWPMGFXBi3IukzShY KvJj+IfDKgXmWpVrtWMlXbkR9LxE6uLlrVuPtalvsf0yac8jQg0JqOXLGzXyNM5H4/J47VbjraZP Gidrj9ZmapJWm6yJQi3Q7S9tMG2wrC99UcKSEEytDcjL5Y3yl40Pdd9fk2Zqp0uiqgpq6ilIO1L3 2tKF6lr1UvVK+Vr1FnVamFYfkY5Iz3XbchZv3j7sSXiX+OP5wHAsEV+SxMtsxrKff2vJMiuXkwZb UrCl7GDeuErz+McDk4FHA4YkcpRi4PXiqBnXivVPG7R9Egwoi6uL93QKu2tOze7ail4j+oOrTGw/ pB4Vrh/ReUSkWFxNRnIloyWfzVmKqlAy4q4gZVXWbSpzxUgpb+ofg4Bz+UYfGVGijsE6k1JE2x4M MYzzvGakdqXegaAp3XSjtwXaUTfG31s8OfLFE2/9/c1roSEjJQdzV1ypQLRimztdNS+8vLZ56Zb9 1265atl5b3/3u2z5mof/kivKt1/+2vKYO73z++ylJROttVc//w//AokmFpl14M7woRFhd0eiC5YA 7J2d2lsF4Cew6XT8+OuawAiqKApomsfyB+dmuK6kgeYmZBSWY4pm3RJ1ioGcB0/Tq2nwBOlUEN6e e5G/AoN/eJJmg7EHDIMgUIJ6hX6lfhNs0e9FYg1zXDuGnoZ5aY77J4X7oY4MdAmEluQXob+j3uGW IRFWsMLbfgnEu+NwHO8HWvezxq8bD6C1F28l4aPRTMyRfPt8yQQ+Jw3xaSH29GmxcQIMjntnMvF+ E15CSz+udetRlD57+bXiSkncUZneFtoaHhfGfS8aTGE1Bjct1goAPoWEDdqJF480LEkyEfQQTFYN vntdd7URNYetm72XBraB02xLRGIGq1kCR5vJv9K8V/y0+U77J5Xb438lfjP0hPcF8aeunylnxP8w eD3j0rhlAp9ur/Xb0vOu0xIsneT4hGiw0jwxY56M9FuXicuta5PrxfXWy7BKyV7v3vA93r+2/rV8 2PKEdb/8PfHX4gn7GdlnOS6BP/G4JO6kLX13BKDYj4TbbqNPqAf89Am8wHlt8+/xT/t/gby9P/rP 1BkNkJeP59QP6El0bQVS7PiOL4kykgHph5ZAIdpyBdiOwJ7APlQezvh8k9S+MGUR68Dj/8JiUADM xyex7Edrg9nyiNNvFPaSXGEFS0/dSX3+BsGpOFWn4bSTOelKrPgunYsTizueC0KANbPAP8PBJxg0 cPlATuA3wgTFXNsFsCT52jv88LURHlDHNUwPTAySDqC8QH/Z4s0HzQJwgDvHeHCAF+ke+RFBwrvZ 0i27Vmk5cEP1beZAgQoHtCEdcSCqP4rqz3UeyfojWX/Oyh9pTmvLD9hFWHW3HLjx3KaeAKE3xB9Y zb1mvbLMaXVhwaALAmDpgfWCOjD/jG3ffufFt1eS/n/48gOv//uhe5+bvZN9w6SEL+9fd5u44Icf +cjlN/n2/pKxn77OpB88MrQ5M6j9OfyhtYJguMX0aaEkWjqzO1vh9qqikbdc4XF1FPU5p5lZnEVm ISPGPPiuf6Nh7VZMfQ/t6cCozGSe0J+kyZZMNoGVSgDpPcyiBzzIYdbap2aUmfYxIFt0owSTNKMc VZ6jf3CY8Ck7E/kIuAnpNUhzRLV40ZzBmSxFAm6ZNzAzzUDG/Wp+GS9pNj4b+X5c1s+4f+10Vsrz JggedmkGb38MFog4IKPaok+p9/jvyRmWGJbYV4RvN9xuN91rZLXKntQUlvOdtkxbv6p81b2/YlWQ ThS3dW8riTGL82DC8tkudjAhHTZYtGQ6MZ14FhQg7kw2yEqjCH7r3UWP24wWTAUCfphd9Pg+BLyH xTcPsO7SYaZojkKReVxu5bMuF8uQsD4+Pt7g26Ehfdtu69tMD99qgViqMeVkJOLb0F0w4zzuNDvD 5adAsinpHtRWilhLiHIhujy2XYjNK1tPEmEAChgLZ3eBGhCRLbQltz+ebN4XyIFrJhsoxIS8LxPj Wfb34ILgJL2nqE79r+kmSpf9cM47JE5ItJHEmf3+Pj97MJZdtG725WLh/PCBA5uf2HnN5qFGItg3 kkzmqlrsDcPq2Qcnu8qZTGHJZeLFKxbu/bvrl1QGE83Uh73enqtePH8FxE84b26Z4X/DJ18grBTG DF/SPu4JjH4pd0+/AU3HW8Qbum8AGX+3uWq+6FOqsT2wdsuOgetzE1v2gWfrtuAnQvuan1x029J9 q+5Y+4XgF0L3rD1sPGI6GDwY+n7j+6tmthzfcmLL6S3RiOrvU5q+/uQW00OWkf52VAgY+lMjUSG8 +N01Yaxer89qQdLBgya+nx/0wCJhAApwe5u2SCDZ2tPZR7PPZg1Yc/SrT2wuTSLYwqGag471TAMs 9mzKQMECvYZv8ZIUjtVCUyNshHgjR8A11R4p09QZ4U1KzKJ5d1jYHlDmIgpFGb9pvofzGfVo9vCI XAuz0fAkuCWfEf8JDPFWwxo0/vVoslkKX8guLJdda/7OUIe9S+C+Jawx1LUkqv476vvq03VDPUT2 tW4ns1dvtqqGyfVsPX02B+Y2Bv9wUME78j10CAYEOsYEW49FlhlQYDMaQOqNfQW2tjBRmCkcLxgL TjoST+kIZwx+q3nINy1cr26pb9G23I/v3LSFXhqz2RtbnPu+uIwt41mcZT1qgLkCE4EfQ9kfPvd7 zU2vC9jJMQjwawRe5BnNew/y7OjFHTWAexp5TMUgGugrDccbfIuzYnuGx/c0eJI+o+Gai7c8hSpI ismP7UX2UkcoIKrYNYv5sXXnqdKuk0ppp96pVdJpNXYqJ3lrKzRSxyiAwolatxSwop+hrvJdCr0Y pgJW4uCPU79IibATQDTBKQN47+CPs7/IYs+u+Tw+NM58u7JOvgUIxC2rNg0tzTRj8WCIITHQ29PX 0+gxmIdza3PVbHduY3Z9jMUWgEVoVXONKpzP2qpwnqkdE0Yra2LCRaX1KlsSWhZjG/KbYmzjpvhQ FIdHFwire0ZUtmqk2a+Ji1Xo8UXGhTF2Qe3CmLCueKEqLA0uxgoDuEo9xcTzTHqySUdC0TP4o0Zb +kMDDxm7nTzZpMlVBTIKLifKNZ1+DNh/HDqGBDsndAvyBluK083pdCeG0nPxSBFx9g+K4Ilkgrpx Oet7P9PhUxwqBZo3OpwbM52WkjXXX3zs/tvGv1Nygs/W4CrdOHj0gSXLy8lUPTbxo/O27vjgV97+ 9u2rbO6mtK1RajH/yPYljdHVly3tm3urVh/a/szBb/Y17v0lu6D4ubG7jmomszUYkU3mFROTh3y5 ls+tSkaDyeqYuGjn5Z/d1NsfCmXPt16e7EmmLxXvvOGWr246f9ct0xeff/bP+zZn65lFe1Y0AgEj jD5WSRAM/4Forl/c17GN8UEYPeD7ZbfMDaEcytDjEAc7IS36FgfvYHBC7+QNOSnbHMqRtUySsOdS jWa+wlJGu13ckOLnSFVCdI4K9SjSXgze5CkrDPQ5hsEbmoteXuHnqzBEYcOgmMI6978SsrgVcMsL DRheV5PnsZr9Qt4dL6P4DTq4GmWxeD8w5LMTD/K8k3L0uV6UaikqRFyIAJHM8Lw3vbmBaW3e0OT3 eMd8AyelU7rzMje/Mje5MjfLcifTxXd1cl+hwQGW4kem+O4UPzKFT3OaZ34xwELdUDYYnH2SjHil MjjQsdrcaHfGiCFLBHBAGInsGCe1oyx5bVDrbsqD4/CbXVlXbnJwatC4f3Bm8PigoWRmo4PjgxO0 SxtkqiVUTAA3ATLjrkoxkR/pkosJZSSdKiZyhw1OrZpu5qvDjURzCVPz/QL/lHCr3G5FDocy1imZ 7ZeZS56Qp+Ufy0bU7J/RgFpKZarJymhlvDJRMU5Wpiri/gojmoyZyvGKsTI+8CCiQySa4VCSZwkP lLbztT/gpdwtPX9GXz43zr5IzISycRR1j3AM4JuIFCfz3MmU8cQw8R1QHsNN9lhPyVI/lj8FtgPM NkJHkW2WeKYWezsMFp2Ika3Z8fHhCyaiXqdc1+YW+bVe2ZBcUu/54Ii/tWxu6Ly0L+RKRvw1J/OY 7p697JalGy/RHpn7203Is2Uy+ZxyAVvyxUtrjbVzsUuryUzGKw9uNJynR4/UJbAQdxLmi03oEjuV mSNCBoYgTi6ix8HF3ZHimYwUB5KnvCEsfnHut1yXY3CCCz4GL/KJhMGPDpHcWx2YU7rGx+BX/Cia ZfPT7cUn6KiQSumQ4NrUjtQemOGuHZjDRGLPPVketdNsNHeZvfAGX4RSP7ZVeVkPJSH+fBYcw5SA zixhIrB3ZoJD5XMgxe/pPAdXrUKygwbDw/pACw8MmDdolOq63yzSmwpIL3RJXvp4b2oxmkngX0k7 +HxwiCT2Dj4f6JPp8wGDN/l8oD18PoRCmfR75gAfHsO1v3ysfQzixOUG+hzx5VSGjWcmMlOZ+zOn MyY1M5oRNbrLkOHs7W3w7eCQvgVKhD/Gmi+01arhSAMTxDvS5SgmPJgW+fCwmkgtsYft3il8lBba YO2S1yNPoaDYIht8YHGTNpqr3TR8CKufhB2ZkFZq4cJRxekfakyF2GiIjYcmQlMgJT8dMoUOpA/8 FZ8OdNnEZk+t5ad0NxXhGD6aniWhqaCbKIi6nhbuJOrI+njfkWtyTFEHhrAjR8yK3QsWdHcvXPCx cM/w3OLFVZR4E5FYwcl8prvpiYXd3QvmUrPqxhYEObJwA/vAF8pq2JWZQFXh8rllbJ9pH6S2yI52 9Lyt4OVBkDdJv9+Zg6Sg+YAEGQNd8DB4SfPq8qnLtkwxkwPR+xx/CQZvcFnF4F+5rGLwEkgrIaxJ wVzMk7zaC9gB96kYiP5IQeruGGXtlBeP6Yoaum9eMEvPIXY59JUIM4cZiuczWnug6SgdgPrTSqOl qdI3nN+I318yq3gwWTIo2HO8ZIhYCnl1OJ8oLAnTRzJv8Eas3eGoWrRLYEN2ohKCdZ4kvLNrmorS SHwt7NZ/ZkC8DdUS1pvB76tLLU/90SyG7GaSySmVuVRGHOanVYOq0smRr/wDIkYcoB7oLv1jin5z 3khDyu8dAClfbuYMfn04W7BP7bae6d1vPhY9yOXt1K4xLD6zUCc4a3lKHVp5riSVWMLpimdjrmSM JZyoKvAGBXJhKFUGL2bsffys7veWsJAte7/cFEoLF5YgHpPP379lcw8Ypt0fSIWqgXelZx9/uru0 cE49e+XrJ89Pp3sd0qbsps+In/5SKcUliGG1K8Foh94bMDzbkZ9SBO4saBn4vQ61dWO2I3Lm99hD EhCge/gGr3IZoYFWopflgK6pJlnHPeD8DSkzdxiq3P5XAySP8M10PwED3U/A4LewrPypOZ3Jpaow d9KYk8FkDE8dbwT5LDwNbyEnNCF7nn7uLaBhOhfGz4wLtEMkDwHpjeNAb/+rx2QzfqHSqVLHiZhF qRrlKvT+6U4DuRGlmeegNQnyBfQJGTPCbUW1I65WsiV6zArD/89ZvyBP2abs97nudd/nuTc53Xpc llvhVmSbss29LXmtssO9I3mfaH09cSopTlr/3Pmc4TnXa+JrrlPu33ksbXc71E4Oqu3WMtcu+XqX pSZ2K2pWzdVaqAQokl/ZwC5S1qvGtLKJbXK9ovxBMa10r0h+x/od+f+RTUFrQEnGk8ml4vkus83t 8joi9rgr4Uya1xk2oBozpqx3r/eaw654PJFcJ86jk2r9sFSQZKYY5DxIHYVbQRD/UahAGd1tdjve uuPd8KRgCt/+K9yvweA01+MY/Inr8Wq1NdjR4/i+eLmP/JljMEDcpaGCH8yNtkFxMRH8514lnIwk wlW4KvkuWbQmZPJU8un+fG24mehfItQEG/RORk36VCaqSfiGdSYCyyQi+6omvcyYF12yooTkAUEA 7+sb2uqQ/YcgajFDY4bDIdlWt0/axdN2dtx+wi5O2GeophMMTgPBEEmibxSujZCp1YSqgj46aqIz jVbZZHUKSweND7YOs5seTz2IIjumNtgrMLHhXV6g7KIOZMqgIdM27+Yg5UYzOUyfHp4bCQ6YDXkv E4fuUi8yDQQcEOpYAL21id8DEaUcPSpJY/h+du3aSSWfXR2QIBo29N5UBdPGh3glWQAuBbe4BsEr uDhQCV2mNjJX7pZL30Bl0yPUYWceAz8HCeu8yHIooZtiFqIZ4KBeSfLymIb8KyiOBpEP6KyeVCia 97bIAK19bcRuSeXY3Rd9ePj11y/rqmfCi+YW56KFuV+Hq2vmqsvSfpvLqUb83W6mmO4+u/OFJR67 3RdH9UKsLvjp3L98NFVzypkM83uDfeyqueNjgyGWybhtwdSFhvOnl0fd6Ql4M+fBw3JB0/jZZ3RN c0QIwr3g/pXPbgZrLrdDjOsMxnUG1jSAm02ODwa/4REGBroLhcGLXGFg8PMneHUcK/n8Cov7/Apo Cy8UhM37Tl2ckO4vl3opkOhMfvLLETMosEvv+Ep5L/eSfD5ua1AmEASpk7njRoQuDfk7vKHu9GBA youXxnWnx27H2ik8z4+QhBz/Nq8ZkU55cio4EzwNRnP8fI+3lzVoqw21FjRY8IBje/9okGnB0eA4 mGKmgvfjQMleTEgjXayYMOfT84VyXJJklgWWceC9+Wloq0WaCxpTdjZqZ+P2CfuU/X77abvJfiDw HrdFd9/bC99Z4wRIcLQp4Mp4+fr9vsm8a/LRcGP5XLtdjTiToUgBhLWmu98e3jgY536IQbtvORWp CSEGK2KuIwu2yfDPHSsSHOPR5hjPwQbd/Kd1b1iN5g5d32PwG/7z0R7NRb9xvcSPKvUMLJs/CgP9 KNqjpeioZcPLh/lxw1xQhrmgDK9Go7u4YfX86zDQ7QsG+gkw+JMGO4GDZDrN6hJ/eYm/vDSAnxRt OzAcA5w+DI9f0Hgv0ECMTozHCILp1QOoHtI9nWPAzc/h5udww394VT+HWqdj8Pg7+jnUbjoHHv9M s9E5qALJH5+FjOI8aiBc6126ghwqdfn6DRodU9vA1m7YsWEPVpzYaF7eE8qWbQBkmXRkB+iWqSpZ OqbMwqTNzMwbNBK6jm17z7Aj6pBHyDvVokrIWlOUAKns1KkX4vQ4u00ySes3bJRCPcvdXOLdKi+g qiUeBJf4vtLAMH80zB8Nr8bn+g23FKq6Gd/TW9yO8AFNDQx+z58dGNiM3+C3fL5goM8gDN7iz65e Pba5M3FQ18Al0r2CK+c3fBjYHB47IL+lnIJG3e/AwrjPAhLxqrAUtxpu9XOvPhEJoTcpRDVI/I1F tVhDOj72u4BhEmHnGEXbqChOjSGoVosJ0FqcPdg1UEz0YKDZulYXE8tHutzFBDjXnQfTpWIC8C/H wfRwMbEMA21RekN+zfD6xIYlluLAGq1VLFgEKbt84yb6YbJlu2yTzEaTtHwZmlqD8hi8T9Cwpuoq m1D3qyIKs03NNVCsljKD9QE2MbB/QBygfYE1m4Yzq1cn14yuESfXTK0RhTXKGnEN5vUhrN+4Znzz 2GHxYtisPeBx38553AkQpmNaYMIWzmKdFh6e86UQYbzojxoAFoKklwwYd3nw5c6vb4RvtxOzd4Go 0pFN5zL2FCBeri5n9r0xO7BctKwlgVsG9JD9vwjcO7aEZ9UlKfiuHuEmhnaj2vbu3vdGPn1sdLun cnXfxlv9V929auXOVMAh9583t9C7IBWUjdH8xuaHVouif2jZXM/qls2UKq/tb66rhHtWzS1o90a4 n5t3MV9JfGO7K9e9fdtNq1ZtGLp17oaNagABflBJu0fZJyeqWnOFrTS3ikf9sEoXYV+PFi8PzPkv 7o+CBm7BBnbpl8rz/rAdebP/F5qsT3xHkzW5JqNEtLihh987La5AmlRClfal45mihaukDl8Z1weW AE+vdXoJOS4CeWNd+WGgQzgx+K2Wo/keEOJcmcT5ieL8FPEiz64VueNcnHeQMSAXjTfc6UoOe/6k yXSWohATM5DaX2nWHh6Z9fQ6iNqdyPi6cEO+TbNmXJleKVLWUWK1Gk+uKRwr9r4MGwrUJCmUXOOa 4yipj/fVurRLawEylXqOvoeP+QX06Od3Zai93LzBwjWFhWsNS4DDLwJ8VwCAEsAzAoC0xPmRcb4j zp+M8w9Kr+cDeiMMfv8kvaRYbDY66uL/N9kG33SoiWybpUnzv94cxYojE82ppqliZLT6yERzEo/2 N837m8eb4v4mG8eOmaYhbgkUEy498VYsJjIjXZZiwjmSjhcTaT3x1pPvHq4nepbEhHRvH/9GM+k0 2sTkYCAjTVnYfgtzoQA8bfmxxWihxBuoq+OZ7mRxtDhOXKSTxani/qJBKCrgUyE7bsWEL4439OQb n+X/s+SbJxQ2mI3ZsCEYY1jwyxSZn8YILUHoSz2JgMpT7q3/v8u8YZ5S6Ww+HddJxhGGja362mdX XYt1Zm09588t8Gp9snF4zY032Jw0EX3LepB1i+nz8NR3Vm1ceOvczZuSYZ5zc61lN+7e+fG5+NZA HDNt+Xa2/oEVEZ65gNIGHhLzzCXERXvHZ4jBDaQJZeeooU5MpxAY2h4x0tyhJ2mgeWmnkR9mDAIv rWTh81GFlFvCTjrsXXCFlZ6n4yL04ijJVMTo4xLns4OyBh4czD7ucXL4ATQ0GhN2e5KDJLgpomkA W8TfhMqwSz2TfvZQ4FDgu+z71qPxn1rNnl/LbIV1aWCT/3b2aete10+jUlLrbRo5OGI6yZ7zfz8i akm20jJ/NR683YxWgv+/FqJoZMfpftQ4bpwwThn3G83GN2hxl7Zmn0aI8w4ugHDBlJgtrdpfWLdq /+iFFz9mT6x8LGlcibXgnyEkNFZMmgF+boZM4OLNf4v1t3vRFO0z9L6mvBZ9z0NYB5CA8Loyij39 LO7BOl5iNpaTs+ac2+VThTiLqCxgxSgkYeR1KCqLGnDntwVVIWzCHWkIHovQABAgrH9MaTJIHfAH mvt68XrzLfItzls8NwWuD10fs6CPQ+9Wt8YUdyuKG1AYpx+z6YUaiKhequ2UYfrBB0MVFwAGeO+E KBz/2Idu+PGeH99y1e4frmt+6Pzpj3/gY9csNzz61Tsf/ejZyQc+9Tcf++ONw+2v3vr83M/v//sz nx5H0HHuj3Mjhqcga3mhJXZ1ZK24gOPte+Vu8sCoHID7kDcsqIail+tgr8rh9nBv/sRzHBic5XoX gw4KVzUUSh6j0xwh6ACWz9BscD+qWWf/GNZ64lpY4FpYYJBOaFjUM1DRgMJ9NwsBHAFwuVCsULbH 3o1Fjgi9584+QYLYi+aD0xoQdeYNsrxgCFfH5dbLdaQX10I2gGevfguaNor5VRxVMDvzoO5y4mJs dDV0AfRLtxW9DEGtsHhHKM/jPKSHdJNUf0xeQFCelrJS2aLsdRvvKLMF5faCVeUt5Q+6P1i+znKz ++byJywPSK9Z/mh11Bds7htrXNswagtYzWIoFD1euFXhO7q8cK7yaSGfWptPCEtET6lgMFZBQUJX IqLBwWkLh5y9PUl5ShbH5Un5Udkgv66KPIUXVdVRwDtFlKcJ7qlDPE2p8SEC9BLTMpH4zmN5F+IT UQZ2Hq5WKhmctPqAvlyNWmtKDku2kbPn6tmm1KuymgN3fdZ+lfXYqioVGTuiC0VJXJZIw42NGbJ9 fvJ0CDIgcTkEZUhHMwbgCc3rRpOuMBFOUymQHB2RRXLL96395CU775p4ZKS/0BtsrZpTwwN5LIyU ToSyrGF1fnjd9kUXXqJtrtcyhtauF2/+wLWfeOHUfXv8rsrca5f2JYiAz9az3XDZWD3k3DP3yI70 0OYLrjzyTzsvCHmoTrFkbsQoQJbjSB2+0JHlSA4igdSbnxN9+hFKJzqxtJNiEo7MdOosQdwPwd4T XJdi8BYPnZ0mkmCEzpoixc2uhCedDZmLYx6b5NTlBvkPeN7vBs8zXGJ1oZmJdpMKjXaTHEa7SQYj rkhio2JAzwS53GooP1oRNTRV/HXh/oqxHqmn2t2DpbWKFtFSa7tXlDa7RiNjidHUxUCr7FAui1yW 2tF9q7IzsiexM7WndHvkL0pfcX0x8pXEF1Nf7v5q6RuBByPfjP1N6Ujg7yC2Pyu9UXq71K1Wrste V9jn/ZL3S76ZirQO/MSA/CSkfCeCjoZciaQhHSky+ljpLNbNlMzOaFRIJrEC/FVaTUhiEVtxHERu jzIDs9CnYK/nehS0dovP+n/s/x0W3eVIAP/i8jx2kjhC0J5BtTGaTxy3cqo9S/JIZEo85xvKFLzB TDAHuKQXd9lAWmV5H0EoSfb08jWxeAwCmwX9SQiWeSvMZQ2VakJPEuY3CIBvp0jGwZL9hg+F+kbm er2DcV9oy10rb/9H5vv71nhuqHlbfnt74v6/um7BJYZH375yc28sm1VsLbi+1679/Q9eY1lVjWVm a+xbsNd/9+0jM6D15RVj8UlIVoE90ZGrQjfXkeZk0J3nzmk+lGSdUP69kS8KA7pfi4HukWLwWx0h keSBeZK7sNiLOIs0bRJ5SdCeUjI3BE6qX2nOtfkd+T15Q74ghewACLWPUYR7CvEtvtj3J2ypytXx ROfD1zSdLofX7rDuwUJjOEHIjCvlitLNI1g33pvUuHkDBr/hQSgNON4qmewuvutMAtaFtM2xTnaT CrboaUL45uoVe12aqLk+bpS0bratmyVJy/F48Y50HoWKXCK/RJBt3W4f2tGMIVpktaUg7TqG9YYl RITbzAxFNnM12c26BTeKEEmVTapTqiioCiLEGYDoTep4kZKTREEzH+PtAr6cSxaQHae2QrQ4jUEH mEtChuoBmmDQSkzOHad44croXX/uPyf8Vl9388CKRia9ye/xV+pex/mL5krLusKyCQTyybzM/IZH f/SjxeV8/1Jf8dK5lavzcN4yAR5PXX7/eTFy4CAv28+dFH8CeekxNjryku/j8tKHfh4w8DJkoFE0 4LVS5gLtYB794+KGfArpTF39YHBG6yV5cPVIlrwrZfSUTOxmE7sWzLLZGmOsWwrfmGCXY3WkrBph 46BKEyMeYGqBUoUPVMMWm60EzSbHD37fsReOKS/olvSd5EZvypW3GLsDCU/VJHb3SPppwp5VJvYh 00dNoinbLS1JsO2JjwASlwVDMF3h7zUoTPMGl6uvN2Jx0tCSB1rQvCGf7+vl0gLMgb49Ch9qK/C9 W7ci37u1rRzlXVe4KBKdorUcLoseT1WztcroZwr5xuwX5+5TPp8xyRKam4rjfRN9k31mV99hpmp3 Ql3+wPED59HM0ey/pF/M/LT8ivGV9CuZ18o2T7u8tfxnld3lfWyfuM8w6Z/EWpCTsb2VfVUHGh9E GUvAmGNy+fmu76ctMUPA58HaXeFitHyP9R75PvVz6c9lbJ6So1AeKa/t29Z3U/Gm8h3Ob6Qf7XvV 8ErMXrT0JIRnxARLshoy8YdZ6YDwDAjlIpq7O5QIPxNNRJIRpkRU/AD0ZPgZVOAiWpfHg7qwzejK 840pwb4nVGvdPWgUx5ca+Vg4HKIGDl+gRl+s+EMPYx6CIv2OkGYGn2abcLFx1wRWaDYAa9mvYQWC cDUJNFl5Os/G8xP5ybxBzdfzYv4ppmLdXfUxHRuLyUHsTByZMEso2HMpoGBbNXRTHDjHMCSc7Ek8 D5eH6rUn30PbBK9URpyWcdh8DodtnsRpDD3LxN20i69bo4/5UM+QHayqVkcDRGJcp8cKxaSquM1S 0o3EibloiWEKAwYlFUwx4m7iip1iL+pYflt6U3nT/XYBHcto+SCqps1aeJpNi9OGadu9jin/VGQq OhW7p+tL6emKHe4xki68MwQrr9bStcynyvdl7itj5VV8OM1dUMMtayEM/kq5JeJGbBgH5BYCmxkt LLeq2FXmN3RDKqC9dKp0BxcSiF6+CbcycAoAa0YCgzZ2bNB4Uu4waxwARRudCyQdDLQiIm5lNEPj NacBRcBhrpYBHdZVzUEnOK15HHgfB47BDWyrdOMhAQ8G/qs7fDfUswc7l6Y0M0dTYcWrDjUVvCgQ U8EAcjJA4DZ02BY9HhCnUrkbL1m2UU1u++wPnrl+/bUpf9CRSsW+etnSTR+Y+3mlct9H+9f0uRWP 3fDo3POf++BIZbBQrC6//Ou770nIEbb803df2Fp66dRQa9POLwddzhB0mO/cv4sLjd8Ga+VsR4dl 41j2AO0pqDeLG2x2noCx+73M5OVDLzdk3nm0FAZneHCAwWkdNuW1WcqugA+La0UPCIBStI/NYrG8 U0c7OdqX57vw3k2+hoNIKiENwu+Jh29+jN/2VZ5NxS+iD8IYaD46YgJcH64o81/jYytBF09vp0EU 8d62KDPx4MDEkykmbgVNuECqr6KGjivl9g8DvcLn9cZj79q/Eu8DaM8e37p1RgGkZCuV9+gPPyt6 Xxy4gGF7axvbJort+D3ue8LP+p8NHA6/Gpam42xvBE1Wax3b7NscfwghE+EP5UEV7A+FIwZGd77o /czgr3eu1lBHV7fZ3qSLDvwY8Hvysa7wRX8o2KjuVwa7tL1ai+9HUw8axI1GU8Y36mWTXiZ4Fe9+ 74z3uPeE1+wdj30TqEk9NEBkQP/AVoDgFkYUxbzZk2j9xiM8haVFgy2Be2f6Cizk8+/imKQ+P/i4 uJj1cY8LZE1p1M2Q3mQjL77YV0gtcufTk0uqm7s/M3BdJVg0fnvun5fNfmtsUbFw2eV92y4Xr04F rlmRu4Iso4jcxqzh80JWrHekKpDnOUQoNnLUmU0tdCoCHX9I5axVCOZO6pgMNcIPjHh49QHcAzo4 DwM9FsXgDIcNeTLzoaczlDXbVGfIHC870QqCOfwEQTMssgBMxjHESboLj8Ua6cfUV9XgnVXvBp3a JklvWTCg6V61hZyAh+Os+iltHZ8YMBGqgZEpZGoEbiDlUkiwIjLti3gslpzKJU/Fgi4UjuZwtb/n soeBjhKiAc/7ezz5XEf2eN4fd5Tx52n/0gwlJ9oQQo6cgz+IADmqNVmeogo1T/Zhf97YsA0kh9QV yRWqKWLxrqXIM7U2kc2nLXk2LCUsS1RbNm45zJZqXhn9UjBJ9BU5ZZtss6V4u5RT2E/EGBNsGgyF RpBhACLnCUeQvx31TnnFSdzt9xpI6NSO2EHoct/RG6je8dMAkkMcAOmj+jHS7lwQEem/g5TTISDR mMsdc0Vi4BKLKnH0UxNGjhqn0EtKWpG8f70val4OAYuTmqmOdML/zzcNl6MnKpl3zv22csOtS9fs LMcGVrDhsXbpw6taFxs+P/uTad4N9Z3J88c+PcnuGe6NsuzsfZOj/atF6YIBUDShYgcZPQUZVcVv 6zJ6yGoVIh4zXwnUDb9cxU0EiAK4bfQ1vvFGGzVwThLWKRn1hGSsvWW1dqXwOpuPJ399XrObx39u j1nkezC/VT5Q6TzHSu/+50QMrdrLx5CRoJ/V6lknbw5tCWOJYyJabnaRFfqAv+kL+yJpa5eccque TEgNq5Eha0seQsm9GR6KjFhWWpfIS0NLwysj11i+YrnH+peRe6PTXQ8L37A8YP16+OsgZPo7NAUd kg+Fngw/FXk6OtP1k9Cb8puhtyOVaSvY6wljNt7g21KPvk0U9S16/Pj+fF7fptP61u3mW00Lxxqu rluxXvQuccJ0q/rnptvd+7qsQ5aG3EBH53PmmdRLEekueW/ozrBhwLMiJHpDvoRXiKoJwSO7E5gF d4CSKRJWQ+FwXee/iEYiGasFTBgWyYyFHSxwybweuE2CORK2oQIE87RNBq1yBnjOQ/ILsknebUXD xlWaoplr91uOWH6EBUB2W8PXR4gYQRWs+HwuT8NKnxMgdNoe6G3S5kl7U7DOIFwCIcch8MlMgsS7 cxRtD7m8jRQp1jBw5LS2DamNyGzolTDUauhM5BRtd4XgaBG1Bv07RdoVrBocHPH/xWsGi0JACzoh /XHR1/nMnpBVULhAeb36JLbWDPxlBAvwUpAEO6HJ3pZFBQEYbtwkcfQUdRcRTTs5EuBOoVQMX1zJ jLoTcSqh4SPvZo/G8kX/T14MWmygDS01fOnY3NPFuSOBQtLda/h8Nqem63Nm0TEYd1pdNixe6k4s O/tbg6m/plgtmC2OcydNBzFbyoZjndmSSyXcTrFMST6nYM2FLMZCNml2mUnM21jMSOc7mic70ucM 6JdhPZeQVgzF6N7C7xEnQX0i40D3oZzVKBT4yW9GX6dwPWgkbNejn8Gmn71crqRS1QrpTOhKTq60 FRR3L2/l1Gl6/z3/VtHDXcXPqMXazUAeAaY7m1er26rXWCeqr2VfK7yVfatgpwMOeJv8uOejyUaq Wi1u74+HsW5PWqka5Vw8V861chuCDwUfCj2Us9iyA5mB/FphNVsjrbQszyzLrymsKd4lTSqT7r/I 3lW4qzhZvVf5PB2cfVo5kj1SeLb6fPb5wk+zPy0cryYFkxFtnsagNSvlrQVzsRlcrCx2j5oukjaG Lirute1T7grtDe9N35W9KzdZDd5pvSN4Z87gsI6xG5Ub3UbMCfya2azMJMwKJehOKGo6lVCFYjkh uGRnwpUMJxII6+94nICDh8/t1rRQNgNGP4tVyhQLvmKxAGnI5usWqw9UMvBOwv6MnPXJchbrQdVD YV8oFC7mQG8ZlDH/ZPwOT7M3MIkS7I3Hk8zlpkeK4IRvAiuoKAjgVUGknQzc4m88jkkaepp9UMgK Fvag5ipouFh0D9nUs64rwLHEHjs4I1xRTB9Gs4xfi9ZGw+z+MHsm/OPwL6D1PpupYXpHn1RdWXCR MN68g26R7NNMAeDNjxlu1+TathzTcpO03hl746B1d75meQrT3ALnT0aCiU0WThew/h1sP15auB/r 212lRUeLbJJWwFOKKtbA21+cKR4vSsXxyjte0yn0i+wMR07NnkQAtLMzt7Ergh0wb6GTEbhSdKPJ TlOdViOGhSMXS5/63MEiFaDHWeBW07UAEUJZAIPiZGt8ML/nf8yxRgxrXGGgoqCXsUCsRG3zT+Ro mQcKTKhhCd7siQNxWuXhnY2PHp0+EGzhuzx9wM8fPebXVQdNEV1z8H4OrxdaQgdOQUI7iqTzmKUN uh5xsEmY4aPfbYTygYXs4IoE+ku/7cu3WGpTce5HxX+b+0N27mfxwYXQJ8ZELFme/Xf2N3cuDDqJ XQnVaJ9/9vfs7X7VmxCzWcc1Z18XV84+aRBX9jnIZ4yi7vxraJhBw+87PqM9J4caOWNFwKlq0DMH K15FHMTgkFBJuHVFg2ICkXfyO72mQKb0Ts9Sme1z7HPuc9+Zu7Pxou3F4M/yP+uzuqqo7NgydsAQ ba/0SrGhquvifmO1bWorbfdgrl1oNepDK21rlbXuZYmVudWFVQ1taGN4Y3Z06Hppj22Psse9J7An +AVpWpl2PxR6OpdwmlyKy+0qJ5WkO1kuysVgbUjGSsrWi/tHh+axiBlc983AOtIHuQEM1NVcIyQb hSp9hkQ1Hm9Vq0PUesQVGlAeOlscabQZrteoS1r7eg5zE/XJfKPRlIGi6YP7IUnhXKPZ6GtmPfsC NcCTmnBLA/b47vAoMka17I70HnDu70uzdDgLGGNf5ffFYr5vFN/27iZrmkxSNixJmWbW12xm7YF8 vt5n9/X12QGhC1ntwb58NmwbrOVCssHekJou9C4l8UvUqvQzwIC73WSVq0Y0SlYSibiMZSuXPrEj wAJVNNg5H1fDDJ7MDILCphbeHz4RPh020g6yxuGnxX6spSaxqw40q3nog8exDmrf0+K30QU3JK55 PHWMt4FhiVBkQMFVCzrp+cW/t85bW2rYRyEE849zyvHABjknyme8j4uNgSB0dy30BpbIoe/4JP+i Peiq3Io9Cn+o3PoGRpJFWegEvFFZuPvoUdoctRyVsLFgL9IeaLPiZCfz0EUb5pRMCMW3nrSiJRxZ BoxfpZU2UM97VbPG3G0HClJtGPBXH8cD2mpesC6bqKYpEQ1iP42G8J1gXeN2EbBHnOH0IVcrq7rI 4BPRGlqST2DTi80hB55w8D2UncghK5FDv3EWN7yO1uYgJwH5C75x6y5D1NFS8AW4cQsilaGAFB4r tSNF4qcFPUgrAIJBG/hiM9gg0j6tef2tfou/VcBSMUXc3JZACw7TCS0aaBU1N27+Vi/d8M5Benfc 6OXzoExuft93958zInpAjUP4E9yBmU+EUDHpHf8FEM4AscTpJaY8qSb+mMLSAfJzouzRYiptCwyv WtGVY/09mZ4Nu0+uX9GaG60AMn/H55ZUKnM/yURzF898a+TC86CYYsFQr9J19dWXR/xxqKVQ166H 5g7f3GPIZHzOYHDr0aNb3KG8mMmYfPEbz529dgBzxY4O1zPQTL3v1E7hnZa6DcJNeZaPI2KA/wLy IVJMbj4kktdDIh+KNOzlw14M9WACiOw38K9dO0aZ2/fGFAlrSYj73OItWDJIQA+1OX0LvYfL50OF otE3ryMQCR5FXMg1BPa1eur7FaDBngHt7FtC+NxpIYKCsqyg/E0QsG9aqSPQWfpCUfQ2qoHt/beZ bjeLVqvJYwlbItaSL5KzZjwZsFsMsn5PM7rcc7X1avma8JWRy6NXl2+y3CzfHL4x8pHoTeW98t7w l4UvW78U+WLpaeF449/MafgkpVK5u1tm3FMPk3tf7u249zmLGo5E6t2yDweUSyXu2Je68ZLuiNUo W8rYhuFpWNIdFz8PKdKcuNp8Ld2KuxqAkIXJW4juk9kv5NNULJ2Qf4di6W5anm6b1WDdjcDWqcVL L6KbwaVOo06xb1uZ1crtslgO9zUeJtgYQZ2xaMtJ0DfOYnlueN6zHajYmtmTJd2i0w9BBgQLLL1r uWG4qdbw37I5YqXUjnFmO8mLh0X9r11x7ot3Cln9VFildN4AMRDjn51901+ppH5xzC1ZukqsO1sI WcNzn+p/9MIFqwfqqVZBTizPDM896UqFlWAfZDgfzy+d62V/KhY8VhvWwzWGUs722T+7/a4l5e6+ gGvR2LT4eLKatit2SC9WMTNcC+n1s4e1msdiDBmnjdOOaefDxsNGaTrIHMHrHT39owJKkH4ssBB0 el2XGi9y/cJ43CV1It0CMwQDBpfoNNlRMvioiY2axlE1qNvNS1zsIy62zbXDJbrqooxcE5Qkv8PX hv+8UoPQVnhTUYb9CUprZbRek+mgnLAZQVeeMRh9BoPRYBONLmZ3Bh30LsZRVD/qDkBhtiGvD2y8 7HpaXCQ4Qfe1SCsbWHUaH6s66mB1hwYqLIMjUgu2g2uBLLZXwT4PXvZwIPg13YQA477mDPEg0qo9 YEREIhwr6fHOerqbv0aaRLghdrsT5J2dlaY7mzFS/UiSIT8Bp+uI4Dx3XLNCyxvquOMAFgcGLo0e ZQKEVf9XUGwaCz4avoQ1OYwTYKg+fG7qEBg0Qn4avnrIj6GLD9/DTs1VJjTiGOuQKyKCSw+k/Jxw EaXPS2xnXxLH5174wEJv1FgwG4TZe9kF16wKKjYWnvt1xtAdTveOzGXPvpAuq1dRrZz/nUsJ2/XR f7pH+75gEEyCFd1TdvTLOoFFUgS34BG8gk/wg6ktBObLKCrtCawkA5Y/uOF5rCVTFLqFklAWKkIV vQx1oQdsjn1CU+gXBoRBMuDgAjhPWCIsFZYJy4UV4AUYEVYJq4U1wgVgrBgVLhQuEtYJ64UNwkZh k7BZGBMuFrYIl4A2mP7A3o4b/Znx/sLGFRtHz99UWn/Nh6+47oIrbrxox4c/8Gej69asF4T/A3RW KP0KZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iagoyNjEyCmVuZG9iagoxNyAwIG9iagozNjA5NApl bmRvYmoKeHJlZgowIDE4CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxMyAwMDAwMCBuIAow MDAwMDAwMDgwIDAwMDAwIG4gCjAwMDAwMDAxMzEgMDAwMDAgbiAKMDAwMDAwMDIzOCAwMDAwMCBu IAowMDAwMDAwMzQ1IDAwMDAwIG4gCjAwMDAwMDA0NDggMDAwMDAgbiAKMDAwMDAwNzM1NiAwMDAw MCBuIAowMDAwMDA3NDU5IDAwMDAwIG4gCjAwMDAwMTI4NzMgMDAwMDAgbiAKMDAwMDAxMzM3NyAw MDAwMCBuIAowMDAwMDEzNDE0IDAwMDAwIG4gCjAwMDAwMTM0MzUgMDAwMDAgbiAKMDAwMDAxMzQ1 NiAwMDAwMCBuIAowMDAwMDEzNzI5IDAwMDAwIG4gCjAwMDAwMTY0NDUgMDAwMDAgbiAKMDAwMDA1 MjYzMSAwMDAwMCBuIAowMDAwMDUyNjUyIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1Jvb3QgMiAwIFIg L1NpemUgMTkgL0luZm8gMTggMCBSID4+CgpzdGFydHhyZWYKNTI2NzQKJSVFT0YK --_004_384D0028F888584EB202C371301DDA7F3B5463cyclops05ttuedu_-- From kelly.grizzle@sailpoint.com Mon Sep 17 09:53:52 2012 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 8384D21F8557 for ; Mon, 17 Sep 2012 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEK0JuFX69t5 for ; Mon, 17 Sep 2012 09:53:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id C2E9D21F8731 for ; Mon, 17 Sep 2012 09:53:51 -0700 (PDT) Received: from mail66-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 16:53:50 +0000 Received: from mail66-co1 (localhost [127.0.0.1]) by mail66-co1-R.bigfish.com (Postfix) with ESMTP id D67F1680197; Mon, 17 Sep 2012 16:53:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT003.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I542M1432Id6eahzz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail66-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT003.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail66-co1 (localhost.localdomain [127.0.0.1]) by mail66-co1 (MessageSwitch) id 1347900828651550_32009; Mon, 17 Sep 2012 16:53:48 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.226]) by mail66-co1.bigfish.com (Postfix) with ESMTP id 9B556A00047; Mon, 17 Sep 2012 16:53:48 +0000 (UTC) Received: from BY2PRD0410HT003.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 16:53:47 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.140]) by BY2PRD0410HT003.namprd04.prod.outlook.com ([10.255.83.38]) with mapi id 14.16.0190.008; Mon, 17 Sep 2012 16:53:46 +0000 From: Kelly Grizzle To: Dale Olds , Samuel Erdtman Thread-Topic: [scim] evaluating filters: true, false, and undefined Thread-Index: AQHNkIkeAQWz4w2FCUy96E41LxonJJeGPL+AgARiEYCABChdMA== Date: Mon, 17 Sep 2012 16:53:46 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330EDAF4@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <504FEA8B.5050505@rbcon.com> <5053D747.4050004@rbcon.com> In-Reply-To: <5053D747.4050004@rbcon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] 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] evaluating filters: true, false, and undefined 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, 17 Sep 2012 16:53:52 -0000 > "Filters that contain references to attributes unknown to the server do n= ot > cause an error, but are evaluated such that those attributes are not pres= ent > on each resource." I would not support this. IMO filters that reference attributes that are u= nknown by the server should return an error, otherwise the client may get u= nexpected results. > we'd like to be able to write queries so that they work whether a particu= lar > scim server supports that extension or not. The client should be able to use the /Schemas resource to determine whether= the server supports the extension. In general, I am in favor of making things simpler for the client, but this= seems like a case where it would be beneficial for the server to be more s= trict. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dal= e Olds Sent: Friday, September 14, 2012 8:18 PM To: Samuel Erdtman Cc: scim@ietf.org Subject: Re: [scim] evaluating filters: true, false, and undefined I would expect that if "PR foobar" on a resource evaluates to false it mean= s "this resource has no value for attribute foobar", which is not quite the= same as "this server does not know what foobar means".=20 Nevertheless, if the server does not know what an attribute means no resour= ce will have a value for that attribute, so perhaps it's close enough. I ca= n't think of an example that's not overly contrived where the difference wo= uld matter. One of the reasons I brought this issue up is because there are places we'd= like to add our own scim extensions, and we'd like to be able to write que= ries so that they work whether a particular scim server supports that exten= sion or not. I also need to know how to handle undefined attributes in our = own server. Would the working group support this additional sentence to the first parag= raph of section 3.2.2.1? "Filters that contain references to attributes unknown to the server do not= cause an error, but are evaluated such that those attributes are not prese= nt on each resource." --Dale On 09/11/2012 11:21 PM, Samuel Erdtman wrote: > In the scimproxy we will probably do it by interpreting undefined as=20 > false i.e. the statements would be evaluated as you describe it. > However currently we only support one filter operation i.e. no 'and' > 'or' stuff yet. Have actually not tested much filtering during the=20 > interops. > > If you would want to require foobar to be precent before evaluating=20 > rest of the expression you could state it as folows: > ?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means=20 > present i.e. not undefined) > > Regards > //Samuel > > On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >> section 3.2.2.1 of the API doc describes filtering expressions and bindi= ngs. >> It is very clear about what should happen if an operator is not=20 >> defined (the example is 'regex'), but I do not see anything which=20 >> explicitly states what happens if an attribute in the expression is=20 >> not defined. The closest statement is in the first paragraph: "The=20 >> expression language that is used in the filter parameter supports=20 >> references to attributes and literals." I suppose that could mean a=20 >> reference to an unknown attribute is not supported, but it doesn't=20 >> really say that, and it doesn't say undefined attributes are an error. >> >> In filtering code for similar systems I've seen implementations that=20 >> did not require attributes to be defined. This can be quite natural=20 >> but does make the implementation more interesting. Consider this filter = of rooms: >> >> True if contains someone with hat size > 7 or wearing a read shirt. >> >> There may not be anyone wearing a hat in any room, but it would still=20 >> find rooms with red shirts. IOW, it only takes one true component of an = 'or' >> expression to make it true, even if one of the components is undefined. >> >> "True if someone with foobar > 7 or wearing a read shirt" works just=20 >> as well. >> >> This is not a big issue for us, we're just checking out=20 >> implementation options. What do most implementations currently do? >> >> --Dale >> >> >> >> >> >> >> _______________________________________________ >> 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 prvs=0607B39C4F=erik.wahlstrom@nexussafe.com Mon Sep 17 11:26:16 2012 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 C5FD321F8718 for ; Mon, 17 Sep 2012 11:26:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNtZFF39hjJg for ; Mon, 17 Sep 2012 11:26:15 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3276C21E8037 for ; Mon, 17 Sep 2012 11:26:14 -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.1.379.0; Mon, 17 Sep 2012 20:26:09 +0200 Received: from MARVMAILDB.technxs.com ([fe80::2c2c:914a:b623:9179]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Mon, 17 Sep 2012 20:26:12 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Dale Olds Thread-Topic: [scim] case preserving Thread-Index: AQHNkTPghZW9vplX8EGqfz9RZrqBvJeIZkmAgACgN4CAAKslAIAAgJQAgARiowA= Date: Mon, 17 Sep 2012 18:26:08 +0000 Message-ID: References: <504FE517.60508@rbcon.com> <5050986B.9010706@stpeter.im> <5050CB48.6010202@rbcon.com> <157AECA7-EB7D-48A4-800F-2150C571A554@nexussafe.com> <50510911.90704@rbcon.com> <6D1636CD-5C94-4F86-80C9-08511DE02297@nexussafe.com> <2975133F5CF7F1468951D6B2C49708D8104D6E4B@ALVMBXW01.prod.quest.corp> <5053996E.4010502@rbcon.com> In-Reply-To: <5053996E.4010502@rbcon.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F3EC672A1891C45AD64545E12355037@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Samuel Erdtman , Gil Kirkpatrick , Peter Saint-Andre , "scim@ietf.org" Subject: Re: [scim] case preserving 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, 17 Sep 2012 18:26:16 -0000 See below. On Sep 14, 2012, at 10:54 PM, Dale Olds wrote: > Erik, as I understand your reply to Gil, you'd prefer that a scim server = not munge your name due to "over ambitious validation rules" or "wrong enco= dings," but you'd like the scim spec to allow such munging to ease complian= ce and increase adoption. Correct.=20 >=20 > I'd like to increase adoption too, but we also need to have some agreed l= evel of usefulness -- hopefully a somewhat higher level than currently in t= he name munging wild. I can see situations that, if I could rely on a scim = server not munging a name, I would be more likely to choose a scim server i= nstead of some other service (or rolling my own). But should we build that into the protocol? If you do a bad implementation = of anything you will have a hard time getting new customers anyway. Provisi= oning users in a big company using many different systems usually means tha= t some of them stores data in a database that don't support for example, sa= me example again, Swedish characters. If I where the admin responsible for = the project I would prefer getting the users in the system with a couple of= strange characters instead of making the legacy system change database mod= els. >=20 > Also, Pamela Dingle has pointed out an attribute that I think is relevant= to this issue: externalId. Mostly we've talked about human names, but exte= rnalId is significant also. I may be wrong, but I have not been able to fin= d anything in the scim specs that says externalId is case-exact. If that's = true, it defaults to case-ignore. I would certainly not want a scim server = to be able to change case or other characters in an externalId. Yes, that's very true. That's a special thing indeed. The spec states the f= ollowing. "The value of the externalId attribute is always issued be the Se= rvice Consumer and can never be specified by the Service Provider." You cou= ld interpret that as case preserving, but I think that we could probably ex= plicitly specify it in more detail. Cheers Erik >=20 > --Dale >=20 > On 09/14/2012 06:13 AM, Erik Wahlstr=F6m wrote: >> Hi, >>=20 >> First of all I think is a corner and that we should not put the burden o= f what attributes are case preserving and who is not on a standard implemen= tor. And regarding a specific corner the last name example you mentioned is= great. My last name is Wahlstr=F6m and it includes the Swedish character = =F6 (sound confused and you got the pronunciation correct :)). Every now an= d then when I register to non swedish systems they complain about the stran= ge looking character =F6 and I'm force to use o instead, and sometime the s= ervers just change it to some random texts. It could be over ambitious vali= dation rules anywhere down the call stack to the storage and wrong encoding= s. To enable all legacy server to use SCIM we will run into one of these ov= er ambitious validation rules and the server must then be able to own all a= ttributes. >>=20 >> / Erik >>=20 >>=20 >>=20 >> On Sep 14, 2012, at 5:01 AM, Gil Kirkpatrick wrote: >>=20 >>>>> if we don't let servers store it's resources in there own way. >>> I disagree that something like the spelling of my last name is the "ser= ver's" resource. The storage medium is the server's resource, and attribute= s that the server creates for its own use are its own. I think that you can= argue that a username is a server's resource, or is at least subject to th= e server's syntax rules. But I would say the spelling of my last name (e.g.= ) is mine and the server should not alter it. What sort of corner are we bu= ilding ourselves into if we don't insist on case preservation, at least for= attributes that are not "owned" by the server? >>>=20 >>> Cheers, >>>=20 >>> -gil >>>=20 >>> -----Original Message----- >>> From: Erik Wahlstr=F6m [mailto:erik.wahlstrom@nexussafe.com] >>> Sent: Friday, September 14, 2012 3:28 AM >>> To: Dale Olds >>> Cc: Samuel Erdtman; Peter Saint-Andre; scim@ietf.org >>> Subject: Re: [scim] case preserving >>>=20 >>> Hi, >>>=20 >>> In general yes. I don't think it's a very good behavior to change it, b= ut I think we build our selfs in a corner if we don't let servers store it'= s resources in there own way. >>>=20 >>> Best regards >>> Erik >>>=20 >>>=20 >>> On Sep 13, 2012, at 12:13 AM, Dale Olds wrote: >>>=20 >>>> (changed subject line to distinguish from evolving thread about i18n, >>>> which IMO is a fine thread, but goes way beyond the original question) >>>>=20 >>>> Erik, >>>>=20 >>>> I actually mostly agree with your point, but I'm also trying to comple= te an implementation... >>>>=20 >>>> Do you think it should be acceptable for a scim server to force all us= erNames to uppercase (for some definition of uppercase)? >>>>=20 >>>> --Dale >>>>=20 >>>>=20 >>>> On 09/12/2012 10:57 AM, Erik Wahlstr=F6m wrote: >>>>> IMHO it's possible to change anything on the server side. Ignoring at= tributes, adding attributes, changing cases and so on. The client gets the = created resource back in the response and can inspect it to look at what wa= s created on the server side. Should the servers change a lot of things in = the creation? No I don't think so, but it should be possible to do to enabl= e more back end storage types. >>>>> / Erik >>>>>=20 >>>>>=20 >>>>> On Sep 12, 2012, at 7:50 PM, Dale Olds wrote: >>>>>=20 >>>>>> Peter, thanks for the comment, but in this case I'm not actually ask= ing for clarification on anything involving string comparison -- I think th= e existing spec covers case-insensitive comparisons and filtering. My quest= ion involved whether the spec should also indicate case-preserving. >>>>>>=20 >>>>>> Another way of asking my question would be: >>>>>>=20 >>>>>> Is a scim server free to change the data of an attribute value as lo= ng as the new value would produce the same matching result in a filter? >>>>>>=20 >>>>>> --Dale >>>>>>=20 >>>>>> On 09/12/2012 07:12 AM, Peter Saint-Andre wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>>=20 >>>>>>> I hate to say the dreaded word "internationalization", but if we're >>>>>>> talking about comparison of strings then there's much more involved >>>>>>> here than case. If we avoid comparison and just pass strings around >>>>>>> as a series of octets then we're probably safe... >>>>>>>=20 >>>>>>> On 9/12/12 12:01 AM, Samuel Erdtman wrote: >>>>>>>> As far as I can remember we have not discussed case-preservation. >>>>>>>>=20 >>>>>>>> I agree that it should be specified how to handle it. have I >>>>>>>> understod you correctly with these two statements: * >>>>>>>> Case-sensitive attributes must preserve case. * Case-insensitive >>>>>>>> attributes may not preserve case if explicitly stated, in >>>>>>>> similarly fashion as case-sensitivity is specified, otherwise case= must be preserved. >>>>>>>>=20 >>>>>>>> Regards //Samuel >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Sep 12, 2012 at 3:27 AM, Dale Olds wrote: >>>>>>>>> from my reading, the scim specs are very clear about >>>>>>>>> case-sensitivity issues. For example, there is this paragraph in >>>>>>>>> the API doc, section 3.2.2.1: >>>>>>>>>=20 >>>>>>>>> "String type attributes are case insensitive by default unless >>>>>>>>> the attribute type is defined as a caseExact string. Attribute >>>>>>>>> operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching >>>>>>>>> for all string attributes unless the attribute is defined as >>>>>>>>> caseExact. By default all string attributes are caseIgnore." >>>>>>>>>=20 >>>>>>>>> However, I have not been able to find anything which indicates >>>>>>>>> whether attribute values should be case-preserving -- unless >>>>>>>>> perhaps there is something relevant in the XML Schema Datatypes >>>>>>>>> Specification referred to in the schema doc. I would think there >>>>>>>>> would be something about it in the API doc for creating or >>>>>>>>> updating resources. >>>>>>>>>=20 >>>>>>>>> Personally, I don't remember using a case-insensitive, >>>>>>>>> non-case-preserving system since DOS 8.3 file names, but it has >>>>>>>>> come up in our implementation. >>>>>>>>>=20 >>>>>>>>> Has this been discussed and does the WG have rough consensus >>>>>>>>> about this? >>>>>>>>>=20 >>>>>>>>> My preference would be to specify case-preservation for >>>>>>>>> case-insensitive attributes. I think it's the most useful option, >>>>>>>>> and then we could rely on it as we cross system domains. It would >>>>>>>>> be inconvenient for a SCIM service to magically modify data >>>>>>>>> passed into it. >>>>>>>>>=20 >>>>>>>>> --Dale >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ scim mailing list >>>>>>>>> scim@ietf.org https://www.ietf.org/mailman/listinfo/scim >>>>>>>>>=20 >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>>>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>>>>>=20 >>>>>>> iEYEARECAAYFAlBQmGsACgkQNL8k5A2w/vzp3ACgvEaWhyhKb7bAEc8z+f2m8aJd >>>>>>> JBIAoOmDm6YXp1JC0rWd4AFqgtLFvyLI >>>>>>> =3DBJel >>>>>>> -----END PGP SIGNATURE----- >>>>>> _______________________________________________ >>>>>> scim mailing list >>>>>> scim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >=20 From edreux@cloudiway.com Tue Sep 18 04:32:20 2012 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 D16C421F8797 for ; Tue, 18 Sep 2012 04:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZjpHkGY7ZnJ for ; Tue, 18 Sep 2012 04:32:19 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 96B1A21F87D5 for ; Tue, 18 Sep 2012 04:32:19 -0700 (PDT) Received: from mail261-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Sep 2012 11:32:18 +0000 Received: from mail261-va3 (localhost [127.0.0.1]) by mail261-va3-R.bigfish.com (Postfix) with ESMTP id 24047130008C for ; Tue, 18 Sep 2012 11:32:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzc85fh1dbaId6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail261-va3: domain of cloudiway.com designates 157.56.252.53 as permitted sender) client-ip=157.56.252.53; envelope-from=edreux@cloudiway.com; helo=DB3PRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail261-va3 (localhost.localdomain [127.0.0.1]) by mail261-va3 (MessageSwitch) id 1347967935643314_27100; Tue, 18 Sep 2012 11:32:15 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.237]) by mail261-va3.bigfish.com (Postfix) with ESMTP id 906FFFC004D for ; Tue, 18 Sep 2012 11:32:15 +0000 (UTC) Received: from DB3PRD0610HT004.eurprd06.prod.outlook.com (157.56.252.53) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Sep 2012 11:32:15 +0000 Received: from DB3PRD0610MB356.eurprd06.prod.outlook.com ([169.254.11.223]) by DB3PRD0610HT004.eurprd06.prod.outlook.com ([10.255.47.39]) with mapi id 14.16.0190.008; Tue, 18 Sep 2012 11:32:12 +0000 From: Emmanuel Dreux To: "scim@ietf.org" Thread-Topic: JSON Patch Thread-Index: Ac2VkT0agDeaY/90SgS2zz02e+uvaA== Date: Tue, 18 Sep 2012 11:32:11 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.84.144.145] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA8968FDB3PRD0610MB356_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: [scim] JSON Patch 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, 18 Sep 2012 11:32:21 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA8968FDB3PRD0610MB356_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What do you think of including the support of this? JavaScript Object Notation (JSON) [RFC4627] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a method to perform partial modifications to resources. The JSON Patch media type "application/json-patch" is a JSON document structure for expressing a sequence of operations to apply to a target JSON document, suitable for use with the HTTP PATCH method. http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux --_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA8968FDB3PRD0610MB356_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
What do you think of including the support of thi=
s?
 
   JavaScript Object Notation (JSON) [<=
/span>RFC4627] is a common format=
 for
   the exchange and storage of structur=
ed data.  HTTP PATCH [RFC5=
789]
   extends the Hypertext Transfer Proto=
col (HTTP) [R=
FC2616] with a
   method to perform partial modificati=
ons to resources.
 
   The JSON Patch media type "appl=
ication/json-patch" is a JSON document
   structure for expressing a sequence =
of operations to apply to a
   targe=
t JSON document, suitable for use with the HTTP PATCH method.

 

http://tools.ietf.org/html/draft-i= etf-appsawg-json-patch-04=

 

--

Cordialement / Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

--_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA8968FDB3PRD0610MB356_-- From olds@rbcon.com Tue Sep 18 22:48:15 2012 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 C38FE21F846A for ; Tue, 18 Sep 2012 22:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA6+6OgzrMyX for ; Tue, 18 Sep 2012 22:48:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A21A821F846B for ; Tue, 18 Sep 2012 22:48:14 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1597444pbb.31 for ; Tue, 18 Sep 2012 22:48:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=eypZAztk6ZsHPfXA8Dt+tv6tyuyn4LHs65/12/dDARc=; b=S8jnueyftxJ3QlvJGMITddyLamzojvxWCSW/pwlZEqM27raWkgNiaPagxnjwXkyV+f 2/tDERNjRYM2qFmDhHKxUyUzgi0pdirpPgX3zJIDODUyPR2X+5WPxdZdCDCqCxNZPJQG EVqTGMX9o7w61Ea9sFeZsbmVlJ1ZqJSR7VJJNxkqkIQW90Mihc9fdy1A8sZ9lcQ8nv2a N+Am3IEZJ1zvdZ6axBH0G+Avi+tB3ENrG+dxOeU1XxSE4UE1KZa4frgBwGj8KGOaWJi+ n4Ww9+fob8OS6tmUIz7tvtrvdWAE6xZhD7kukr4/UmVRi4594rxm4R+l32ZbDJmjJI9Z h/sA== Received: by 10.68.130.10 with SMTP id oa10mr4584566pbb.109.1348033694235; Tue, 18 Sep 2012 22:48:14 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id pq7sm1243607pbb.25.2012.09.18.22.48.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 22:48:13 -0700 (PDT) Message-ID: <50595C9B.6080402@rbcon.com> Date: Tue, 18 Sep 2012 22:48:11 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnAXLh7bjRHzA3MyLcC6Ot6CccaGrtGDT5qqvugPYslL7gUE8wQDWNZItLQQXOLFC4XU19l Subject: [scim] source code for compliance tests 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, 19 Sep 2012 05:48:15 -0000 I apologize to the wg that this is not directly related to the scim specs, but I find that compliance tests are very useful to clarify the specs. The scim WG (as represented at simplecloud.info) has taken the the bold and quite useful step to publish compliance tests. I don't expect the tests determine some PM's view of marketing compliance -- I'd just like to know that the implementers of the spec agree about what the spec means. Is the source code for the tests available? --Dale From prvs=9609853463=erik.wahlstrom@nexussafe.com Wed Sep 19 00:03:48 2012 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 BF4CA21E8096 for ; Wed, 19 Sep 2012 00:03:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdptPre4HCtc for ; Wed, 19 Sep 2012 00:03:47 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5A21F8611 for ; Wed, 19 Sep 2012 00:03:44 -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.1.379.0; Wed, 19 Sep 2012 09:03:40 +0200 Received: from MARVMAILDB.technxs.com ([fe80::2c2c:914a:b623:9179]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 19 Sep 2012 09:03:41 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Dale Olds , Samuel Erdtman , Daniel Lindau Thread-Topic: [scim] source code for compliance tests Thread-Index: AQHNlipgGuStLtM+KEaRaZct1UMC2ZeRG+0A Date: Wed, 19 Sep 2012 07:03:40 +0000 Message-ID: <73690037-3ADB-41E0-AFA3-275D9E37CEE1@nexussafe.com> References: <50595C9B.6080402@rbcon.com> In-Reply-To: <50595C9B.6080402@rbcon.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: multipart/alternative; boundary="_000_736900373ADB41E0AFA3275D9E37CEE1nexussafecom_" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] source code for compliance tests 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, 19 Sep 2012 07:03:48 -0000 --_000_736900373ADB41E0AFA3275D9E37CEE1nexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dale, Great news that you find it useful. We would love some feedback on it. It's= still in beta and we have plans to add and improve existing tests. Code can currently be found here: http://code.google.com/p/scimproxy/ / Erik On Sep 19, 2012, at 7:48 AM, Dale Olds wrote: I apologize to the wg that this is not directly related to the scim specs, = but I find that compliance tests are very useful to clarify the specs. The = scim WG (as represented at simplecloud.info) has t= aken the the bold and quite useful step to publish compliance tests. I don'= t expect the tests determine some PM's view of marketing compliance -- I'd = just like to know that the implementers of the spec agree about what the sp= ec means. Is the source code for the tests available? --Dale _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_736900373ADB41E0AFA3275D9E37CEE1nexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8CC736EF8700EA4F9D56B0CFA64C72D6@nexussafe.com> Content-Transfer-Encoding: quoted-printable Hi Dale,

Great news that you find it useful. We would love some feedback on it.= It's still in beta and we have plans to add and improve existing tests.

Code can currently be found here: http://code.google.com/p/scimproxy/

/ Erik


On Sep 19, 2012, at 7:48 AM, Dale Olds wrote:

I apologize to the wg that this is not directly related to the scim sp= ecs, but I find that compliance tests are very useful to clarify the specs.= The scim WG (as represented at simplecloud.info) has taken the the= bold and quite useful step to publish compliance tests. I don't expect the= tests determine some PM's view of marketing compliance -- I'd just like to= know that the implementers of the spec agree about what the spec means.

Is the source code for the tests available?

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

--_000_736900373ADB41E0AFA3275D9E37CEE1nexussafecom_-- From hannes.tschofenig@gmx.net Wed Sep 19 00:04:38 2012 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 D718521F8617 for ; Wed, 19 Sep 2012 00:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0heMUYcf1K0s for ; Wed, 19 Sep 2012 00:04:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D316121F8616 for ; Wed, 19 Sep 2012 00:04:36 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2012 07:04:34 -0000 Received: from unknown (EHLO [10.255.129.136]) [194.251.119.201] by mail.gmx.net (mp041) with SMTP; 19 Sep 2012 09:04:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/gIL0EycHgGA1o+65L2/SUbBcF/RiGV0UbusSYZ5 NESfRoAmuhAJB3 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50595C9B.6080402@rbcon.com> Date: Wed, 19 Sep 2012 10:04:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50595C9B.6080402@rbcon.com> To: Dale Olds X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "scim@ietf.org" , Hannes Tschofenig Subject: Re: [scim] source code for compliance tests 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, 19 Sep 2012 07:04:39 -0000 Hi Dale,=20 I agree that interoperability tests are quite important but, as you = said, it would be very helpful to know the details of these tests.=20 In addition there is the challenge that these tests (regardless of = whether they are done online or not) are a bit misleading at this point = in time when the work on the protocol is still at an early stage. It may = lead someone in the false believe that their code is interoperable = although that only means interoperability with a work-in-progress = specification that may change any minute.=20 Ciao Hannes PS: I had worked on test cases in a different IETF working group, called = DIME, and published them as IETF drafts before we used them for the = interop-events. Here is one example:=20 http://tools.ietf.org/html/draft-fajardo-dime-base-test-suite-02 Maybe the group can create something similar.=20 On Sep 19, 2012, at 8:48 AM, Dale Olds wrote: > I apologize to the wg that this is not directly related to the scim = specs, but I find that compliance tests are very useful to clarify the = specs. The scim WG (as represented at simplecloud.info) has taken the = the bold and quite useful step to publish compliance tests. I don't = expect the tests determine some PM's view of marketing compliance -- I'd = just like to know that the implementers of the spec agree about what the = spec means. >=20 > Is the source code for the tests available? >=20 > --Dale > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From prvs=86094D6FAB=erik.wahlstrom@nexussafe.com Wed Sep 19 00:25:17 2012 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 5D08821F8692 for ; Wed, 19 Sep 2012 00:25:17 -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, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2FlOiU26nrd for ; Wed, 19 Sep 2012 00:25:16 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2779621F8691 for ; Wed, 19 Sep 2012 00:25:15 -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.1.379.0; Wed, 19 Sep 2012 09:25:12 +0200 Received: from MARVMAILDB.technxs.com ([fe80::2c2c:914a:b623:9179]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 19 Sep 2012 09:25:14 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Hannes Tschofenig Thread-Topic: [scim] source code for compliance tests Thread-Index: AQHNlipgGuStLtM+KEaRaZct1UMC2ZeRHCsAgAAFyAA= Date: Wed, 19 Sep 2012 07:25:13 +0000 Message-ID: <39E8D1F8-3793-4C1F-AFD2-F081526EE15B@nexussafe.com> References: <50595C9B.6080402@rbcon.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <526A553C6E93604B826945CC0F2E3776@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dale Olds , "scim@ietf.org" Subject: Re: [scim] source code for compliance tests 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, 19 Sep 2012 07:25:17 -0000 Hi, That site tests the 1.1 specification that earlier was developed under the = Open Web Foundation before the IETF work started. I think it's very importa= nt to separate the two (hence the no email to this list when tests went liv= e). We should probably also make that very clear on the simplecloud site th= at tests has nothing to do with the work done here. +1 on that a document describing the tests for the work done here would be = good. / Erik On Sep 19, 2012, at 9:04 AM, Hannes Tschofenig wrote: > Hi Dale,=20 >=20 > I agree that interoperability tests are quite important but, as you said,= it would be very helpful to know the details of these tests.=20 > In addition there is the challenge that these tests (regardless of whethe= r they are done online or not) are a bit misleading at this point in time w= hen the work on the protocol is still at an early stage. It may lead someon= e in the false believe that their code is interoperable although that only = means interoperability with a work-in-progress specification that may chang= e any minute.=20 >=20 > Ciao > Hannes >=20 > PS: I had worked on test cases in a different IETF working group, called = DIME, and published them as IETF drafts before we used them for the interop= -events. Here is one example:=20 > http://tools.ietf.org/html/draft-fajardo-dime-base-test-suite-02 >=20 > Maybe the group can create something similar.=20 >=20 > On Sep 19, 2012, at 8:48 AM, Dale Olds wrote: >=20 >> I apologize to the wg that this is not directly related to the scim spec= s, but I find that compliance tests are very useful to clarify the specs. T= he scim WG (as represented at simplecloud.info) has taken the the bold and = quite useful step to publish compliance tests. I don't expect the tests det= ermine some PM's view of marketing compliance -- I'd just like to know that= the implementers of the spec agree about what the spec means. >>=20 >> Is the source code for the tests available? >>=20 >> --Dale >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Wed Sep 19 00:47:14 2012 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 3C46521F86AB for ; Wed, 19 Sep 2012 00:47:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaeaRfRni0ch for ; Wed, 19 Sep 2012 00:47:13 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE821F86AA for ; Wed, 19 Sep 2012 00:47:12 -0700 (PDT) Received: from [158.37.171.136] ([158.37.171.136]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q8J7l6Bm024550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Sep 2012 09:47:10 +0200 (CEST) Message-ID: <5059787A.30306@mnt.se> Date: Wed, 19 Sep 2012 09:47:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: scim@ietf.org References: <50595C9B.6080402@rbcon.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] source code for compliance tests 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, 19 Sep 2012 07:47:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/19/2012 09:04 AM, Hannes Tschofenig wrote: > Hi Dale, > > I agree that interoperability tests are quite important but, as you > said, it would be very helpful to know the details of these tests. > In addition there is the challenge that these tests (regardless of > whether they are done online or not) are a bit misleading at this > point in time when the work on the protocol is still at an early > stage. It may lead someone in the false believe that their code is > interoperable although that only means interoperability with a > work-in-progress specification that may change any minute. > Agreed. Keep tracking the speck but please note to all your users that the spec is very much a moving target at this point. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBZeHoACgkQ8Jx8FtbMZnfuUACfSEqQyZQ7+SnkIj1FRRoq30O1 EOsAmwSlVAPwKDVkuoLBAO3+S3DVLUXG =APHS -----END PGP SIGNATURE----- From kelly.grizzle@sailpoint.com Wed Sep 19 08:45:37 2012 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 D763E21F8709 for ; Wed, 19 Sep 2012 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2hHuws+dxFK for ; Wed, 19 Sep 2012 08:45:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01821F870A for ; Wed, 19 Sep 2012 08:45:33 -0700 (PDT) Received: from mail108-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 15:45:32 +0000 Received: from mail108-tx2 (localhost [127.0.0.1]) by mail108-tx2-R.bigfish.com (Postfix) with ESMTP id 7945F3C01B3 for ; Wed, 19 Sep 2012 15:45:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic85fh1dbaId6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail108-tx2: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail108-tx2 (localhost.localdomain [127.0.0.1]) by mail108-tx2 (MessageSwitch) id 1348069530343258_6591; Wed, 19 Sep 2012 15:45:30 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.246]) by mail108-tx2.bigfish.com (Postfix) with ESMTP id 504801A0059; Wed, 19 Sep 2012 15:45:30 +0000 (UTC) Received: from BY2PRD0410HT004.namprd04.prod.outlook.com (157.56.236.85) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 15:45:27 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.78]) by BY2PRD0410HT004.namprd04.prod.outlook.com ([10.255.83.39]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 15:45:26 +0000 From: Kelly Grizzle To: Emmanuel Dreux , "scim@ietf.org" Thread-Topic: JSON Patch Thread-Index: Ac2VkT0agDeaY/90SgS2zz02e+uvaAA6wdUg Date: Wed, 19 Sep 2012 15:45:25 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373E79AF0C@BY2PRD0410MB354.namprd04.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: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373E79AF0CBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] JSON Patch 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, 19 Sep 2012 15:45:38 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373E79AF0CBY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Generally, I like the diff-like structure of JSON Patch and would like to s= ee something like this in SCIM. The main problem that I have with it is th= at it relies on JSON Pointer, which uses indexes to address list elements (= eg - /bar/mylist/1). Index-based patching does not seem like enough for SC= IM. For example, a common use case for patch is to add or remove a member = to/from a group. Having to know the list index before issuing this operati= on seems onerous. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emm= anuel Dreux Sent: Tuesday, September 18, 2012 6:32 AM To: scim@ietf.org Subject: [scim] JSON Patch What do you think of including the support of this? JavaScript Object Notation (JSON) [RFC4627] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a method to perform partial modifications to resources. The JSON Patch media type "application/json-patch" is a JSON document structure for expressing a sequence of operations to apply to a target JSON document, suitable for use with the HTTP PATCH method. http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 -- Cordialement / Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux --_000_56C3C758F9D6534CA3778EAA1E0C34373E79AF0CBY2PRD0410MB354_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Generally, I like the = diff-like structure of JSON Patch and would like to see something like this= in SCIM.  The main problem that I have with it is that it relies on J= SON Pointer, which uses indexes to address list elements (eg - /bar/mylist/1).  Index-based patching does not se= em like enough for SCIM.  For example, a common use case for patch is = to add or remove a member to/from a group.  Having to know the list in= dex before issuing this operation seems onerous.

 

--Kelly

 

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Tuesday, September 18, 2012 6:32 AM
To: scim@ietf.org
Subject: [scim] JSON Patch

 

What do you think of including the support of this?
 
   JavaScript Object Notation (JSON) [RFC4627] is a common format for
   the exchange and storage of structured data.  HTTP P=
ATCH [RFC5789=
]
   extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a
   method to perform partial modifications to resources.
 
   The JSON Patch media type "application/json-patch&qu=
ot; is a JSON document
   structure for expressing a sequence of operations to appl=
y to a
   target JSON document, suit=
able for use with the HTTP PATCH method.

 

http://tools.iet= f.org/html/draft-ietf-appsawg-json-patch-04

 

--

Cordialement / Regards,=

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70=

skype: Emmanuel.Dreux

 

--_000_56C3C758F9D6534CA3778EAA1E0C34373E79AF0CBY2PRD0410MB354_-- From andrew@badera.us Thu Sep 20 11:00:14 2012 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 DEE7D21F8810 for ; Thu, 20 Sep 2012 11:00:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGv7KlqHqOzN for ; Thu, 20 Sep 2012 11:00:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD621F880D for ; Thu, 20 Sep 2012 11:00:14 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3142363vbb.31 for ; Thu, 20 Sep 2012 11:00:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=lIhzqLOc+nSHkmQ3/2m7yyKvBbcKisKhPajsw00FpHo=; b=p1OQaaF4wYDG7Y7PjeiN5r8az4BDShghMru73o8/jumZJ++5Sm+VLizYMUvAIqNXSm U7lTm5xiMtww2PNA7UxQV8nwoJPVx8Px8tNXyEaB/sZ0Ng0vw+t3eCuQvdCsAlW68icm M53ERI0TedRU9JE3kpBEejyJwNu+6LdS+cEQEDzYyQAMUP0uWqc4coEPmMywLebxKbO6 28xrEHo3r+fDZZPAx80/dZrZ6XQM2zPFTxQ/QC3PXHqEbOhRF7kIYPBGtPS2bE++rwXX /M2GT4iTOskx1IP1Ddb54SlbxSKOPwbIuDgnGd4f2U6kXlPdeh/DS4WqpHV3abFy5BL/ zOfg== Received: by 10.58.0.7 with SMTP id 7mr1551793vea.18.1348164013500; Thu, 20 Sep 2012 11:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.225.225 with HTTP; Thu, 20 Sep 2012 10:59:53 -0700 (PDT) From: Andrew Badera Date: Thu, 20 Sep 2012 12:59:53 -0500 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33d3661fa8bb04ca25e507 X-Gm-Message-State: ALoCoQkLHEdqz3nFjQbQtkj3qWcZM3ppWviVFAtdixKinGi8SVbPDrUCFKtu0cHNY5a7dGX7LHEb Subject: [scim] Proprietary/custom properties 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, 20 Sep 2012 18:00:15 -0000 --047d7b33d3661fa8bb04ca25e507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all- If an organization is looking at early adoption of SCIM and has a number of additional properties associated with users and groups that aren't part of core schema or existing/proposed extensions, is there a preferred or recommended way of handling those values? My thoughts to date are: 1. Treat it like an unofficial extension, (but then wonder about returning supporting schema and configs, though we may not support that at this point anyhow) 2. Bolt-on a users and groups attribute system, which can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining and supporting attributes and their metadata, supporting retrieval and modification on a per-attribute basis, etc.) 3. Something I haven't considered, or missed being discussed on-list previously? These are not (strictly) LDAP values, though many are currently stored in otherwise-unused, sometimes repurposed LDAP fields. These run the gamut from users being "enabled" or "disabled" to user's roles (beyond usertype) to user's customer details, etc. Thanks in advance for any insights- =E2=88=9E Andy Badera =E2=88=9E Technical Evangelist, MPS Partners, Chicago =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera --047d7b33d3661fa8bb04ca25e507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all-

If an organization is looking at early adopti= on of SCIM and has a number of additional properties associated with users = and groups that aren't part of core schema or existing/proposed extensi= ons, is there a preferred or recommended way of handling those values? My t= houghts to date are:

1. Treat it like an unofficial extension, (but then won= der about returning supporting schema and configs, though we may not suppor= t that at this point anyhow)
2. Bolt-on a users and groups attrib= ute system, which can easily get ugly, bloated, onerous and non-intuitive, = fast. (Defining and supporting attributes and their metadata, supporting re= trieval and modification on a per-attribute basis, etc.)
3. Something I haven't considered, or missed being discussed on-li= st previously?

These are not (strictly) LDAP value= s, though many are currently stored in otherwise-unused, sometimes repurpos= ed LDAP fields. These run the gamut from users being "enabled" or= "disabled" to user's roles (beyond usertype) to user's c= ustomer details, etc.

Thanks in advance for any insights-
= =E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chic= ago
=E2=88=9E This email is: [ ] bloggable [x] ask first [ ] priv= ate
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera


--047d7b33d3661fa8bb04ca25e507-- From edreux@cloudiway.com Thu Sep 20 12:19:14 2012 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 E142121E808B for ; Thu, 20 Sep 2012 12:19:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqi4ojmA50r9 for ; Thu, 20 Sep 2012 12:19:08 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8710E21E8084 for ; Thu, 20 Sep 2012 12:19:08 -0700 (PDT) Received: from mail168-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Sep 2012 19:19:01 +0000 Received: from mail168-co1 (localhost [127.0.0.1]) by mail168-co1-R.bigfish.com (Postfix) with ESMTP id 91D0820148; Thu, 20 Sep 2012 19:19:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT001.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zzc89bh1443Ic857h14ffId6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail168-co1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT001.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail168-co1 (localhost.localdomain [127.0.0.1]) by mail168-co1 (MessageSwitch) id 1348168738874672_10030; Thu, 20 Sep 2012 19:18:58 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.243]) by mail168-co1.bigfish.com (Postfix) with ESMTP id C91D41C004B; Thu, 20 Sep 2012 19:18:58 +0000 (UTC) Received: from AMXPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.213) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Sep 2012 19:18:57 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.4.167]) by AMXPRD0610HT001.eurprd06.prod.outlook.com ([10.255.58.36]) with mapi id 14.16.0190.008; Thu, 20 Sep 2012 19:18:55 +0000 From: Emmanuel Dreux To: Andrew Badera , "scim@ietf.org" Thread-Topic: [scim] Proprietary/custom properties Thread-Index: AQHNl2KiiYQWoFChrUyG+mktf3qWSZeTmXfQ Date: Thu, 20 Sep 2012 19:18:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.209.63.230] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA97463AMXPRD0610MB353_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: Re: [scim] Proprietary/custom properties 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, 20 Sep 2012 19:19:14 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA97463AMXPRD0610MB353_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3VyIG93biBmZWVkYmFjayA6DQpXZeKAmXJlIGludGVncmF0aW5nIFNDSU0gb24gMiBTQUFTIHBy b3ZpZGVy4oCZcyBwbGF0Zm9ybXMuDQpGb3IgYm90aCAoPSAxMDAlKSwgd2XigJlyZSBleHRlbmRp bmcgdGhlIGNvcmUgdXNlciBzY2hlbWEgYmVjYXVzZSB3ZSBoYXZlIHRvIGhhbmRsZSBub24gc3Rh bmRhcmQgZGVmaW5lZCBhdHRyaWJ1dGVzLg0KDQotLQ0KQ29yZGlhbGVtZW50IC8gUmVnYXJkcywN CkVtbWFudWVsIERyZXV4DQpodHRwOi8vd3d3LmNsb3VkaXdheS5jb20NClRlbDogKzMzIDQgMjYg NzggMTcgNTgNCk1vYmlsZTogKzMzIDYgNDcgODEgMjYgNzANCnNreXBlOiBFbW1hbnVlbC5EcmV1 eA0KDQpEZSA6IEFuZHJldyBCYWRlcmEgW21haWx0bzphbmRyZXdAYmFkZXJhLnVzXQ0KRW52b3nD qSA6IGpldWRpIDIwIHNlcHRlbWJyZSAyMDEyIDIwOjAwDQrDgCA6IHNjaW1AaWV0Zi5vcmcNCk9i amV0IDogW3NjaW1dIFByb3ByaWV0YXJ5L2N1c3RvbSBwcm9wZXJ0aWVzDQoNCkhlbGxvIGFsbC0N Cg0KSWYgYW4gb3JnYW5pemF0aW9uIGlzIGxvb2tpbmcgYXQgZWFybHkgYWRvcHRpb24gb2YgU0NJ TSBhbmQgaGFzIGEgbnVtYmVyIG9mIGFkZGl0aW9uYWwgcHJvcGVydGllcyBhc3NvY2lhdGVkIHdp dGggdXNlcnMgYW5kIGdyb3VwcyB0aGF0IGFyZW4ndCBwYXJ0IG9mIGNvcmUgc2NoZW1hIG9yIGV4 aXN0aW5nL3Byb3Bvc2VkIGV4dGVuc2lvbnMsIGlzIHRoZXJlIGEgcHJlZmVycmVkIG9yIHJlY29t bWVuZGVkIHdheSBvZiBoYW5kbGluZyB0aG9zZSB2YWx1ZXM/IE15IHRob3VnaHRzIHRvIGRhdGUg YXJlOg0KDQoxLiBUcmVhdCBpdCBsaWtlIGFuIHVub2ZmaWNpYWwgZXh0ZW5zaW9uLCAoYnV0IHRo ZW4gd29uZGVyIGFib3V0IHJldHVybmluZyBzdXBwb3J0aW5nIHNjaGVtYSBhbmQgY29uZmlncywg dGhvdWdoIHdlIG1heSBub3Qgc3VwcG9ydCB0aGF0IGF0IHRoaXMgcG9pbnQgYW55aG93KQ0KMi4g Qm9sdC1vbiBhIHVzZXJzIGFuZCBncm91cHMgYXR0cmlidXRlIHN5c3RlbSwgd2hpY2ggY2FuIGVh c2lseSBnZXQgdWdseSwgYmxvYXRlZCwgb25lcm91cyBhbmQgbm9uLWludHVpdGl2ZSwgZmFzdC4g KERlZmluaW5nIGFuZCBzdXBwb3J0aW5nIGF0dHJpYnV0ZXMgYW5kIHRoZWlyIG1ldGFkYXRhLCBz dXBwb3J0aW5nIHJldHJpZXZhbCBhbmQgbW9kaWZpY2F0aW9uIG9uIGEgcGVyLWF0dHJpYnV0ZSBi YXNpcywgZXRjLikNCjMuIFNvbWV0aGluZyBJIGhhdmVuJ3QgY29uc2lkZXJlZCwgb3IgbWlzc2Vk IGJlaW5nIGRpc2N1c3NlZCBvbi1saXN0IHByZXZpb3VzbHk/DQoNClRoZXNlIGFyZSBub3QgKHN0 cmljdGx5KSBMREFQIHZhbHVlcywgdGhvdWdoIG1hbnkgYXJlIGN1cnJlbnRseSBzdG9yZWQgaW4g b3RoZXJ3aXNlLXVudXNlZCwgc29tZXRpbWVzIHJlcHVycG9zZWQgTERBUCBmaWVsZHMuIFRoZXNl IHJ1biB0aGUgZ2FtdXQgZnJvbSB1c2VycyBiZWluZyAiZW5hYmxlZCIgb3IgImRpc2FibGVkIiB0 byB1c2VyJ3Mgcm9sZXMgKGJleW9uZCB1c2VydHlwZSkgdG8gdXNlcidzIGN1c3RvbWVyIGRldGFp bHMsIGV0Yy4NCg0KVGhhbmtzIGluIGFkdmFuY2UgZm9yIGFueSBpbnNpZ2h0cy0NCuKIniBBbmR5 IEJhZGVyYQ0K4oieIFRlY2huaWNhbCBFdmFuZ2VsaXN0LCBNUFMgUGFydG5lcnMsIENoaWNhZ28N CuKIniBUaGlzIGVtYWlsIGlzOiBbIF0gYmxvZ2dhYmxlIFt4XSBhc2sgZmlyc3QgWyBdIHByaXZh dGUNCuKIniBHb29nbGUgbWU6IGh0dHA6Ly93d3cuZ29vZ2xlLmNvbS9zZWFyY2g/cT1hbmRyZXcl MjBiYWRlcmENCg0K --_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA97463AMXPRD0610MB353_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdXIgb3duIGZlZWRi YWNrJm5ic3A7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Xi gJlyZSBpbnRlZ3JhdGluZyBTQ0lNIG9uIDIgU0FBUyBwcm92aWRlcuKAmXMgcGxhdGZvcm1zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGJvdGggKD0gMTAw JSksIHdl4oCZcmUgZXh0ZW5kaW5nIHRoZSBjb3JlIHVzZXIgc2NoZW1hIGJlY2F1c2Ugd2UgaGF2 ZSB0byBoYW5kbGUgbm9uIHN0YW5kYXJkIGRlZmluZWQgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db3JkaWFsZW1lbnQg LyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FbW1hbnVlbCBEcmV1eDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5odHRwOi8vd3d3LmNsb3VkaXdheS5jb208bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGVsOiAmIzQzOzMzIDQgMjYgNzggMTcgNTg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9iaWxlOiAmIzQzOzMzIDYgNDcgODEgMjYgNzA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c2t5cGU6IEVtbWFudWVsLkRyZXV4PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQW5kcmV3IEJhZGVyYSBbbWFpbHRvOmFuZHJld0BiYWRlcmEudXNdDQo8YnI+ DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMjAgc2VwdGVtYnJlIDIwMTIgMjA6MDA8YnI+ DQo8Yj7DgCZuYnNwOzo8L2I+IHNjaW1AaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFtzY2ltXSBQcm9wcmlldGFyeS9jdXN0b20gcHJvcGVydGllczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBhbGwtPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhbiBvcmdhbml6YXRpb24gaXMgbG9va2luZyBhdCBlYXJs eSBhZG9wdGlvbiBvZiBTQ0lNIGFuZCBoYXMgYSBudW1iZXIgb2YgYWRkaXRpb25hbCBwcm9wZXJ0 aWVzIGFzc29jaWF0ZWQgd2l0aCB1c2VycyBhbmQgZ3JvdXBzIHRoYXQgYXJlbid0IHBhcnQgb2Yg Y29yZSBzY2hlbWEgb3IgZXhpc3RpbmcvcHJvcG9zZWQgZXh0ZW5zaW9ucywgaXMgdGhlcmUgYSBw cmVmZXJyZWQgb3IgcmVjb21tZW5kZWQgd2F5DQogb2YgaGFuZGxpbmcgdGhvc2UgdmFsdWVzPyBN eSB0aG91Z2h0cyB0byBkYXRlIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gVHJlYXQgaXQgbGlrZSBhbiB1bm9mZmljaWFsIGV4dGVu c2lvbiwgKGJ1dCB0aGVuIHdvbmRlciBhYm91dCByZXR1cm5pbmcgc3VwcG9ydGluZyBzY2hlbWEg YW5kIGNvbmZpZ3MsIHRob3VnaCB3ZSBtYXkgbm90IHN1cHBvcnQgdGhhdCBhdCB0aGlzIHBvaW50 IGFueWhvdyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIuIEJvbHQtb24gYSB1c2VycyBhbmQgZ3JvdXBzIGF0dHJpYnV0ZSBzeXN0ZW0sIHdoaWNo IGNhbiBlYXNpbHkgZ2V0IHVnbHksIGJsb2F0ZWQsIG9uZXJvdXMgYW5kIG5vbi1pbnR1aXRpdmUs IGZhc3QuIChEZWZpbmluZyBhbmQgc3VwcG9ydGluZyBhdHRyaWJ1dGVzIGFuZCB0aGVpciBtZXRh ZGF0YSwgc3VwcG9ydGluZyByZXRyaWV2YWwgYW5kIG1vZGlmaWNhdGlvbiBvbiBhIHBlci1hdHRy aWJ1dGUgYmFzaXMsDQogZXRjLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjMuIFNvbWV0aGluZyBJIGhhdmVuJ3QgY29uc2lkZXJlZCwgb3IgbWlz c2VkIGJlaW5nIGRpc2N1c3NlZCBvbi1saXN0IHByZXZpb3VzbHk/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGFyZSBub3QgKHN0cmlj dGx5KSBMREFQIHZhbHVlcywgdGhvdWdoIG1hbnkgYXJlIGN1cnJlbnRseSBzdG9yZWQgaW4gb3Ro ZXJ3aXNlLXVudXNlZCwgc29tZXRpbWVzIHJlcHVycG9zZWQgTERBUCBmaWVsZHMuIFRoZXNlIHJ1 biB0aGUgZ2FtdXQgZnJvbSB1c2VycyBiZWluZyAmcXVvdDtlbmFibGVkJnF1b3Q7IG9yICZxdW90 O2Rpc2FibGVkJnF1b3Q7IHRvIHVzZXIncyByb2xlcyAoYmV5b25kIHVzZXJ0eXBlKSB0byB1c2Vy J3MgY3VzdG9tZXINCiBkZXRhaWxzLCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgaW5zaWdo dHMtPGJyIGNsZWFyPSJhbGwiPg0K4oieIEFuZHkgQmFkZXJhPGJyPg0K4oieIFRlY2huaWNhbCBF dmFuZ2VsaXN0LCBNUFMgUGFydG5lcnMsIENoaWNhZ288bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ 4oieIFRoaXMgZW1haWwgaXM6IFsgXSBibG9nZ2FibGUgW3hdIGFzayBmaXJzdCBbIF0gcHJpdmF0 ZTxicj4NCuKIniBHb29nbGUgbWU6IDxhIGhyZWY9Imh0dHA6Ly93d3cuZ29vZ2xlLmNvbS9zZWFy Y2g/cT1hbmRyZXclMjBiYWRlcmEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuZ29vZ2xl LmNvbS9zZWFyY2g/cT1hbmRyZXclMjBiYWRlcmE8L2E+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DF63ACC82673DB40A7AAC08FFA71DFBD3AA97463AMXPRD0610MB353_-- From andrew@badera.us Thu Sep 20 12:39:37 2012 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 D9C4121F8683 for ; Thu, 20 Sep 2012 12:39:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv70dSqNsmfw for ; Thu, 20 Sep 2012 12:39:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B82DE21F867C for ; Thu, 20 Sep 2012 12:39:36 -0700 (PDT) Received: by qcac10 with SMTP id c10so2330825qca.31 for ; Thu, 20 Sep 2012 12:39:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=zhC32OMPu2msflNo6J7Tz/zt2zZykqetlK33czgRmIc=; b=dyfhYmFnVS3xCnh6dZIrLzakzHDd4tTTC7AQj1fibOtCybK3JYneBvZeMeunzLiVAR 4e1C21v+jt/U4YDd1C01trVA8HW971sK8o/CSNroMd9tPGEnaFb97ty5nWXqW59BZk4V 5DeHu1KNbXXzspgro8iY2v7O1tCQyFUYyTvD7EVafwgEQhRtPfg5lpIv2TpFuAd8YShu 3kkAmdlqx/UCHBv1LRZFmmf05jse69enclNnqCvAKVyrsBvKgHrIsgVdedZ7Dk9zqN2V HnJQclfZ3v2ylrO7pMj2j0WBySI+idgbwK3ndhgraG3TpRWRbG98VCJzHvUHzua0aZSr 2g+Q== Received: by 10.229.136.202 with SMTP id s10mr1845250qct.36.1348169975964; Thu, 20 Sep 2012 12:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.108.233 with HTTP; Thu, 20 Sep 2012 12:39:15 -0700 (PDT) In-Reply-To: References: From: Andrew Badera Date: Thu, 20 Sep 2012 14:39:15 -0500 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=0023544718dc83a42c04ca27484d X-Gm-Message-State: ALoCoQmpuNCV+6bOkmvFLJM3LMHemyCIbyrZiGmqD9gx3wMU4Y/moMWrYgeGmEtOlpvVaIJQ64ox Subject: Re: [scim] Proprietary/custom properties 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, 20 Sep 2012 19:39:38 -0000 --0023544718dc83a42c04ca27484d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Emmanuel. With JSON, as long as JSON remains schema-less, with most JSON serialization frameworks being fairly loose and lax, that's probably pretty pain-free. What about those consuming or serving XML however? Or what happens if JSON Schema is adopted? Won't extending the core schema open up the possibility, create the likelihood even, of breakage due to validation issues? Or issues with anyone who's a very strict consumer? --ab On Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux wrote= : > Our own feedback :**** > > We=E2=80=99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.***= * > > For both (=3D 100%), we=E2=80=99re extending the core user schema because= we have to > handle non standard defined attributes.**** > > ** ** > > --**** > > Cordialement / Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > ** ** > > *De :* Andrew Badera [mailto:andrew@badera.us] > *Envoy=C3=A9 :* jeudi 20 septembre 2012 20:00 > *=C3=80 :* scim@ietf.org > *Objet :* [scim] Proprietary/custom properties**** > > ** ** > > Hello all-**** > > ** ** > > If an organization is looking at early adoption of SCIM and has a number > of additional properties associated with users and groups that aren't par= t > of core schema or existing/proposed extensions, is there a preferred or > recommended way of handling those values? My thoughts to date are:**** > > ** ** > > 1. Treat it like an unofficial extension, (but then wonder about returnin= g > supporting schema and configs, though we may not support that at this poi= nt > anyhow)**** > > 2. Bolt-on a users and groups attribute system, which can easily get ugly= , > bloated, onerous and non-intuitive, fast. (Defining and supporting > attributes and their metadata, supporting retrieval and modification on a > per-attribute basis, etc.)**** > > 3. Something I haven't considered, or missed being discussed on-list > previously?**** > > ** ** > > These are not (strictly) LDAP values, though many are currently stored in > otherwise-unused, sometimes repurposed LDAP fields. These run the gamut > from users being "enabled" or "disabled" to user's roles (beyond usertype= ) > to user's customer details, etc.**** > > ** ** > > Thanks in advance for any insights- > =E2=88=9E Andy Badera > =E2=88=9E Technical Evangelist, MPS Partners, Chicago**** > > =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private > =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera > > **** > --0023544718dc83a42c04ca27484d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Emmanuel.

With JSON, as long as JSON remains sche= ma-less, with most JSON serialization frameworks being fairly loose and lax= , that's probably pretty pain-free. What about those consuming or servi= ng XML however? Or what happens if JSON Schema is adopted? Won't extend= ing the core schema open up the possibility, create the likelihood even, of= breakage due to validation issues? Or issues with anyone who's a very = strict consumer?

--ab


On= Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

Our own fe= edback=C2=A0:

We=E2=80= =99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.

For both (= =3D 100%), we=E2=80=99re extending the core user schema because we have to = handle non standard defined attributes.

=C2= =A0

--

Cordialement / Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=C2=A0

De=C2=A0: Andr= ew Badera [mailto:and= rew@badera.us]
Envoy=C3=A9=C2=A0: jeudi 20 septembre 2012 20:00
=C3=80=C2=A0: sci= m@ietf.org
Objet=C2=A0: [scim] Proprietary/custom properties

=C2=A0

Hello all-

=C2=A0

If an organization is looking at early adoption of S= CIM and has a number of additional properties associated with users and gro= ups that aren't part of core schema or existing/proposed extensions, is= there a preferred or recommended way of handling those values? My thoughts to date are:

=C2=A0

1. Treat it like an unofficial extension, (but then = wonder about returning supporting schema and configs, though we may not sup= port that at this point anyhow)

2. Bolt-on a users and groups attribute system, whic= h can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining = and supporting attributes and their metadata, supporting retrieval and modi= fication on a per-attribute basis, etc.)

3. Something I haven't considered, or missed bei= ng discussed on-list previously?

=C2=A0

These are not (strictly) LDAP values, though many ar= e currently stored in otherwise-unused, sometimes repurposed LDAP fields. T= hese run the gamut from users being "enabled" or "disabled&q= uot; to user's roles (beyond usertype) to user's customer details, etc.

=C2=A0

Thanks in advance for any insights-
=E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chicago

=E2=88=9E This email = is: [ ] bloggable [x] ask first [ ] private
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera


--0023544718dc83a42c04ca27484d-- From olds@rbcon.com Thu Sep 20 17:59:31 2012 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 F0BD821E8047 for ; Thu, 20 Sep 2012 17:59:31 -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.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktgewocOlb+8 for ; Thu, 20 Sep 2012 17:59:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39D7721F8602 for ; Thu, 20 Sep 2012 17:59:31 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3953600pbb.31 for ; Thu, 20 Sep 2012 17:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=9/bf0f/dW3irS3kGv0aNHpDtbGW0ldOw4YjBWcy1FXQ=; b=h0hzn1YnPIgEoh6ADqm9Ns/gDD7F2U2IW5Md2NG3GrSth4K56uAm4uSGlmRZ+mPHTI M4b1+NJnNnfDkN1B2Eom2YJiIe+cvxbGAin7srW1j9o/cvCNE1o9Yuiy33sko6DBoDrc CIekuskBiTrNqOPtD6P94H3r+ooV+u0aYgNhdgoJqiVqgAPElbVkPo0VG8c7xhxdfIID MGWRlKrEv6/uy+nKRGgt6eWGhcBV1dCPM5FnXxwMRuSTmd2yd98bTwpvS/TFO3OPVxby mKhmtEOw4GctYjoS1EkOlz3RDlMvZit0u7AakTJ99YlMWbON9zk3vvTMptolpQyUDNBl 4TNg== Received: by 10.66.72.197 with SMTP id f5mr9333659pav.20.1348189170704; Thu, 20 Sep 2012 17:59:30 -0700 (PDT) Received: from [10.40.32.89] ([173.243.48.220]) by mx.google.com with ESMTPS id iq3sm4262777pbc.5.2012.09.20.17.59.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 17:59:29 -0700 (PDT) Message-ID: <505BBBEF.1020309@rbcon.com> Date: Thu, 20 Sep 2012 17:59:27 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Kelly Grizzle References: <504FEA8B.5050505@rbcon.com> <5053D747.4050004@rbcon.com> <56C3C758F9D6534CA3778EAA1E0C3437330EDAF4@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330EDAF4@BY2PRD0410MB354.namprd04.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn3uSkXRljZh+/1Ea8mjdNJnaHtLQaBNpFABmDJoioJb7A3y8spHckTobX4R88v4qwKykGc Cc: Samuel Erdtman , "scim@ietf.org" Subject: Re: [scim] evaluating filters: true, false, and undefined 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, 21 Sep 2012 00:59:32 -0000 Kelly, thanks for the reply. I'm more interested in what is compatible with other implementations than a particular outcome, and your position is certainly implementable. Just in case there are others that might agree with my reasoning, I will reply inline below, but I'm more interested in determining if the wg feels this issue should be clarified. replies inline: On 09/17/2012 09:53 AM, Kelly Grizzle wrote: >> "Filters that contain references to attributes unknown to the server do not >> cause an error, but are evaluated such that those attributes are not present >> on each resource." > I would not support this. IMO filters that reference attributes that are unknown by the server should return an error, otherwise the client may get unexpected results. I think it depends on the client and how much the scim schema is extended in practice. If clients are tightly coupled to the server then they can expect specific attributes to be known and anything else is an error. If the scim server supports extensions (as our implementation does, and as do others represented on this list), then IMO it's easier with fewer unexpected results if they can make queries that work in a reasonable fashion to different servers. > > >> we'd like to be able to write queries so that they work whether a particular >> scim server supports that extension or not. > The client should be able to use the /Schemas resource to determine whether the server supports the extension. Of course, but that means that an application needs to query the server first and will need to support multiple queries based on what extensions are supported. As I said above, it depends on the client application and how often there are variations in the server schema, but in my experience it's crucial that schema extensions can be added without requiring clients and servers to be in sync. > > > In general, I am in favor of making things simpler for the client, but this seems like a case where it would be beneficial for the server to be more strict. Complete agreement on keeping things simpler for the client, I just think it's simpler to make logical queries rather than querying for schema support. I prefer: does joe have a hat or a foobar? rather than: if (server supports the foobar extension) then (does joe have a hat or a foobar?) else (does joe have a hat?) --Dale > > --Kelly > > > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds > Sent: Friday, September 14, 2012 8:18 PM > To: Samuel Erdtman > Cc: scim@ietf.org > Subject: Re: [scim] evaluating filters: true, false, and undefined > > I would expect that if "PR foobar" on a resource evaluates to false it means "this resource has no value for attribute foobar", which is not quite the same as "this server does not know what foobar means". > Nevertheless, if the server does not know what an attribute means no resource will have a value for that attribute, so perhaps it's close enough. I can't think of an example that's not overly contrived where the difference would matter. > > One of the reasons I brought this issue up is because there are places we'd like to add our own scim extensions, and we'd like to be able to write queries so that they work whether a particular scim server supports that extension or not. I also need to know how to handle undefined attributes in our own server. > > Would the working group support this additional sentence to the first paragraph of section 3.2.2.1? > > "Filters that contain references to attributes unknown to the server do not cause an error, but are evaluated such that those attributes are not present on each resource." > > --Dale > > On 09/11/2012 11:21 PM, Samuel Erdtman wrote: >> In the scimproxy we will probably do it by interpreting undefined as >> false i.e. the statements would be evaluated as you describe it. >> However currently we only support one filter operation i.e. no 'and' >> 'or' stuff yet. Have actually not tested much filtering during the >> interops. >> >> If you would want to require foobar to be precent before evaluating >> rest of the expression you could state it as folows: >> ?filter=PR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means >> present i.e. not undefined) >> >> Regards >> //Samuel >> >> On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >>> section 3.2.2.1 of the API doc describes filtering expressions and bindings. >>> It is very clear about what should happen if an operator is not >>> defined (the example is 'regex'), but I do not see anything which >>> explicitly states what happens if an attribute in the expression is >>> not defined. The closest statement is in the first paragraph: "The >>> expression language that is used in the filter parameter supports >>> references to attributes and literals." I suppose that could mean a >>> reference to an unknown attribute is not supported, but it doesn't >>> really say that, and it doesn't say undefined attributes are an error. >>> >>> In filtering code for similar systems I've seen implementations that >>> did not require attributes to be defined. This can be quite natural >>> but does make the implementation more interesting. Consider this filter of rooms: >>> >>> True if contains someone with hat size > 7 or wearing a read shirt. >>> >>> There may not be anyone wearing a hat in any room, but it would still >>> find rooms with red shirts. IOW, it only takes one true component of an 'or' >>> expression to make it true, even if one of the components is undefined. >>> >>> "True if someone with foobar > 7 or wearing a read shirt" works just >>> as well. >>> >>> This is not a big issue for us, we're just checking out >>> implementation options. What do most implementations currently do? >>> >>> --Dale >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 g.c.prasad@gmail.com Thu Sep 20 19:01:35 2012 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 E5EA621E804D for ; Thu, 20 Sep 2012 19:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REkB-0BhluPn for ; Thu, 20 Sep 2012 19:01:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D46021E8047 for ; Thu, 20 Sep 2012 19:01:32 -0700 (PDT) Received: by bkty12 with SMTP id y12so1416778bkt.31 for ; Thu, 20 Sep 2012 19:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=DFd1tG55c1AFD/b65phAhUHiRc95qzqV//jvaNuKoOI=; b=LIFSvpCAfefgSOaKa1FY/sLKB7nL1aKxES6nD1RVH7Trw1qFv7RZfDBDunfvN16KjU KyD+iV4zmwPt9hnxaJb2+9TdjAR2O/rfGKEd5WLJvs1UsNmFtuAcippc36p8B4xsbQb+ 9K5s1Ldv9mwqbCba9Rl4Z6TRTHPSZHc5Qx4ooSqE45uH2YkTarHEs/N30pt3nsKJIt40 rPtXoauu+jkgj32g/61zjT1OnCveWbpozbgn5YuArkr3gbt8r1r0n7H4uAnvHV0KKeh8 7XDfnqQfw+rwOWarY2qhee5B5GqzVLFTLNnUdcLfcmxtboZCbiyz5Vq8d/jOaZjAU05+ lo3A== Received: by 10.204.128.214 with SMTP id l22mr1498804bks.86.1348192891989; Thu, 20 Sep 2012 19:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Thu, 20 Sep 2012 19:01:11 -0700 (PDT) From: Ganesh and Sashi Prasad Date: Fri, 21 Sep 2012 12:01:11 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=0015173ff32a6a6dbf04ca2c9e4a Subject: Re: [scim] Proprietary/custom properties 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, 21 Sep 2012 02:01:36 -0000 --0015173ff32a6a6dbf04ca2c9e4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've found that a simple naming convention (e.g., that all metadata element names begin with an underscore) makes extensions much easier. This only means the inclusion of a metadata element called "_value" to represent the value of an attribute, and this then makes the treatment of metadata uniform. { "abc" : 123 } is semantically equivalent to { "abc" : { "_value" : 123 } } This is the same element expressed in terms of metadata. Now, we can extend this to add more metadata elements (custom properties), woven into the resource structure itself, without breaking the original. { "abc" : { "_value" : 123, "_created" : "2011-10-25T13:45", "_updated" : "2012-03-18T08:05" } } If a system doesn't understand a custom metadata tag, it just ignores it. Nesting is also possible. { "abc" : { "def" : 456, "ghi" : 789 } } in expanded notation could be { "abc" : { "_value" : { "def" : { "_value" : 456, "_replica" : true }, "ghi" : 789 }, "_created" : "2011-10-25T13:45", "_updated" : "2012-03-18T08:05" } } The "_created" and "_updated" metadata tags refer to resource element "abc" (same level as "_value" of "abc"). The "_replica" tag refers to resource element "def" (same level as "_value" of "def"). Note that not all elements need be expanded (e.g., "ghi"). Regards, Ganesh On 21 September 2012 10:59, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: Proprietary/custom properties (Emmanuel Dreux) > 2. Re: Proprietary/custom properties (Andrew Badera) > 3. Re: evaluating filters: true, false, and undefined (Dale Olds) > > > ---------- Forwarded message ---------- > From: Emmanuel Dreux > To: Andrew Badera , "scim@ietf.org" > Cc: > Date: Thu, 20 Sep 2012 19:18:55 +0000 > Subject: Re: [scim] Proprietary/custom properties > > Our own feedback :**** > > We=E2=80=99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.***= * > > For both (=3D 100%), we=E2=80=99re extending the core user schema because= we have to > handle non standard defined attributes.**** > > ** ** > > --**** > > Cordialement / Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > ** ** > > *De :* Andrew Badera [mailto:andrew@badera.us] > *Envoy=C3=A9 :* jeudi 20 septembre 2012 20:00 > *=C3=80 :* scim@ietf.org > *Objet :* [scim] Proprietary/custom properties**** > > ** ** > > Hello all-**** > > ** ** > > If an organization is looking at early adoption of SCIM and has a number > of additional properties associated with users and groups that aren't par= t > of core schema or existing/proposed extensions, is there a preferred or > recommended way of handling those values? My thoughts to date are:**** > > ** ** > > 1. Treat it like an unofficial extension, (but then wonder about returnin= g > supporting schema and configs, though we may not support that at this poi= nt > anyhow)**** > > 2. Bolt-on a users and groups attribute system, which can easily get ugly= , > bloated, onerous and non-intuitive, fast. (Defining and supporting > attributes and their metadata, supporting retrieval and modification on a > per-attribute basis, etc.)**** > > 3. Something I haven't considered, or missed being discussed on-list > previously?**** > > ** ** > > These are not (strictly) LDAP values, though many are currently stored in > otherwise-unused, sometimes repurposed LDAP fields. These run the gamut > from users being "enabled" or "disabled" to user's roles (beyond usertype= ) > to user's customer details, etc.**** > > ** ** > > Thanks in advance for any insights- > =E2=88=9E Andy Badera > =E2=88=9E Technical Evangelist, MPS Partners, Chicago**** > > =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private > =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera > > **** > > > ---------- Forwarded message ---------- > From: Andrew Badera > To: "scim@ietf.org" > Cc: > Date: Thu, 20 Sep 2012 14:39:15 -0500 > Subject: Re: [scim] Proprietary/custom properties > Thanks Emmanuel. > > With JSON, as long as JSON remains schema-less, with most JSON > serialization frameworks being fairly loose and lax, that's probably pret= ty > pain-free. What about those consuming or serving XML however? Or what > happens if JSON Schema is adopted? Won't extending the core schema open u= p > the possibility, create the likelihood even, of breakage due to validatio= n > issues? Or issues with anyone who's a very strict consumer? > > --ab > > > On Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux wro= te: > >> Our own feedback :**** >> >> We=E2=80=99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.**= ** >> >> For both (=3D 100%), we=E2=80=99re extending the core user schema becaus= e we have >> to handle non standard defined attributes.**** >> >> ** ** >> >> --**** >> >> Cordialement / Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> ** ** >> >> *De :* Andrew Badera [mailto:andrew@badera.us] >> *Envoy=C3=A9 :* jeudi 20 septembre 2012 20:00 >> *=C3=80 :* scim@ietf.org >> *Objet :* [scim] Proprietary/custom properties**** >> >> ** ** >> >> Hello all-**** >> >> ** ** >> >> If an organization is looking at early adoption of SCIM and has a number >> of additional properties associated with users and groups that aren't pa= rt >> of core schema or existing/proposed extensions, is there a preferred or >> recommended way of handling those values? My thoughts to date are:**** >> >> ** ** >> >> 1. Treat it like an unofficial extension, (but then wonder about >> returning supporting schema and configs, though we may not support that = at >> this point anyhow)**** >> >> 2. Bolt-on a users and groups attribute system, which can easily get >> ugly, bloated, onerous and non-intuitive, fast. (Defining and supporting >> attributes and their metadata, supporting retrieval and modification on = a >> per-attribute basis, etc.)**** >> >> 3. Something I haven't considered, or missed being discussed on-list >> previously?**** >> >> ** ** >> >> These are not (strictly) LDAP values, though many are currently stored i= n >> otherwise-unused, sometimes repurposed LDAP fields. These run the gamut >> from users being "enabled" or "disabled" to user's roles (beyond usertyp= e) >> to user's customer details, etc.**** >> >> ** ** >> >> Thanks in advance for any insights- >> =E2=88=9E Andy Badera >> =E2=88=9E Technical Evangelist, MPS Partners, Chicago**** >> >> =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private >> =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera >> >> **** >> > > > > ---------- Forwarded message ---------- > From: Dale Olds > To: Kelly Grizzle > Cc: Samuel Erdtman , "scim@ietf.org" > Date: Thu, 20 Sep 2012 17:59:27 -0700 > Subject: Re: [scim] evaluating filters: true, false, and undefined > Kelly, thanks for the reply. I'm more interested in what is compatible > with other implementations than a particular outcome, and your position i= s > certainly implementable. Just in case there are others that might agree > with my reasoning, I will reply inline below, but I'm more interested in > determining if the wg feels this issue should be clarified. > > replies inline: > > On 09/17/2012 09:53 AM, Kelly Grizzle wrote: > >> "Filters that contain references to attributes unknown to the server do >>> not >>> cause an error, but are evaluated such that those attributes are not >>> present >>> on each resource." >>> >> I would not support this. IMO filters that reference attributes that ar= e >> unknown by the server should return an error, otherwise the client may g= et >> unexpected results. >> > > I think it depends on the client and how much the scim schema is extended > in practice. If clients are tightly coupled to the server then they can > expect specific attributes to be known and anything else is an error. If > the scim server supports extensions (as our implementation does, and as d= o > others represented on this list), then IMO it's easier with fewer > unexpected results if they can make queries that work in a reasonable > fashion to different servers. > > >> >> we'd like to be able to write queries so that they work whether a >>> particular >>> scim server supports that extension or not. >>> >> The client should be able to use the /Schemas resource to determine >> whether the server supports the extension. >> > > Of course, but that means that an application needs to query the server > first and will need to support multiple queries based on what extensions > are supported. As I said above, it depends on the client application and > how often there are variations in the server schema, but in my experience > it's crucial that schema extensions can be added without requiring client= s > and servers to be in sync. > > >> >> In general, I am in favor of making things simpler for the client, but >> this seems like a case where it would be beneficial for the server to be >> more strict. >> > > Complete agreement on keeping things simpler for the client, I just think > it's simpler to make logical queries rather than querying for schema > support. > > I prefer: does joe have a hat or a foobar? > > rather than: if (server supports the foobar extension) then (does joe hav= e > a hat or a foobar?) else (does joe have a hat?) > > --Dale > > >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >> Dale Olds >> Sent: Friday, September 14, 2012 8:18 PM >> To: Samuel Erdtman >> Cc: scim@ietf.org >> Subject: Re: [scim] evaluating filters: true, false, and undefined >> >> I would expect that if "PR foobar" on a resource evaluates to false it >> means "this resource has no value for attribute foobar", which is not qu= ite >> the same as "this server does not know what foobar means". >> Nevertheless, if the server does not know what an attribute means no >> resource will have a value for that attribute, so perhaps it's close >> enough. I can't think of an example that's not overly contrived where th= e >> difference would matter. >> >> One of the reasons I brought this issue up is because there are places >> we'd like to add our own scim extensions, and we'd like to be able to wr= ite >> queries so that they work whether a particular scim server supports that >> extension or not. I also need to know how to handle undefined attributes= in >> our own server. >> >> Would the working group support this additional sentence to the first >> paragraph of section 3.2.2.1? >> >> "Filters that contain references to attributes unknown to the server do >> not cause an error, but are evaluated such that those attributes are not >> present on each resource." >> >> --Dale >> >> On 09/11/2012 11:21 PM, Samuel Erdtman wrote: >> >>> In the scimproxy we will probably do it by interpreting undefined as >>> false i.e. the statements would be evaluated as you describe it. >>> However currently we only support one filter operation i.e. no 'and' >>> 'or' stuff yet. Have actually not tested much filtering during the >>> interops. >>> >>> If you would want to require foobar to be precent before evaluating >>> rest of the expression you could state it as folows: >>> ?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means >>> present i.e. not undefined) >>> >>> Regards >>> //Samuel >>> >>> On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >>> >>>> section 3.2.2.1 of the API doc describes filtering expressions and >>>> bindings. >>>> It is very clear about what should happen if an operator is not >>>> defined (the example is 'regex'), but I do not see anything which >>>> explicitly states what happens if an attribute in the expression is >>>> not defined. The closest statement is in the first paragraph: "The >>>> expression language that is used in the filter parameter supports >>>> references to attributes and literals." I suppose that could mean a >>>> reference to an unknown attribute is not supported, but it doesn't >>>> really say that, and it doesn't say undefined attributes are an error. >>>> >>>> In filtering code for similar systems I've seen implementations that >>>> did not require attributes to be defined. This can be quite natural >>>> but does make the implementation more interesting. Consider this filte= r >>>> of rooms: >>>> >>>> True if contains someone with hat size > 7 or wearing a read shirt. >>>> >>>> There may not be anyone wearing a hat in any room, but it would still >>>> find rooms with red shirts. IOW, it only takes one true component of a= n >>>> 'or' >>>> expression to make it true, even if one of the components is undefined= . >>>> >>>> "True if someone with foobar > 7 or wearing a read shirt" works just >>>> as well. >>>> >>>> This is not a big issue for us, we're just checking out >>>> implementation options. What do most implementations currently do? >>>> >>>> --Dale >>>> >>>> >>>> >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/scim >>>> >>>> ______________________________**_________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/**listinfo/scim >> >> >> > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015173ff32a6a6dbf04ca2c9e4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've found that a simple naming convention (e.g., that all metadata ele= ment names begin with an underscore) makes extensions much easier. This onl= y means the inclusion of a metadata element called "_value" to re= present the value of an attribute, and this then makes the treatment of met= adata uniform.

{ =C2=A0"abc" : 123 }

is = semantically equivalent to

{
=C2=A0 =C2= =A0 "abc" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value&= quot; : 123
=C2=A0 =C2=A0 }
}

This is the same element expressed in terms= of metadata.

Now, we can extend this to add more = metadata elements (custom properties), woven into the resource structure it= self, without breaking the original.

{
=C2=A0 =C2=A0 "abc" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" : 123,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 "_created" : "2011-10-25T13:45"= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_updated" : "2012-= 03-18T08:05"
=C2=A0 =C2=A0 }
}

If a system doesn= 't understand a custom metadata tag, it just ignores it.

=
Nesting is also possible.

{
= =C2=A0 =C2=A0 "abc" : { "def" : 456, "ghi" : = 789 }
}

in expanded notation could be
{
=C2=A0 =C2=A0 "abc" : {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" : {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "def" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" = : 456,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;_replica" : true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ghi" = : 789
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 "_created" : "2011-10-25T13:45",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_updated" : "2012-03-18T08= :05"
=C2=A0 =C2=A0 }
}

<= div>The "_created" and "_updated" metadata tags refer t= o resource element "abc" (same level as "_value" of &qu= ot;abc").
The "_replica" tag refers to resource element "def"= ; (same level as "_value" of "def").
Note tha= t not all elements need be expanded (e.g., "ghi").

Regards,
Ganesh


On 21 September 2012 10:59, <scim-request@ietf.= org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =C2=A0To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/scim

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =C2=A0You can set this option globally for all the list digests you receive at this point.



Send scim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim-own= er@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of scim digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Proprietary/custom properties (Emmanuel Dreux)
=C2=A0 =C2=A02. Re: Proprietary/custom properties (Andrew Badera)
=C2=A0 =C2=A03. Re: evaluating filters: true, false, and undefined (Dale Ol= ds)


---------- Forwarded message ----------
From:=C2=A0Emmanuel Dreu= x <edreux@cloudiway.com><= br>To:=C2=A0Andrew Badera <andrew@ba= dera.us>, "scim@ietf.org&q= uot; <scim@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 20 Sep 2012 19:18:55 +0000
Subject:=C2=A0Re= : [scim] Proprietary/custom properties

Our own fe= edback=C2=A0:

We=E2=80= =99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.

For both (= =3D 100%), we=E2=80=99re extending the core user schema because we have to = handle non standard defined attributes.

=C2= =A0

--

Cordialement / Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=C2=A0

De=C2=A0: Andr= ew Badera [mailto:and= rew@badera.us]
Envoy=C3=A9=C2=A0: jeudi 20 septembre 2012 20:00
=C3=80=C2=A0: sci= m@ietf.org
Objet=C2=A0: [scim] Proprietary/custom properties

=C2=A0

Hello all-

=C2=A0

If an organization is looking at early adoption of S= CIM and has a number of additional properties associated with users and gro= ups that aren't part of core schema or existing/proposed extensions, is= there a preferred or recommended way of handling those values? My thoughts to date are:

=C2=A0

1. Treat it like an unofficial extension, (but then = wonder about returning supporting schema and configs, though we may not sup= port that at this point anyhow)

2. Bolt-on a users and groups attribute system, whic= h can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining = and supporting attributes and their metadata, supporting retrieval and modi= fication on a per-attribute basis, etc.)

3. Something I haven't considered, or missed bei= ng discussed on-list previously?

=C2=A0

These are not (strictly) LDAP values, though many ar= e currently stored in otherwise-unused, sometimes repurposed LDAP fields. T= hese run the gamut from users being "enabled" or "disabled&q= uot; to user's roles (beyond usertype) to user's customer details, etc.

=C2=A0

Thanks in advance for any insights-
=E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chicago

=E2=88=9E This email = is: [ ] bloggable [x] ask first [ ] private
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera



---------- Forwarded message ----------
From:=C2=A0Andrew Badera= <andrew@badera.us>
To:=C2= =A0"scim@ietf.org" <scim@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 20 Sep 2012 14:39:15 -0500
Subject:=C2=A0Re= : [scim] Proprietary/custom properties
Thanks Emmanuel.

With JSON, as long as JSON remains schema-less, with most JSON serializa= tion frameworks being fairly loose and lax, that's probably pretty pain= -free. What about those consuming or serving XML however? Or what happens i= f JSON Schema is adopted? Won't extending the core schema open up the p= ossibility, create the likelihood even, of breakage due to validation issue= s? Or issues with anyone who's a very strict consumer?

--ab


On= Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

Our own fe= edback=C2=A0:

We=E2=80= =99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.

For both (= =3D 100%), we=E2=80=99re extending the core user schema because we have to = handle non standard defined attributes.

=C2= =A0

--

Cordialement / Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=C2=A0

De=C2=A0: Andr= ew Badera [mailto:and= rew@badera.us]
Envoy=C3=A9=C2=A0: jeudi 20 septembre 2012 20:00
=C3=80=C2=A0: sci= m@ietf.org
Objet=C2=A0: [scim] Proprietary/custom properties

=C2=A0

Hello all-

=C2=A0

If an organization is looking at early adoption of S= CIM and has a number of additional properties associated with users and gro= ups that aren't part of core schema or existing/proposed extensions, is= there a preferred or recommended way of handling those values? My thoughts to date are:

=C2=A0

1. Treat it like an unofficial extension, (but then = wonder about returning supporting schema and configs, though we may not sup= port that at this point anyhow)

2. Bolt-on a users and groups attribute system, whic= h can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining = and supporting attributes and their metadata, supporting retrieval and modi= fication on a per-attribute basis, etc.)

3. Something I haven't considered, or missed bei= ng discussed on-list previously?

=C2=A0

These are not (strictly) LDAP values, though many ar= e currently stored in otherwise-unused, sometimes repurposed LDAP fields. T= hese run the gamut from users being "enabled" or "disabled&q= uot; to user's roles (beyond usertype) to user's customer details, etc.

=C2=A0

Thanks in advance for any insights-
=E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chicago

=E2=88=9E This email = is: [ ] bloggable [x] ask first [ ] private
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera




---------- Forwarded message ----------
From:=C2=A0Dale Olds <= ;olds@rbcon.com>
To:=C2=A0Kelly= Grizzle <kelly.grizzle@s= ailpoint.com>
Cc:=C2=A0Samuel Erdtman <samuel@erd= tman.se>, "scim@ietf.org&q= uot; <scim@ietf.org>
Date:=C2= =A0Thu, 20 Sep 2012 17:59:27 -0700
Subject:=C2=A0Re: [scim] evaluating filters: true, false, and undefined
= Kelly, thanks for the reply. I'm more interested in what is compatible = with other implementations than a particular outcome, and your position is = certainly implementable. Just in case there are others that might agree wit= h my reasoning, I will reply inline below, but I'm more interested in d= etermining if the wg feels this issue should be clarified.

replies inline:

On 09/17/2012 09:53 AM, Kelly Grizzle wrote:
"Filters that contain references to attributes unknown to the server d= o not
cause an error, but are evaluated such that those attributes are not presen= t
on each resource."
I would not support this. =C2=A0IMO filters that reference attributes that = are unknown by the server should return an error, otherwise the client may = get unexpected results.

I think it depends on the client and how much the scim schema is extended i= n practice. If clients are tightly coupled to the server then they can expe= ct specific attributes to be known and anything else is an error. If the sc= im server supports extensions (as our implementation does, and as do others= represented on this list), then IMO it's easier with fewer unexpected = results if they can make queries that work in a reasonable fashion to diffe= rent servers.



we'd like to be able to write queries so that they work whether a parti= cular
scim server supports that extension or not.
The client should be able to use the /Schemas resource to determine whether= the server supports the extension.

Of course, but that means that an application needs to query the server fir= st and will need to support multiple queries based on what extensions are s= upported. As I said above, it depends on the client application and how oft= en there are variations in the server schema, but in my experience it's= crucial that schema extensions can be added without requiring clients and = servers to be in sync.



In general, I am in favor of making things simpler for the client, but this= seems like a case where it would be beneficial for the server to be more s= trict.

Complete agreement on keeping things simpler for the client, I just think i= t's simpler to make logical queries rather than querying for schema sup= port.

I prefer: does joe have a hat or a foobar?

rather than: if (server supports the foobar extension) then (does joe have = a hat or a foobar?) else (does joe have a hat?)

--Dale


--Kelly


-----Original Message-----
From: scim-bounc= es@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Friday, September 14, 2012 8:18 PM
To: Samuel Erdtman
Cc: scim@ietf.org Subject: Re: [scim] evaluating filters: true, false, and undefined

I would expect that if "PR foobar" on a resource evaluates to fal= se it means "this resource has no value for attribute foobar", wh= ich is not quite the same as "this server does not know what foobar me= ans".
Nevertheless, if the server does not know what an attribute means no resour= ce will have a value for that attribute, so perhaps it's close enough. = I can't think of an example that's not overly contrived where the d= ifference would matter.

One of the reasons I brought this issue up is because there are places we&#= 39;d like to add our own scim extensions, and we'd like to be able to w= rite queries so that they work whether a particular scim server supports th= at extension or not. I also need to know how to handle undefined attributes= in our own server.

Would the working group support this additional sentence to the first parag= raph of section 3.2.2.1?

"Filters that contain references to attributes unknown to the server d= o not cause an error, but are evaluated such that those attributes are not = present on each resource."

--Dale

On 09/11/2012 11:21 PM, Samuel Erdtman wrote:
In the scimproxy we will probably do it by interpreting undefined as
false i.e. the statements would be evaluated as you describe it.
However currently we only support one filter operation i.e. no 'and'= ;
'or' stuff yet. Have actually not tested much filtering during the<= br> interops.

If you would want to require foobar to be precent before evaluating
rest of the expression you could state it as folows:
?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means
present i.e. not undefined)

Regards
//Samuel

On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds <olds@rbcon.com> wrote:
section 3.2.2.1 of the API doc describes filtering expressions and bindings= .
It is very clear about what should happen if an operator is not
defined (the example is 'regex'), but I do not see anything which explicitly states what happens if an attribute in the expression is
not defined. The closest statement is in the first paragraph: "The
expression language that is used in the filter parameter supports
references to attributes and literals." I suppose that could mean a reference to an unknown attribute is not supported, but it doesn't
really say that, and it doesn't say undefined attributes are an error.<= br>
In filtering code for similar systems I've seen implementations that did not require attributes to be defined. This can be quite natural
but does make the implementation more interesting. Consider this filter of = rooms:

True if contains someone with hat size > 7 or wearing a read shirt.

There may not be anyone wearing a hat in any room, but it would still
find rooms with red shirts. IOW, it only takes one true component of an = 9;or'
expression to make it true, even if one of the components is undefined.

"True if someone with foobar > 7 or wearing a read shirt" work= s just
as well.

This is not a big issue for us, we're just checking out
implementation options. What do most implementations currently do?

--Dale






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

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





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


--0015173ff32a6a6dbf04ca2c9e4a-- From Bert.Greevenbosch@huawei.com Thu Sep 20 23:14:23 2012 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 4B2E121F84F3; Thu, 20 Sep 2012 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcXrkzOGKHuB; Thu, 20 Sep 2012 23:14:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9466621F8639; Thu, 20 Sep 2012 23:14:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW51145; Fri, 21 Sep 2012 06:14:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:13:41 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:14:17 +0100 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 14:14:07 +0800 From: Bert Greevenbosch To: "dany.cauchie@orange.com" , "vcarddav@ietf.org" , "scim@ietf.org" Thread-Topic: Upload of SCIM/vCard mapping draft Thread-Index: AQHNlX3P+qo+TKEJ9EuMcAMkwpiVzJeUSfqA Date: Fri, 21 Sep 2012 06:14:07 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB6290D5011@szxeml509-mbs> References: <29195_1347959585_50583B21_29195_10300_1_ef6d99e0-25ee-4eb9-8e6e-267b3be182d9@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <29195_1347959585_50583B21_29195_10300_1_ef6d99e0-25ee-4eb9-8e6e-267b3be182d9@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: MIENVILLE Thibaud OLNC/NAD , Likepeng Subject: Re: [scim] Upload of SCIM/vCard mapping draft 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, 21 Sep 2012 06:14:23 -0000 Hello Dany, Thank you for your comments. I have added the references to RFC 6473, RFC 6= 474 and RFC 6715 to the draft, and updated the vCard -> SCIM table. I haven= 't found strong matches in SCIM for the new vCard properties, so I have not= yet defined mappings for them. Both typos have been fixed too. I will upload a new version of the draft in due time, but first wait a whil= e for possibly more comments. Thanks again and best regards, Bert -----Original Message----- From: dany.cauchie@orange.com [mailto:dany.cauchie@orange.com]=20 Sent: 18 September 2012 17:13 To: vcarddav@ietf.org; scim@ietf.org; Bert Greevenbosch Cc: Likepeng; MIENVILLE Thibaud OLNC/NAD Subject: Upload of SCIM/vCard mapping draft Hi all, Here are my comments : 1) To be complete, in its sections 4 and 9, this document will have to take= into account other RFCs like : - RFC 6473 - RFC 6474 - RFC 6715 2) I noted 2 typos in section 4 :=20 - ANIVERSARY instead of ANNIVERSARY=20 and=20 - CATHEGORIES instead of CATEGORIES=20 Regards Dany ---------------------------------------------------------------------- 1. Fwd: [scim] Upload of SCIM/vCard mapping draft (Peter Saint-Andre) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Sep 2012 19:15:29 -0600 From: Peter Saint-Andre To: vcarddav@ietf.org Subject: [VCARDDAV] Fwd: [scim] Upload of SCIM/vCard mapping draft Message-ID: <50528531.2070903@stpeter.im> Content-Type: text/plain; charset=3D"utf-8" Of interest. -------- Original Message -------- Subject: [scim] Upload of SCIM/vCard mapping draft Date: Fri, 14 Sep 2012 01:08:18 +0000 From: Bert Greevenbosch To: scim@ietf.org Hi all, Yesterday I uploaded a draft that provides mapping between SCIM and vCard. It is available under the following link: http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ The draft provides the mapping in two directions: from SCIM to vCard and from vCard to SCIM. Open issues include the conversion method between SCIM ids and vCard UIDs. When that is done, it should be easy to port the grouping function. I think the draft is also very useful for the discussion on the format to use for SCIM, and in which extent it will be related to vCard. I look forward to your comments and suggestions! Best regards, Bert -------------- next part -------------- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------------------------------ _______________________________________________ VCARDDAV mailing list VCARDDAV@ietf.org https://www.ietf.org/mailman/listinfo/vcarddav End of VCARDDAV Digest, Vol 61, Issue 23 **************************************** ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From mike.angstadt@gmail.com Fri Sep 21 06:17:09 2012 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 BF85B21F8807; Fri, 21 Sep 2012 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OShsqYdEmMM3; Fri, 21 Sep 2012 06:17:09 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 944FE21F87BA; Fri, 21 Sep 2012 06:17:05 -0700 (PDT) Received: by oagn5 with SMTP id n5so3059160oag.31 for ; Fri, 21 Sep 2012 06:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dj40g1O39eoDrNPCUOgXYgFWbEcb160AObwdqeOl4gY=; b=Z8MLCV/ITn3aDfrNIBwA09MxfIAqcU9aPQd8TSQAQlXA2baK8VabkReQ+OQ+YYk+SL eDnpv0DXbSMStwI/CD5MSl9kLdkG1P1jeeq+tXxFwhJUbU/triEusqIW4jeM91eWcWuq zMXF1F/0cQmv94Tge4qWGWnimaz3CsSP8VidcF2DlQUVzmbEWnMz2K20WtQhX8Rgd6Ov 8VgSQHf4J0HuakLOiXGgvcG+Sd/tArxo2l+OddUQ7aZoDMO3khFiE+/9xm0L3TmXeJDg 3I9aevH/b2nq0YS3KXV6mEQu3ETgu5NZ2GVDSV1eqacm6HOZx8z65OhZ9kSgfXtHdbrI Wo/w== MIME-Version: 1.0 Received: by 10.60.172.143 with SMTP id bc15mr3883106oec.73.1348233425229; Fri, 21 Sep 2012 06:17:05 -0700 (PDT) Received: by 10.60.136.228 with HTTP; Fri, 21 Sep 2012 06:17:05 -0700 (PDT) In-Reply-To: <46A1DF3F04371240B504290A071B4DB6290D5011@szxeml509-mbs> References: <29195_1347959585_50583B21_29195_10300_1_ef6d99e0-25ee-4eb9-8e6e-267b3be182d9@PEXCVZYH01.corporate.adroot.infra.ftgroup> <46A1DF3F04371240B504290A071B4DB6290D5011@szxeml509-mbs> Date: Fri, 21 Sep 2012 09:17:05 -0400 Message-ID: From: Michael Angstadt To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=bcaec54c527c62995704ca360e00 Cc: "scim@ietf.org" , "dany.cauchie@orange.com" , "vcarddav@ietf.org" , MIENVILLE Thibaud OLNC/NAD Subject: Re: [scim] [VCARDDAV] Upload of SCIM/vCard mapping draft 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, 21 Sep 2012 13:17:09 -0000 --bcaec54c527c62995704ca360e00 Content-Type: text/plain; charset=ISO-8859-1 Dany/Bert, Actually, ANNIVERSARY (with two Ns) is the correct spelling (see RFC 6350, p.31). Thanks, -Mike http://code.google.com/p/ez-vcard On Friday, September 21, 2012, Bert Greevenbosch wrote: > Hello Dany, > > Thank you for your comments. I have added the references to RFC 6473, RFC > 6474 and RFC 6715 to the draft, and updated the vCard -> SCIM table. I > haven't found strong matches in SCIM for the new vCard properties, so I > have not yet defined mappings for them. > > Both typos have been fixed too. > > I will upload a new version of the draft in due time, but first wait a > while for possibly more comments. > > Thanks again and best regards, > Bert > > > -----Original Message----- > From: dany.cauchie@orange.com [mailto:dany.cauchie@orange.com] > Sent: 18 September 2012 17:13 > To: vcarddav@ietf.org; scim@ietf.org; Bert Greevenbosch > Cc: Likepeng; MIENVILLE Thibaud OLNC/NAD > Subject: Upload of SCIM/vCard mapping draft > > Hi all, > > Here are my comments : > > 1) To be complete, in its sections 4 and 9, this document will have to > take into account other RFCs like : > > - RFC 6473 > - RFC 6474 > - RFC 6715 > > 2) I noted 2 typos in section 4 : > - ANIVERSARY instead of ANNIVERSARY > and > - CATHEGORIES instead of CATEGORIES > Regards > Dany > > > ---------------------------------------------------------------------- > 1. Fwd: [scim] Upload of SCIM/vCard mapping draft > (Peter Saint-Andre) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Sep 2012 19:15:29 -0600 > From: Peter Saint-Andre > To: vcarddav@ietf.org > Subject: [VCARDDAV] Fwd: [scim] Upload of SCIM/vCard mapping draft > Message-ID: <50528531.2070903@stpeter.im> > Content-Type: text/plain; charset="utf-8" > > Of interest. > > > -------- Original Message -------- > Subject: [scim] Upload of SCIM/vCard mapping draft > Date: Fri, 14 Sep 2012 01:08:18 +0000 > From: Bert Greevenbosch > To: scim@ietf.org > > > > Hi all, > > > > Yesterday I uploaded a draft that provides mapping between SCIM and > vCard. It is available under the following link: > > http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/ > > > > The draft provides the mapping in two directions: from SCIM to vCard and > from vCard to SCIM. > > > > Open issues include the conversion method between SCIM ids and vCard > UIDs. When that is done, it should be easy to port the grouping function. > > > > I think the draft is also very useful for the discussion on the format > to use for SCIM, and in which extent it will be related to vCard. > > > > I look forward to your comments and suggestions! > > > > Best regards, > > Bert > > > > -------------- next part -------------- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > ------------------------------ > > _______________________________________________ > VCARDDAV mailing list > VCARDDAV@ietf.org > https://www.ietf.org/mailman/listinfo/vcarddav > > > End of VCARDDAV Digest, Vol 61, Issue 23 > **************************************** > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler< --bcaec54c527c62995704ca360e00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dany/Bert,

Actually, ANNIVERSARY (with two Ns) is the co= rrect spelling (see RFC 6350, p.31).

Thanks,
=
-Mike
http://c= ode.google.com/p/ez-vcard

On Friday, September 21, 2012, Bert Greevenbosch wrote:
Hello Dany,

Thank you for your comments. I have added the references to RFC 6473, RFC 6= 474 and RFC 6715 to the draft, and updated the vCard -> SCIM table. I ha= ven't found strong matches in SCIM for the new vCard properties, so I h= ave not yet defined mappings for them.

Both typos have been fixed too.

I will upload a new version of the draft in due time, but first wait a whil= e for possibly more comments.

Thanks again and best regards,
Bert


-----Original Message-----
From: dany.cauchie@orange.com [mailto:dany.cauchie@orange.com= ]
Sent: 18 September 2012 17:13
To: vcarddav@ietf.org; scim@ietf.org; Bert Greevenbosch
Cc: Likepeng; MIENVILLE Thibaud OLNC/NAD
Subject: Upload of SCIM/vCard mapping draft

Hi all,

Here are my comments :

1) To be complete, in its sections 4 and 9, this document will have to take= into account other RFCs like :

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - RFC 6473
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - RFC 6474
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - RFC 6715

2) I noted 2 typos in section 4 :
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - ANIVERSARY instead of ANNIVERSARY
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - CATHEGORIES instead of CATEGORIES
Regards
Dany


----------------------------------------------------------------------
=A0 =A01. =A0Fwd: [scim] Upload of SCIM/vCard mapping draft
=A0 =A0 =A0 (Peter Saint-Andre)


----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Sep 2012 19:15:29 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: vcarddav@ietf.org
Subject: [VCARDDAV] Fwd: [scim] Upload of SCIM/vCard mapping draft
Message-ID: <50528531.2070903@stpeter.im>
Content-Type: text/plain; charset=3D"utf-8"

Of interest.


-------- Original Message --------
Subject: =A0 =A0 =A0 =A0[scim] Upload of SCIM/vCard mapping draft
Date: =A0 Fri, 14 Sep 2012 01:08:18 +0000
From: =A0 Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: =A0 =A0 scim@ietf.org <scim@ietf.org>



Hi all,



Yesterday I uploaded a draft that provides mapping between SCIM and
vCard. It is available under the following link:

http://datatracker.ietf.org/doc/draft-greevenbosc= h-scim-vcard-mapping/



The draft provides the mapping in two directions: from SCIM to vCard and from vCard to SCIM.



Open issues include the conversion method between SCIM ids and vCard
UIDs. When that is done, it should be easy to port the grouping function.


I think the draft is also very useful for the discussion on the format
to use for SCIM, and in which extent it will be related to vCard.



I look forward to your comments and suggestions!



Best regards,

Bert



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

------------------------------

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


End of VCARDDAV Digest, Vol 61, Issue 23
****************************************

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler<
--bcaec54c527c62995704ca360e00-- From andrew@badera.us Fri Sep 21 07:16:39 2012 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 2CEA121F884D for ; Fri, 21 Sep 2012 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfvdqmOl4-n1 for ; Fri, 21 Sep 2012 07:16:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93EC121F8849 for ; Fri, 21 Sep 2012 07:16:36 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4294402vcb.31 for ; Fri, 21 Sep 2012 07:16:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=KgA9svoK8PNmql7fcGx45JImd7bJvKyqgEBz9rhML+M=; b=oSBFd16mviH7Tm6GroLtTyjVGVLd26xuQY+HUn8kTfdQCOaZ7TTFRUSTGYgmBrNe73 X1Pgz2NsTaWqJ8/SAtN+4tnUlKgx2qQQCNEhILDugQCL5mJFNb374BinAuuvm/FlL7UB 4N1MMuWIzpBiLmJv5Rym4xRK30fP34prlOAffhl7RMDfXqNq2X8mzPtefcAKISluEr0D 7c5nkCsq5RSnXYtJDx7cEqx7uZdALeP3UDBjzQKgikcfnl7k4Gl/WR5r+rhNuT+I5O+o BVTpZ1+PfNCAXkZP4KdyuCp0kBg/CEyEVBCiRKS4lT1R3kb4sdMkPEj3lWV0ToqAaTUf mGOg== Received: by 10.52.35.16 with SMTP id d16mr1352739vdj.74.1348236996045; Fri, 21 Sep 2012 07:16:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.225.225 with HTTP; Fri, 21 Sep 2012 07:16:15 -0700 (PDT) In-Reply-To: References: From: Andrew Badera Date: Fri, 21 Sep 2012 09:16:15 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bc1038eab104ca36e3d1 X-Gm-Message-State: ALoCoQnt1WTqQKExkD8rvLx7tV/5uvYcdVAygNNiS0iOk9ki82lO6hGXNXS9dS4RvGWMkLJ7g1jY Subject: Re: [scim] Proprietary/custom properties 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, 21 Sep 2012 14:16:39 -0000 --20cf3079bc1038eab104ca36e3d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Ganesh, putting some thought into this. The issue with "custom extensions" as it were though still comes down to compatibility and validation issues. I feel like if I'm adopting a standard, that it should meet my needs without all sorts of caveats and kludges and hacks ... otherwise, what's the benefit to adopting a standard that doesn't fully serve its purpose? Somewhat philosophical, but the validation/compatibility stuff is purely technical. I can't imagine we're the only ones who have had such a need ... there must be a way to achieve this without risking broken validation down the line, and without a weighty, obtuse attributes bolt-on. Maybe something as simple as a property bag in the core user definition, simple name/value pairs ... --ab On Thu, Sep 20, 2012 at 9:01 PM, Ganesh and Sashi Prasad < g.c.prasad@gmail.com> wrote: > I've found that a simple naming convention (e.g., that all metadata > element names begin with an underscore) makes extensions much easier. Thi= s > only means the inclusion of a metadata element called "_value" to represe= nt > the value of an attribute, and this then makes the treatment of metadata > uniform. > > { "abc" : 123 } > > is semantically equivalent to > > { > "abc" : { > "_value" : 123 > } > } > > This is the same element expressed in terms of metadata. > > Now, we can extend this to add more metadata elements (custom properties)= , > woven into the resource structure itself, without breaking the original. > > { > "abc" : { > "_value" : 123, > "_created" : "2011-10-25T13:45", > "_updated" : "2012-03-18T08:05" > } > } > > If a system doesn't understand a custom metadata tag, it just ignores it. > > Nesting is also possible. > > { > "abc" : { "def" : 456, "ghi" : 789 } > } > > in expanded notation could be > > { > "abc" : { > "_value" : { > "def" : { > "_value" : 456, > "_replica" : true > }, > "ghi" : 789 > }, > "_created" : "2011-10-25T13:45", > "_updated" : "2012-03-18T08:05" > } > } > > The "_created" and "_updated" metadata tags refer to resource element > "abc" (same level as "_value" of "abc"). > The "_replica" tag refers to resource element "def" (same level as > "_value" of "def"). > Note that not all elements need be expanded (e.g., "ghi"). > > Regards, > Ganesh > > > On 21 September 2012 10:59, wrote: > >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/scim >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send scim mailing list submissions to >> scim@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >> >> You can reach the person managing the list at >> scim-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >> >> Today's Topics: >> >> 1. Re: Proprietary/custom properties (Emmanuel Dreux) >> 2. Re: Proprietary/custom properties (Andrew Badera) >> 3. Re: evaluating filters: true, false, and undefined (Dale Olds) >> >> >> >> ---------- Forwarded message ---------- >> From: Emmanuel Dreux >> To: Andrew Badera , "scim@ietf.org" >> Cc: >> Date: Thu, 20 Sep 2012 19:18:55 +0000 >> Subject: Re: [scim] Proprietary/custom properties >> >> Our own feedback :**** >> >> We=E2=80=99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.**= ** >> >> For both (=3D 100%), we=E2=80=99re extending the core user schema becaus= e we have >> to handle non standard defined attributes.**** >> >> ** ** >> >> --**** >> >> Cordialement / Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> ** ** >> >> *De :* Andrew Badera [mailto:andrew@badera.us] >> *Envoy=C3=A9 :* jeudi 20 septembre 2012 20:00 >> *=C3=80 :* scim@ietf.org >> *Objet :* [scim] Proprietary/custom properties**** >> >> ** ** >> >> Hello all-**** >> >> ** ** >> >> If an organization is looking at early adoption of SCIM and has a number >> of additional properties associated with users and groups that aren't pa= rt >> of core schema or existing/proposed extensions, is there a preferred or >> recommended way of handling those values? My thoughts to date are:**** >> >> ** ** >> >> 1. Treat it like an unofficial extension, (but then wonder about >> returning supporting schema and configs, though we may not support that = at >> this point anyhow)**** >> >> 2. Bolt-on a users and groups attribute system, which can easily get >> ugly, bloated, onerous and non-intuitive, fast. (Defining and supporting >> attributes and their metadata, supporting retrieval and modification on = a >> per-attribute basis, etc.)**** >> >> 3. Something I haven't considered, or missed being discussed on-list >> previously?**** >> >> ** ** >> >> These are not (strictly) LDAP values, though many are currently stored i= n >> otherwise-unused, sometimes repurposed LDAP fields. These run the gamut >> from users being "enabled" or "disabled" to user's roles (beyond usertyp= e) >> to user's customer details, etc.**** >> >> ** ** >> >> Thanks in advance for any insights- >> =E2=88=9E Andy Badera >> =E2=88=9E Technical Evangelist, MPS Partners, Chicago**** >> >> =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private >> =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera >> >> **** >> >> >> ---------- Forwarded message ---------- >> From: Andrew Badera >> To: "scim@ietf.org" >> Cc: >> Date: Thu, 20 Sep 2012 14:39:15 -0500 >> Subject: Re: [scim] Proprietary/custom properties >> Thanks Emmanuel. >> >> With JSON, as long as JSON remains schema-less, with most JSON >> serialization frameworks being fairly loose and lax, that's probably pre= tty >> pain-free. What about those consuming or serving XML however? Or what >> happens if JSON Schema is adopted? Won't extending the core schema open = up >> the possibility, create the likelihood even, of breakage due to validati= on >> issues? Or issues with anyone who's a very strict consumer? >> >> --ab >> >> >> On Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux wr= ote: >> >>> Our own feedback :**** >>> >>> We=E2=80=99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.*= *** >>> >>> For both (=3D 100%), we=E2=80=99re extending the core user schema becau= se we have >>> to handle non standard defined attributes.**** >>> >>> ** ** >>> >>> --**** >>> >>> Cordialement / Regards,**** >>> >>> Emmanuel Dreux**** >>> >>> http://www.cloudiway.com**** >>> >>> Tel: +33 4 26 78 17 58**** >>> >>> Mobile: +33 6 47 81 26 70**** >>> >>> skype: Emmanuel.Dreux**** >>> >>> ** ** >>> >>> *De :* Andrew Badera [mailto:andrew@badera.us] >>> *Envoy=C3=A9 :* jeudi 20 septembre 2012 20:00 >>> *=C3=80 :* scim@ietf.org >>> *Objet :* [scim] Proprietary/custom properties**** >>> >>> ** ** >>> >>> Hello all-**** >>> >>> ** ** >>> >>> If an organization is looking at early adoption of SCIM and has a numbe= r >>> of additional properties associated with users and groups that aren't p= art >>> of core schema or existing/proposed extensions, is there a preferred or >>> recommended way of handling those values? My thoughts to date are:**** >>> >>> ** ** >>> >>> 1. Treat it like an unofficial extension, (but then wonder about >>> returning supporting schema and configs, though we may not support that= at >>> this point anyhow)**** >>> >>> 2. Bolt-on a users and groups attribute system, which can easily get >>> ugly, bloated, onerous and non-intuitive, fast. (Defining and supportin= g >>> attributes and their metadata, supporting retrieval and modification on= a >>> per-attribute basis, etc.)**** >>> >>> 3. Something I haven't considered, or missed being discussed on-list >>> previously?**** >>> >>> ** ** >>> >>> These are not (strictly) LDAP values, though many are currently stored >>> in otherwise-unused, sometimes repurposed LDAP fields. These run the ga= mut >>> from users being "enabled" or "disabled" to user's roles (beyond userty= pe) >>> to user's customer details, etc.**** >>> >>> ** ** >>> >>> Thanks in advance for any insights- >>> =E2=88=9E Andy Badera >>> =E2=88=9E Technical Evangelist, MPS Partners, Chicago**** >>> >>> =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private >>> =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera >>> >>> **** >>> >> >> >> >> ---------- Forwarded message ---------- >> From: Dale Olds >> To: Kelly Grizzle >> Cc: Samuel Erdtman , "scim@ietf.org" >> Date: Thu, 20 Sep 2012 17:59:27 -0700 >> Subject: Re: [scim] evaluating filters: true, false, and undefined >> Kelly, thanks for the reply. I'm more interested in what is compatible >> with other implementations than a particular outcome, and your position = is >> certainly implementable. Just in case there are others that might agree >> with my reasoning, I will reply inline below, but I'm more interested in >> determining if the wg feels this issue should be clarified. >> >> replies inline: >> >> On 09/17/2012 09:53 AM, Kelly Grizzle wrote: >> >>> "Filters that contain references to attributes unknown to the server do >>>> not >>>> cause an error, but are evaluated such that those attributes are not >>>> present >>>> on each resource." >>>> >>> I would not support this. IMO filters that reference attributes that >>> are unknown by the server should return an error, otherwise the client = may >>> get unexpected results. >>> >> >> I think it depends on the client and how much the scim schema is extende= d >> in practice. If clients are tightly coupled to the server then they can >> expect specific attributes to be known and anything else is an error. If >> the scim server supports extensions (as our implementation does, and as = do >> others represented on this list), then IMO it's easier with fewer >> unexpected results if they can make queries that work in a reasonable >> fashion to different servers. >> >> >>> >>> we'd like to be able to write queries so that they work whether a >>>> particular >>>> scim server supports that extension or not. >>>> >>> The client should be able to use the /Schemas resource to determine >>> whether the server supports the extension. >>> >> >> Of course, but that means that an application needs to query the server >> first and will need to support multiple queries based on what extensions >> are supported. As I said above, it depends on the client application and >> how often there are variations in the server schema, but in my experienc= e >> it's crucial that schema extensions can be added without requiring clien= ts >> and servers to be in sync. >> >> >>> >>> In general, I am in favor of making things simpler for the client, but >>> this seems like a case where it would be beneficial for the server to b= e >>> more strict. >>> >> >> Complete agreement on keeping things simpler for the client, I just thin= k >> it's simpler to make logical queries rather than querying for schema >> support. >> >> I prefer: does joe have a hat or a foobar? >> >> rather than: if (server supports the foobar extension) then (does joe >> have a hat or a foobar?) else (does joe have a hat?) >> >> --Dale >> >> >>> --Kelly >>> >>> >>> -----Original Message----- >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >>> Dale Olds >>> Sent: Friday, September 14, 2012 8:18 PM >>> To: Samuel Erdtman >>> Cc: scim@ietf.org >>> Subject: Re: [scim] evaluating filters: true, false, and undefined >>> >>> I would expect that if "PR foobar" on a resource evaluates to false it >>> means "this resource has no value for attribute foobar", which is not q= uite >>> the same as "this server does not know what foobar means". >>> Nevertheless, if the server does not know what an attribute means no >>> resource will have a value for that attribute, so perhaps it's close >>> enough. I can't think of an example that's not overly contrived where t= he >>> difference would matter. >>> >>> One of the reasons I brought this issue up is because there are places >>> we'd like to add our own scim extensions, and we'd like to be able to w= rite >>> queries so that they work whether a particular scim server supports tha= t >>> extension or not. I also need to know how to handle undefined attribute= s in >>> our own server. >>> >>> Would the working group support this additional sentence to the first >>> paragraph of section 3.2.2.1? >>> >>> "Filters that contain references to attributes unknown to the server do >>> not cause an error, but are evaluated such that those attributes are no= t >>> present on each resource." >>> >>> --Dale >>> >>> On 09/11/2012 11:21 PM, Samuel Erdtman wrote: >>> >>>> In the scimproxy we will probably do it by interpreting undefined as >>>> false i.e. the statements would be evaluated as you describe it. >>>> However currently we only support one filter operation i.e. no 'and' >>>> 'or' stuff yet. Have actually not tested much filtering during the >>>> interops. >>>> >>>> If you would want to require foobar to be precent before evaluating >>>> rest of the expression you could state it as folows: >>>> ?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means >>>> present i.e. not undefined) >>>> >>>> Regards >>>> //Samuel >>>> >>>> On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >>>> >>>>> section 3.2.2.1 of the API doc describes filtering expressions and >>>>> bindings. >>>>> It is very clear about what should happen if an operator is not >>>>> defined (the example is 'regex'), but I do not see anything which >>>>> explicitly states what happens if an attribute in the expression is >>>>> not defined. The closest statement is in the first paragraph: "The >>>>> expression language that is used in the filter parameter supports >>>>> references to attributes and literals." I suppose that could mean a >>>>> reference to an unknown attribute is not supported, but it doesn't >>>>> really say that, and it doesn't say undefined attributes are an error= . >>>>> >>>>> In filtering code for similar systems I've seen implementations that >>>>> did not require attributes to be defined. This can be quite natural >>>>> but does make the implementation more interesting. Consider this >>>>> filter of rooms: >>>>> >>>>> True if contains someone with hat size > 7 or wearing a read shirt. >>>>> >>>>> There may not be anyone wearing a hat in any room, but it would still >>>>> find rooms with red shirts. IOW, it only takes one true component of >>>>> an 'or' >>>>> expression to make it true, even if one of the components is undefine= d. >>>>> >>>>> "True if someone with foobar > 7 or wearing a read shirt" works just >>>>> as well. >>>>> >>>>> This is not a big issue for us, we're just checking out >>>>> implementation options. What do most implementations currently do? >>>>> >>>>> --Dale >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/**listinfo/scim >>>>> >>>>> ______________________________**_________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/**listinfo/scim >>> >>> >>> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --20cf3079bc1038eab104ca36e3d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Ganesh, putting some thought into this.

The issue= with "custom extensions" as it were though still comes down to c= ompatibility and validation issues. I feel like if I'm adopting a stand= ard, that it should meet my needs without all sorts of caveats and kludges = and hacks ... otherwise, what's the benefit to adopting a standard that= doesn't fully serve its purpose? Somewhat philosophical, but the valid= ation/compatibility stuff is purely technical.

I can't imagine we're the only ones who have ha= d such a need ... there must be a way to achieve this without risking broke= n validation down the line, and without a weighty, obtuse attributes bolt-o= n. Maybe something as simple as a property bag in the core user definition,= simple name/value pairs ...

--ab


On Thu, Sep 20, 2012 at 9:01 PM, Ganesh = and Sashi Prasad <g.c.prasad@gmail.com> wrote:
I've found that a simple naming convention (e.g., that all metadata ele= ment names begin with an underscore) makes extensions much easier. This onl= y means the inclusion of a metadata element called "_value" to re= present the value of an attribute, and this then makes the treatment of met= adata uniform.

{ =C2=A0"abc" : 123 }

is = semantically equivalent to

{
=C2=A0 =C2= =A0 "abc" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value&= quot; : 123
=C2=A0 =C2=A0 }
}

This is the same element expressed in terms= of metadata.

Now, we can extend this to add more = metadata elements (custom properties), woven into the resource structure it= self, without breaking the original.

{
=C2=A0 =C2=A0 "abc" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" : 123,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 "_created" : "2011-10-25T13:45"= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_updated" : "2012-= 03-18T08:05"
=C2=A0 =C2=A0 }
}

If a system doesn= 't understand a custom metadata tag, it just ignores it.

=
Nesting is also possible.

{
= =C2=A0 =C2=A0 "abc" : { "def" : 456, "ghi" : = 789 }
}

in expanded notation could be
{
=C2=A0 =C2=A0 "abc" : {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" : {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "def" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "_value" = : 456,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;_replica" : true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ghi" = : 789
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 "_created" : "2011-10-25T13:45",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "_updated" : "2012-03-18T08= :05"
=C2=A0 =C2=A0 }
}

<= div>The "_created" and "_updated" metadata tags refer t= o resource element "abc" (same level as "_value" of &qu= ot;abc").
The "_replica" tag refers to resource element "def"= ; (same level as "_value" of "def").
Note tha= t not all elements need be expanded (e.g., "ghi").

Regards,
Ganesh


On 21 September 2012 10:59, <scim-request@ietf.= org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =C2=A0To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/scim

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =C2=A0You can set this option globally for all the list digests you receive at this point.



Send scim mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scim-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of scim digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Proprietary/custom properties (Emmanuel Dreux)
=C2=A0 =C2=A02. Re: Proprietary/custom properties (Andrew Badera)
=C2=A0 =C2=A03. Re: evaluating filters: true, false, and undefined (Dale Ol= ds)



---------- Forwarded message ----------
From:=C2=A0Emmanuel Dreu= x <edreux@clou= diway.com>
To:=C2=A0Andrew Badera <andrew@badera.us>, "scim@ietf.org" <scim@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 20 Sep 2012 19:18:55 +0000
Subject:=C2=A0Re= : [scim] Proprietary/custom properties

Our own fe= edback=C2=A0:

We=E2=80= =99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.

For both (= =3D 100%), we=E2=80=99re extending the core user schema because we have to = handle non standard defined attributes.

=C2= =A0

--

Cordialement / Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=C2=A0

De=C2=A0: Andr= ew Badera [mailto:and= rew@badera.us]
Envoy=C3=A9=C2=A0: jeudi 20 septembre 2012 20:00
=C3=80=C2=A0: sci= m@ietf.org
Objet=C2=A0: [scim] Proprietary/custom properties

=C2=A0

Hello all-

=C2=A0

If an organization is looking at early adoption of S= CIM and has a number of additional properties associated with users and gro= ups that aren't part of core schema or existing/proposed extensions, is= there a preferred or recommended way of handling those values? My thoughts to date are:

=C2=A0

1. Treat it like an unofficial extension, (but then = wonder about returning supporting schema and configs, though we may not sup= port that at this point anyhow)

2. Bolt-on a users and groups attribute system, whic= h can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining = and supporting attributes and their metadata, supporting retrieval and modi= fication on a per-attribute basis, etc.)

3. Something I haven't considered, or missed bei= ng discussed on-list previously?

=C2=A0

These are not (strictly) LDAP values, though many ar= e currently stored in otherwise-unused, sometimes repurposed LDAP fields. T= hese run the gamut from users being "enabled" or "disabled&q= uot; to user's roles (beyond usertype) to user's customer details, etc.

=C2=A0

Thanks in advance for any insights-
=E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chicago

=E2=88=9E This email = is: [ ] bloggable [x] ask first [ ] private
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera



---------- Forwarded message ---= -------
From:=C2=A0Andrew Badera <andrew@badera.us>
To:=C2=A0"scim@ietf.org" <scim@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 20 Sep 2012 14:39:15 -0500
Subject:=C2=A0Re= : [scim] Proprietary/custom properties
Thanks Emmanuel.

With JSON, as long as JSON remains schema-less, with most JSON serializa= tion frameworks being fairly loose and lax, that's probably pretty pain= -free. What about those consuming or serving XML however? Or what happens i= f JSON Schema is adopted? Won't extending the core schema open up the p= ossibility, create the likelihood even, of breakage due to validation issue= s? Or issues with anyone who's a very strict consumer?

--ab


On= Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

Our own fe= edback=C2=A0:

We=E2=80= =99re integrating SCIM on 2 SAAS provider=E2=80=99s platforms.

For both (= =3D 100%), we=E2=80=99re extending the core user schema because we have to = handle non standard defined attributes.

=C2= =A0

--

Cordialement / Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=C2=A0

De=C2=A0: Andr= ew Badera [mailto:and= rew@badera.us]
Envoy=C3=A9=C2=A0: jeudi 20 septembre 2012 20:00
=C3=80=C2=A0: sci= m@ietf.org
Objet=C2=A0: [scim] Proprietary/custom properties

=C2=A0

Hello all-

=C2=A0

If an organization is looking at early adoption of S= CIM and has a number of additional properties associated with users and gro= ups that aren't part of core schema or existing/proposed extensions, is= there a preferred or recommended way of handling those values? My thoughts to date are:

=C2=A0

1. Treat it like an unofficial extension, (but then = wonder about returning supporting schema and configs, though we may not sup= port that at this point anyhow)

2. Bolt-on a users and groups attribute system, whic= h can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining = and supporting attributes and their metadata, supporting retrieval and modi= fication on a per-attribute basis, etc.)

3. Something I haven't considered, or missed bei= ng discussed on-list previously?

=C2=A0

These are not (strictly) LDAP values, though many ar= e currently stored in otherwise-unused, sometimes repurposed LDAP fields. T= hese run the gamut from users being "enabled" or "disabled&q= uot; to user's roles (beyond usertype) to user's customer details, etc.

=C2=A0

Thanks in advance for any insights-
=E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chicago

=E2=88=9E This email = is: [ ] bloggable [x] ask first [ ] private
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera




---------- Forwarded message ----------
From:=C2=A0D= ale Olds <olds@rbcon= .com>
To:=C2=A0Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc:=C2=A0Samuel Erdtman <samuel@erdtman.se>, "scim@ietf.org" <scim@ietf.org>
Date:=C2=A0Thu, 20 Sep 2012 17:59:27 -0700
Subject:=C2=A0Re: [scim] evaluating filters: true, false, and undefined
= Kelly, thanks for the reply. I'm more interested in what is compatible = with other implementations than a particular outcome, and your position is = certainly implementable. Just in case there are others that might agree wit= h my reasoning, I will reply inline below, but I'm more interested in d= etermining if the wg feels this issue should be clarified.

replies inline:

On 09/17/2012 09:53 AM, Kelly Grizzle wrote:
"Filters that contain references to attributes unknown to the server d= o not
cause an error, but are evaluated such that those attributes are not presen= t
on each resource."
I would not support this. =C2=A0IMO filters that reference attributes that = are unknown by the server should return an error, otherwise the client may = get unexpected results.

I think it depends on the client and how much the scim schema is extended i= n practice. If clients are tightly coupled to the server then they can expe= ct specific attributes to be known and anything else is an error. If the sc= im server supports extensions (as our implementation does, and as do others= represented on this list), then IMO it's easier with fewer unexpected = results if they can make queries that work in a reasonable fashion to diffe= rent servers.



we'd like to be able to write queries so that they work whether a parti= cular
scim server supports that extension or not.
The client should be able to use the /Schemas resource to determine whether= the server supports the extension.

Of course, but that means that an application needs to query the server fir= st and will need to support multiple queries based on what extensions are s= upported. As I said above, it depends on the client application and how oft= en there are variations in the server schema, but in my experience it's= crucial that schema extensions can be added without requiring clients and = servers to be in sync.



In general, I am in favor of making things simpler for the client, but this= seems like a case where it would be beneficial for the server to be more s= trict.

Complete agreement on keeping things simpler for the client, I just think i= t's simpler to make logical queries rather than querying for schema sup= port.

I prefer: does joe have a hat or a foobar?

rather than: if (server supports the foobar extension) then (does joe have = a hat or a foobar?) else (does joe have a hat?)

--Dale


--Kelly


-----Original Message-----
From: scim-bounc= es@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dale Olds
Sent: Friday, September 14, 2012 8:18 PM
To: Samuel Erdtman
Cc: scim@ietf.org Subject: Re: [scim] evaluating filters: true, false, and undefined

I would expect that if "PR foobar" on a resource evaluates to fal= se it means "this resource has no value for attribute foobar", wh= ich is not quite the same as "this server does not know what foobar me= ans".
Nevertheless, if the server does not know what an attribute means no resour= ce will have a value for that attribute, so perhaps it's close enough. = I can't think of an example that's not overly contrived where the d= ifference would matter.

One of the reasons I brought this issue up is because there are places we&#= 39;d like to add our own scim extensions, and we'd like to be able to w= rite queries so that they work whether a particular scim server supports th= at extension or not. I also need to know how to handle undefined attributes= in our own server.

Would the working group support this additional sentence to the first parag= raph of section 3.2.2.1?

"Filters that contain references to attributes unknown to the server d= o not cause an error, but are evaluated such that those attributes are not = present on each resource."

--Dale

On 09/11/2012 11:21 PM, Samuel Erdtman wrote:
In the scimproxy we will probably do it by interpreting undefined as
false i.e. the statements would be evaluated as you describe it.
However currently we only support one filter operation i.e. no 'and'= ;
'or' stuff yet. Have actually not tested much filtering during the<= br> interops.

If you would want to require foobar to be precent before evaluating
rest of the expression you could state it as folows:
?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means
present i.e. not undefined)

Regards
//Samuel

On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds <olds@rbcon.com> wrote:
section 3.2.2.1 of the API doc describes filtering expressions and bindings= .
It is very clear about what should happen if an operator is not
defined (the example is 'regex'), but I do not see anything which explicitly states what happens if an attribute in the expression is
not defined. The closest statement is in the first paragraph: "The
expression language that is used in the filter parameter supports
references to attributes and literals." I suppose that could mean a reference to an unknown attribute is not supported, but it doesn't
really say that, and it doesn't say undefined attributes are an error.<= br>
In filtering code for similar systems I've seen implementations that did not require attributes to be defined. This can be quite natural
but does make the implementation more interesting. Consider this filter of = rooms:

True if contains someone with hat size > 7 or wearing a read shirt.

There may not be anyone wearing a hat in any room, but it would still
find rooms with red shirts. IOW, it only takes one true component of an = 9;or'
expression to make it true, even if one of the components is undefined.

"True if someone with foobar > 7 or wearing a read shirt" work= s just
as well.

This is not a big issue for us, we're just checking out
implementation options. What do most implementations currently do?

--Dale






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

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





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



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


--20cf3079bc1038eab104ca36e3d1-- From moransar@cisco.com Fri Sep 21 09:37:59 2012 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 58CB921F8669 for ; Fri, 21 Sep 2012 09:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbi-RG4ke2Sg for ; Fri, 21 Sep 2012 09:37:58 -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 5100521F8667 for ; Fri, 21 Sep 2012 09:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1348245478; x=1349455078; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nFfQQvOk7gBg1rNeQIalWHj7wot9RoFZEKvl37VWy9U=; b=jUYOisW/zpifImBg2nHSiXNZArATpeoY8/EejOjnMBCyRmh0eC3BUups SzKJ8OBx5oXhjsdvkeC32dBc2gqCUkkrkvG4KiBMWGX2nmN9ctiPg8bWC oUqThOWKWono/DJM9Fld1PGl9B4dIFUB4PVQjnN2p5ocIwMJixeUQtQYV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+XXFCtJXHA/2dsb2JhbABFvhaBCIIgAQEBBAEBAQ8BJzQLDAYBCBEEAQEBHgkuCxQJCAIEAQ0FIodjC5kWoBwEixyGJgOVZI45gWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="124044365" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 21 Sep 2012 16:37:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8LGbo1B001445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 16:37:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.212]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 11:37:49 -0500 From: "Morteza Ansari (moransar)" To: Dale Olds , Kelly Grizzle Thread-Topic: [scim] evaluating filters: true, false, and undefined Thread-Index: AQHNkIkdG2CTfFCpAEuRazLzJ/XUT5eGkJGAgARiEYCABCoeAIAFPrGAgACQ0wA= Date: Fri, 21 Sep 2012 16:37:49 +0000 Message-ID: In-Reply-To: <505BBBEF.1020309@rbcon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.167.5] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--57.398300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <611C801E7E6E984D9D404DEEAFE6DD4D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Samuel Erdtman , "scim@ietf.org" Subject: Re: [scim] evaluating filters: true, false, and undefined 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, 21 Sep 2012 16:37:59 -0000 You have raised a good question and we should clarify this in the spec. We should capture this in the issue tracker. Cheers, Morteza On 9/20/12 5:59 PM, "Dale Olds" wrote: >Kelly, thanks for the reply. I'm more interested in what is compatible >with other implementations than a particular outcome, and your position >is certainly implementable. Just in case there are others that might >agree with my reasoning, I will reply inline below, but I'm more >interested in determining if the wg feels this issue should be clarified. > >replies inline: > >On 09/17/2012 09:53 AM, Kelly Grizzle wrote: >>> "Filters that contain references to attributes unknown to the server >>>do not >>> cause an error, but are evaluated such that those attributes are not >>>present >>> on each resource." >> I would not support this. IMO filters that reference attributes that >>are unknown by the server should return an error, otherwise the client >>may get unexpected results. > >I think it depends on the client and how much the scim schema is >extended in practice. If clients are tightly coupled to the server then >they can expect specific attributes to be known and anything else is an >error. If the scim server supports extensions (as our implementation >does, and as do others represented on this list), then IMO it's easier >with fewer unexpected results if they can make queries that work in a >reasonable fashion to different servers. > >> >> >>> we'd like to be able to write queries so that they work whether a >>>particular >>> scim server supports that extension or not. >> The client should be able to use the /Schemas resource to determine >>whether the server supports the extension. > >Of course, but that means that an application needs to query the server >first and will need to support multiple queries based on what extensions >are supported. As I said above, it depends on the client application and >how often there are variations in the server schema, but in my >experience it's crucial that schema extensions can be added without >requiring clients and servers to be in sync. > >> >> >> In general, I am in favor of making things simpler for the client, but >>this seems like a case where it would be beneficial for the server to be >>more strict. > >Complete agreement on keeping things simpler for the client, I just >think it's simpler to make logical queries rather than querying for >schema support. > >I prefer: does joe have a hat or a foobar? > >rather than: if (server supports the foobar extension) then (does joe >have a hat or a foobar?) else (does joe have a hat?) > >--Dale > >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >>Dale Olds >> Sent: Friday, September 14, 2012 8:18 PM >> To: Samuel Erdtman >> Cc: scim@ietf.org >> Subject: Re: [scim] evaluating filters: true, false, and undefined >> >> I would expect that if "PR foobar" on a resource evaluates to false it >>means "this resource has no value for attribute foobar", which is not >>quite the same as "this server does not know what foobar means". >> Nevertheless, if the server does not know what an attribute means no >>resource will have a value for that attribute, so perhaps it's close >>enough. I can't think of an example that's not overly contrived where >>the difference would matter. >> >> One of the reasons I brought this issue up is because there are places >>we'd like to add our own scim extensions, and we'd like to be able to >>write queries so that they work whether a particular scim server >>supports that extension or not. I also need to know how to handle >>undefined attributes in our own server. >> >> Would the working group support this additional sentence to the first >>paragraph of section 3.2.2.1? >> >> "Filters that contain references to attributes unknown to the server do >>not cause an error, but are evaluated such that those attributes are not >>present on each resource." >> >> --Dale >> >> On 09/11/2012 11:21 PM, Samuel Erdtman wrote: >>> In the scimproxy we will probably do it by interpreting undefined as >>> false i.e. the statements would be evaluated as you describe it. >>> However currently we only support one filter operation i.e. no 'and' >>> 'or' stuff yet. Have actually not tested much filtering during the >>> interops. >>> >>> If you would want to require foobar to be precent before evaluating >>> rest of the expression you could state it as folows: >>> ?filter=3DPR foobar AND (foobar GT 7 OR shirtColor EG red) (PR means >>> present i.e. not undefined) >>> >>> Regards >>> //Samuel >>> >>> On Wed, Sep 12, 2012 at 3:51 AM, Dale Olds wrote: >>>> section 3.2.2.1 of the API doc describes filtering expressions and >>>>bindings. >>>> It is very clear about what should happen if an operator is not >>>> defined (the example is 'regex'), but I do not see anything which >>>> explicitly states what happens if an attribute in the expression is >>>> not defined. The closest statement is in the first paragraph: "The >>>> expression language that is used in the filter parameter supports >>>> references to attributes and literals." I suppose that could mean a >>>> reference to an unknown attribute is not supported, but it doesn't >>>> really say that, and it doesn't say undefined attributes are an error. >>>> >>>> In filtering code for similar systems I've seen implementations that >>>> did not require attributes to be defined. This can be quite natural >>>> but does make the implementation more interesting. Consider this >>>>filter of rooms: >>>> >>>> True if contains someone with hat size > 7 or wearing a read shirt. >>>> >>>> There may not be anyone wearing a hat in any room, but it would still >>>> find rooms with red shirts. IOW, it only takes one true component of >>>>an 'or' >>>> expression to make it true, even if one of the components is >>>>undefined. >>>> >>>> "True if someone with foobar > 7 or wearing a read shirt" works just >>>> as well. >>>> >>>> This is not a big issue for us, we're just checking out >>>> implementation options. What do most implementations currently do? >>>> >>>> --Dale >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Fri Sep 21 12:59:52 2012 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 67D2B21F86A0 for ; Fri, 21 Sep 2012 12:59:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O146X59eBzXS for ; Fri, 21 Sep 2012 12:59:51 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 1530021F841D for ; Fri, 21 Sep 2012 12:59:45 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q8LJxdmP023462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Sep 2012 21:59:43 +0200 (CEST) Message-ID: <505CC72B.9060300@mnt.se> Date: Fri, 21 Sep 2012 21:59:39 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373E79AF0C@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373E79AF0C@BY2PRD0410MB354.namprd04.prod.outlook.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] JSON Patch 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, 21 Sep 2012 19:59:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/19/2012 05:45 PM, Kelly Grizzle wrote: > Generally, I like the diff-like structure of JSON Patch and would > like to see something like this in SCIM. The main problem that I > have with it is that it relies on JSON Pointer, which uses indexes > to address list elements (eg - /bar/mylist/1). Index-based > patching does not seem like enough for SCIM. For example, a common > use case for patch is to add or remove a member to/from a group. > Having to know the list index before issuing this operation seems > onerous. Speaking as an individual, I agree. Having to pick up the index is not only onerous it introduces pretty bad race-conditions too. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBcxysACgkQ8Jx8FtbMZnc+nQCgjP+m+GwSQrAT15pHOtBALbEX ri8AoKMbiAuSlUr+GUZT8iMSzg1qLJEv =uhOk -----END PGP SIGNATURE----- From samuel@erdtman.se Sat Sep 22 09:56:23 2012 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 B177D21F86B1 for ; Sat, 22 Sep 2012 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc2XOIgT0hsZ for ; Sat, 22 Sep 2012 09:56:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D431A21F8670 for ; Sat, 22 Sep 2012 09:56:22 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5391197vcb.31 for ; Sat, 22 Sep 2012 09:56:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=60T2kRb3qhNgPUyVik+4aL2rGIGGyNHvE6Ig0uQsp7w=; b=GWYnS49dRF7Daoa06c0jqBp4RKW1lUba4+s4WOs3sF21xzv0kY5pOlpJACwFwC0jNS GR7ww29mncOVnB7FL/tSVN+5N7dWX1q9Z5DYwuwbHqowtc4DjmTY+1pCG7cZ1tIj1adW Xj87DJ3ovTeTl7+DkbxRlv/qAtZsK7B7DsaX8idpDg97TOr2qVx+2N4kmUtUmjmzihFU a88isSu7Suc81DqykGjCiqZeh7r7xCsRyuIBd1ngE9idoJGkpH39jU/qMEBc41xU3D3S H/tjBU/vLru/UlAeLIgWWkABHdJL/1xcn92RN2DFVl3qypAy3+NAcyq6WODQNgduGxiS xRiw== Received: by 10.58.91.133 with SMTP id ce5mr1542622veb.27.1348332981985; Sat, 22 Sep 2012 09:56:21 -0700 (PDT) References: From: Samuel Erdtman Mime-Version: 1.0 (1.0) In-Reply-To: Date: Sat, 22 Sep 2012 18:56:23 +0200 Message-ID: <-1826268799262697061@unknownmsgid> To: Andrew Badera Content-Type: multipart/alternative; boundary=047d7b5daebe6e203204ca4d3c2f X-Gm-Message-State: ALoCoQkk9WgWYc+JXPKbuGvkA4/0G9hfM7WpPXsFuMFFI0n6w7cBr+XKuUcUwlt2OrcpHBAXW2UU Cc: "scim@ietf.org" Subject: Re: [scim] Proprietary/custom properties 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, 22 Sep 2012 16:56:23 -0000 --047d7b5daebe6e203204ca4d3c2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would go for option 1 with an unofficial extension created according to the extensions rules with a schema name and config for discovery. Then when you have it in place or want some opinions on the extension I would present it to the list, and if it is an extension that solves a common problem it might become an official extension. Cheers //Samuel Sent from my iPad On 20 sep 2012, at 20:00, Andrew Badera wrote: Hello all- If an organization is looking at early adoption of SCIM and has a number of additional properties associated with users and groups that aren't part of core schema or existing/proposed extensions, is there a preferred or recommended way of handling those values? My thoughts to date are: 1. Treat it like an unofficial extension, (but then wonder about returning supporting schema and configs, though we may not support that at this point anyhow) 2. Bolt-on a users and groups attribute system, which can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining and supporting attributes and their metadata, supporting retrieval and modification on a per-attribute basis, etc.) 3. Something I haven't considered, or missed being discussed on-list previously? These are not (strictly) LDAP values, though many are currently stored in otherwise-unused, sometimes repurposed LDAP fields. These run the gamut from users being "enabled" or "disabled" to user's roles (beyond usertype) to user's customer details, etc. Thanks in advance for any insights- =E2=88=9E Andy Badera =E2=88=9E Technical Evangelist, MPS Partners, Chicago =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --047d7b5daebe6e203204ca4d3c2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would go for option 1 with an un= official extension created according to the extensions rules with a schema = name and config for=C2=A0discovery. Then when you have it in place or want = some opinions on the extension I would present it to the list, and if it is= an extension that solves a common problem it might become an official exte= nsion.

Cheers
//Samuel

Sent from my iP= ad

On 20 sep 2012, at 20:00, Andrew Badera <andrew@badera.us> wrote:

Hello all-

If an organization is looking at early a= doption of SCIM and has a number of additional properties associated with u= sers and groups that aren't part of core schema or existing/proposed ex= tensions, is there a preferred or recommended way of handling those values?= My thoughts to date are:

1. Treat it like an unofficial extension, (but then won= der about returning supporting schema and configs, though we may not suppor= t that at this point anyhow)
2. Bolt-on a users and groups attrib= ute system, which can easily get ugly, bloated, onerous and non-intuitive, = fast. (Defining and supporting attributes and their metadata, supporting re= trieval and modification on a per-attribute basis, etc.)
3. Something I haven't considered, or missed being discussed on-li= st previously?

These are not (strictly) LDAP value= s, though many are currently stored in otherwise-unused, sometimes repurpos= ed LDAP fields. These run the gamut from users being "enabled" or= "disabled" to user's roles (beyond usertype) to user's c= ustomer details, etc.

Thanks in advance for any insights-
= =E2=88=9E Andy Badera
=E2=88=9E Technical Evangelist, MPS Partners, Chic= ago
=E2=88=9E This email is: [ ] bloggable [x] ask first [ ] priv= ate
=E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera


--047d7b5daebe6e203204ca4d3c2f--