From nobody Fri May 1 03:38:51 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982D1B30EC for ; Fri, 1 May 2015 03:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZFeXtn3xf1I for ; Fri, 1 May 2015 03:38:50 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10391B30EB for ; Fri, 1 May 2015 03:38:49 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so86644089ieb.3 for ; Fri, 01 May 2015 03:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=rAkR7q6WkSMMmNoVMM64Ki9WJZrp0TkL8co/yNkKuj4=; b=hdTnJtzh6HGWNjz771Ivot0sHFwE8pRo/CpqrOrEYsB5Lrsbz9ICYjD/GbDfT5KLHI DltcCrCpk1m+zpQKMn4v/F3ZPNjqJUHpqFsCP3V8TarHxVVlSOT94ckt9FI3ZmkfnT6Q WwWNRwqP1PMEIapFfR6opikNpeRHnHG0L3lOs4pZ1rFXB+CKoffp3GzjFfuwHZXlFp4P 5vLG1815YNhYrVpbitQVbJvm/4Ij3nIPKsV79bN0pwQJsB5f7oX3/WxnTeeOO/sGCSoO Aikkiq77n2/ZriY8pd/zP82+bdBYkXb2PKVL1lvXJtlr25TakbZViUiDjj5+38vp4IH6 +Uaw== MIME-Version: 1.0 X-Received: by 10.50.25.137 with SMTP id c9mr9296136igg.29.1430476729430; Fri, 01 May 2015 03:38:49 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Fri, 1 May 2015 03:38:49 -0700 (PDT) Date: Fri, 1 May 2015 11:38:49 +0100 X-Google-Sender-Auth: I4Ux4TlIQXPlagke6AAseNlu_1A Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [scim] Are core-schema and api ready for IESG Evaluation? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:38:51 -0000 Phil has posted revised I-Ds for core-schema and api, but I have not heard from the document shepherds: have all the last call comments been addressed, and are these ready to go into IESG Evaluation? Barry From nobody Fri May 1 03:39:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2499D1B30F0 for ; Fri, 1 May 2015 03:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7FCb4qFSaZT for ; Fri, 1 May 2015 03:39:44 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50501B30EF for ; Fri, 1 May 2015 03:39:43 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so35469617igb.1 for ; Fri, 01 May 2015 03:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=tDfIvPJV6inyk8Uy/6R7h2Y398xuRM1akcbFl+Cv9DU=; b=EVXotrXkn1W/tvzHWHa4RajqdXilwnrVk7CwjAIunBmTC4ThfP75lUF0PDKMhjpqij g1pcBB959LkcAOVKC3Vdas9XMQQW09ABfrZpTOPltWAyDn3DkmAtIuddKEB/K6rwrKVx taHZQb+pD+uSzSTAqdsDGWJlxs0V8IhkJ5CHNvHu1134a06xFAftybdPMg2QAcAUlEqv CeHMnku2xjIhjTNb6CFPqk5i1RIlCJ0vifUPrO4R7gJp/hr3kU1HHHo8a0Voj+u1Fmu0 HYZaoawsOxVWD1Tej7O4GN4yEjBfkA9OByzhE1q0oHboTdoZfdqWtu0RIgcDPseFkLh7 AIwg== MIME-Version: 1.0 X-Received: by 10.50.225.35 with SMTP id rh3mr9288367igc.29.1430476783483; Fri, 01 May 2015 03:39:43 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Fri, 1 May 2015 03:39:43 -0700 (PDT) Date: Fri, 1 May 2015 11:39:43 +0100 X-Google-Sender-Auth: eAinU9ZxZ3TcGUI8aKf2KUph6lQ Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:39:45 -0000 There's still a DISCUSS on the use-cases doc. What is the status of addressing that, as well as the non-blocking comments from IESG evaluation? Barry From nobody Fri May 1 04:03:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8F1B3036 for ; Fri, 1 May 2015 04:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeDTtm7Yj1Bi for ; Fri, 1 May 2015 04:03:01 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3491B2CD2 for ; Fri, 1 May 2015 04:03:01 -0700 (PDT) Received: by wgyo15 with SMTP id o15so87995952wgy.2 for ; Fri, 01 May 2015 04:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=duzMxj3imW9AEPdy2GxXwi2RJcBsnaSH1jFneyyWD7w=; b=rxltSXBgkXTOzSCrNKP9KZ3n+zGkUoUfOxwLbpoi0GQJ4hmD0a9BSV5yzEddU8HB3S ZP2yI1m9InJrB0KgyfKuAkyxEv2uxJ9dG0CslxWuwOQLQTXjKFkL8lcbMZPZj+zthkJq mAw2zCTXcVAR/pjtUmH94hi0dqG9UuE60QAmYZoUA3FiFQqpS5+99FsxAOG7QztB/E3n TugwB5nk4NR55RPAHQOBHWi9othhAE9vCMdSDPEEGQATSZHVjzJ9eDx+Ep9p41KFnkNn nwfYcyYxtDVax4/MUBBqvAt1Qy4BxKTPj2JXjqa7ChuC7rAwOheeD5NVAu9gWZhfYl5r DCgA== MIME-Version: 1.0 X-Received: by 10.180.103.130 with SMTP id fw2mr13682838wib.87.1430478179796; Fri, 01 May 2015 04:02:59 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.6.2 with HTTP; Fri, 1 May 2015 04:02:59 -0700 (PDT) Date: Fri, 1 May 2015 21:02:59 +1000 X-Google-Sender-Auth: XmzSEf9p3IoDguHqNa84xbFYKSM Message-ID: From: Grahame Grieve To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428d24c40f330515032787 Archived-At: Subject: [scim] User templates X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 11:03:02 -0000 --f46d04428d24c40f330515032787 Content-Type: text/plain; charset=UTF-8 hi I've just been working on my scim implementation. One of the things I ran into is that my system - and others I've worked on - have the concept of user Templates - the shell of a valid user that you copy and fill out when creating a real user. Some systems make these a different kind of entity, some make them a special kind of user, and others just give a standard user a special name. I also have an account for 'anonymous' - that's something different again. Has this kind of differentiation been discussed? Note: in some ways, you could achieve some of this using schema, but not other parts of it. Grahame -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --f46d04428d24c40f330515032787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi

I've just been working on my scim implementation.= One of the things I ran into is that my system - and others I've worke= d on - have the concept of user Templates - the shell of a valid user that = you copy and fill out when creating a real user. Some systems make these a = different kind of entity, some make them a special kind of user, and others= just give a standard user a special name.

I also = have an account for 'anonymous' - that's something different ag= ain.

Has this kind of differentiation been discuss= ed? Note: in some ways, you could achieve some of this using schema, but no= t other parts of it.

Grahame=C2=A0


--=
-----
http://www.healthintersections.com.au / grahame@healthintersections= .com.au / +61 411 867 065
--f46d04428d24c40f330515032787-- From nobody Fri May 1 13:31:01 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF671A9135 for ; Fri, 1 May 2015 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk0-nzEymN_H for ; Fri, 1 May 2015 13:30:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C019E1A8B84 for ; Fri, 1 May 2015 13:30:57 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 1 May 2015 20:30:38 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.112]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.112]) with mapi id 15.01.0148.019; Fri, 1 May 2015 20:30:38 +0000 From: Kelly Grizzle To: Grahame Grieve , "scim@ietf.org" Thread-Topic: [scim] User templates Thread-Index: AQHQg/5oy+lkLssJg0OLrLwur+xZMp1nksqg Date: Fri, 1 May 2015 20:30:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 3C3EF0B1009BB03C3EF1FE authentication-results: healthintersections.com.au; dkim=none (message not signed) header.d=none; x-originating-ip: [97.79.140.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB389; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(50986999)(19580395003)(106116001)(2501003)(16236675004)(54356999)(77156002)(19625215002)(86362001)(74316001)(76176999)(102836002)(62966003)(15975445007)(33656002)(19617315012)(107886002)(40100003)(16601075003)(19580405001)(99286002)(2950100001)(87936001)(76576001)(122556002)(66066001)(46102003)(5001770100001)(92566002)(19300405004)(2656002)(5001960100002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB3922E58F4C62DAE7DCFC033E2D50BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2015 20:30:38.2725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 Archived-At: Subject: Re: [scim] User templates X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 20:30:59 -0000 --_000_BN1PR04MB3922E58F4C62DAE7DCFC033E2D50BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JhaGFtIC4uLiBJIGRvbuKAmXQgcmVtZW1iZXIgaGVhcmluZyBhbnkgZGlzY3Vzc2lvbnMgYXJv dW5kIHRoaXMuICBUaGUgZmlyc3Qgc29sdXRpb24gdGhhdCBwb3BzIHRvIG15IG1pbmQgaXMgdG8g Y3JlYXRlIGEgbmV3IHJlc291cmNlIHR5cGUgZm9yIHVzZXIgdGVtcGxhdGVzLCBidXQgdXNlIHRo ZSBzYW1lIHVzZXIgc2NoZW1hIHRoYXQgeW91IHVzZSBmb3IgdGhlIFVzZXJzIHJlc291cmNlLiAg VGhpcyB3b3VsZCBrZWVwIHRoZSBmYWtlIHRlbXBsYXRlIHVzZXJzIHNlcGFyYXRlZCAod2hlbiBz ZWFyY2hpbmcsIGV0Y+KApikgZnJvbSB0aGUgcmVhbCB1c2Vycy4NCg0KLS1LZWxseQ0KDQpGcm9t OiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JhaGFt ZSBHcmlldmUNClNlbnQ6IEZyaWRheSwgTWF5IDAxLCAyMDE1IDY6MDMgQU0NClRvOiBzY2ltQGll dGYub3JnDQpTdWJqZWN0OiBbc2NpbV0gVXNlciB0ZW1wbGF0ZXMNCg0KaGkNCg0KSSd2ZSBqdXN0 IGJlZW4gd29ya2luZyBvbiBteSBzY2ltIGltcGxlbWVudGF0aW9uLiBPbmUgb2YgdGhlIHRoaW5n cyBJIHJhbiBpbnRvIGlzIHRoYXQgbXkgc3lzdGVtIC0gYW5kIG90aGVycyBJJ3ZlIHdvcmtlZCBv biAtIGhhdmUgdGhlIGNvbmNlcHQgb2YgdXNlciBUZW1wbGF0ZXMgLSB0aGUgc2hlbGwgb2YgYSB2 YWxpZCB1c2VyIHRoYXQgeW91IGNvcHkgYW5kIGZpbGwgb3V0IHdoZW4gY3JlYXRpbmcgYSByZWFs IHVzZXIuIFNvbWUgc3lzdGVtcyBtYWtlIHRoZXNlIGEgZGlmZmVyZW50IGtpbmQgb2YgZW50aXR5 LCBzb21lIG1ha2UgdGhlbSBhIHNwZWNpYWwga2luZCBvZiB1c2VyLCBhbmQgb3RoZXJzIGp1c3Qg Z2l2ZSBhIHN0YW5kYXJkIHVzZXIgYSBzcGVjaWFsIG5hbWUuDQoNCkkgYWxzbyBoYXZlIGFuIGFj Y291bnQgZm9yICdhbm9ueW1vdXMnIC0gdGhhdCdzIHNvbWV0aGluZyBkaWZmZXJlbnQgYWdhaW4u DQoNCkhhcyB0aGlzIGtpbmQgb2YgZGlmZmVyZW50aWF0aW9uIGJlZW4gZGlzY3Vzc2VkPyBOb3Rl OiBpbiBzb21lIHdheXMsIHlvdSBjb3VsZCBhY2hpZXZlIHNvbWUgb2YgdGhpcyB1c2luZyBzY2hl bWEsIGJ1dCBub3Qgb3RoZXIgcGFydHMgb2YgaXQuDQoNCkdyYWhhbWUNCg0KDQotLQ0KLS0tLS0N Cmh0dHA6Ly93d3cuaGVhbHRoaW50ZXJzZWN0aW9ucy5jb20uYXUgLyBncmFoYW1lQGhlYWx0aGlu dGVyc2VjdGlvbnMuY29tLmF1PG1haWx0bzpncmFoYW1lQGhlYWx0aGludGVyc2VjdGlvbnMuY29t LmF1PiAvICs2MSA0MTEgODY3IDA2NQ0K --_000_BN1PR04MB3922E58F4C62DAE7DCFC033E2D50BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkdyYWhhbSAuLi4gSSBkb27igJl0IHJlbWVtYmVyIGhlYXJpbmcgYW55IGRpc2N1c3Npb25z IGFyb3VuZCB0aGlzLiZuYnNwOyBUaGUgZmlyc3Qgc29sdXRpb24gdGhhdCBwb3BzIHRvIG15IG1p bmQgaXMgdG8gY3JlYXRlIGEgbmV3IHJlc291cmNlIHR5cGUgZm9yIHVzZXIgdGVtcGxhdGVzLA0K IGJ1dCB1c2UgdGhlIHNhbWUgdXNlciBzY2hlbWEgdGhhdCB5b3UgdXNlIGZvciB0aGUgVXNlcnMg cmVzb3VyY2UuJm5ic3A7IFRoaXMgd291bGQga2VlcCB0aGUgZmFrZSB0ZW1wbGF0ZSB1c2VycyBz ZXBhcmF0ZWQgKHdoZW4gc2VhcmNoaW5nLCBldGPigKYpIGZyb20gdGhlIHJlYWwgdXNlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tLUtlbGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5HcmFoYW1lIEdyaWV2ZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAwMSwgMjAxNSA2 OjAzIEFNPGJyPg0KPGI+VG86PC9iPiBzY2ltQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtzY2ltXSBVc2VyIHRlbXBsYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGk8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUganVzdCBi ZWVuIHdvcmtpbmcgb24gbXkgc2NpbSBpbXBsZW1lbnRhdGlvbi4gT25lIG9mIHRoZSB0aGluZ3Mg SSByYW4gaW50byBpcyB0aGF0IG15IHN5c3RlbSAtIGFuZCBvdGhlcnMgSSd2ZSB3b3JrZWQgb24g LSBoYXZlIHRoZSBjb25jZXB0IG9mIHVzZXIgVGVtcGxhdGVzIC0gdGhlIHNoZWxsIG9mIGEgdmFs aWQgdXNlciB0aGF0IHlvdSBjb3B5IGFuZCBmaWxsIG91dCB3aGVuIGNyZWF0aW5nIGEgcmVhbA0K IHVzZXIuIFNvbWUgc3lzdGVtcyBtYWtlIHRoZXNlIGEgZGlmZmVyZW50IGtpbmQgb2YgZW50aXR5 LCBzb21lIG1ha2UgdGhlbSBhIHNwZWNpYWwga2luZCBvZiB1c2VyLCBhbmQgb3RoZXJzIGp1c3Qg Z2l2ZSBhIHN0YW5kYXJkIHVzZXIgYSBzcGVjaWFsIG5hbWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBoYXZlIGFuIGFjY291bnQg Zm9yICdhbm9ueW1vdXMnIC0gdGhhdCdzIHNvbWV0aGluZyBkaWZmZXJlbnQgYWdhaW4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcyB0aGlz IGtpbmQgb2YgZGlmZmVyZW50aWF0aW9uIGJlZW4gZGlzY3Vzc2VkPyBOb3RlOiBpbiBzb21lIHdh eXMsIHlvdSBjb3VsZCBhY2hpZXZlIHNvbWUgb2YgdGhpcyB1c2luZyBzY2hlbWEsIGJ1dCBub3Qg b3RoZXIgcGFydHMgb2YgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkdyYWhhbWUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0gPGJyPg0KLS0tLS08YnI+DQo8YSBocmVm PSJodHRwOi8vd3d3LmhlYWx0aGludGVyc2VjdGlvbnMuY29tLmF1IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3d3dy5oZWFsdGhpbnRlcnNlY3Rpb25zLmNvbS5hdTwvYT4gLw0KPGEgaHJlZj0ibWFp bHRvOmdyYWhhbWVAaGVhbHRoaW50ZXJzZWN0aW9ucy5jb20uYXUiIHRhcmdldD0iX2JsYW5rIj5n cmFoYW1lQGhlYWx0aGludGVyc2VjdGlvbnMuY29tLmF1PC9hPiAvICYjNDM7NjEgNDExIDg2NyAw NjU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB3922E58F4C62DAE7DCFC033E2D50BN1PR04MB392namprd_-- From nobody Fri May 1 15:10:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B448B1A0397 for ; Fri, 1 May 2015 15:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48bhUDN2HqOL for ; Fri, 1 May 2015 15:10:47 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C053A1A0334 for ; Fri, 1 May 2015 15:10:46 -0700 (PDT) Received: by wizk4 with SMTP id k4so64840359wiz.1 for ; Fri, 01 May 2015 15:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cfDUDsHykXoEcRd01O+k227HtRktv9vTF94346fadMs=; b=f/grbiCwgZfMWUN7TgS2MjIntuhxJvZF6MS14sVyO2B5wieH4BZJAPeIkUh5vjX0Sd 0/7kOswPL7hSMcLirthjhLEfnKdvTc3+XeoVrHgMHBqHu9ssmWlBXJtsU+6/jyFfazME cmvN+7CAU+gzMH+cnh5UNjYWE3qhZhg9+zhJAlUKMsqoyQOXni7n0sSnTysU/zBCSX/N qiU9f9DlzRrQJZtU76IOk85skNNZKTkMDIEzzqTWZ8FdfLUxab0zKZJxZ8Aj5QsoMTjS yVgZxnPMMNZJ5I3lLe1pXly0nN/+7QXCFwRSEQXRiLohZHYISgCoSdEIw8sNwL0VOXCm Coyg== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr21898986wjc.14.1430518245564; Fri, 01 May 2015 15:10:45 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.6.2 with HTTP; Fri, 1 May 2015 15:10:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 May 2015 08:10:45 +1000 X-Google-Sender-Auth: iLktVXNPI7Wc7i2LKc641pLrcjw Message-ID: From: Grahame Grieve To: Kelly Grizzle Content-Type: multipart/alternative; boundary=047d7bb70c58df267405150c7bef Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] User templates X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:10:48 -0000 --047d7bb70c58df267405150c7bef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kelly You could achieve the same by adding a enumerated field type to the existing resource : { normal, proxy, template }. (though I'm not necessarily advocating for that - there's pros and cons). I think that this will come up often enough to be justified addressing in a future version Grahame On Sat, May 2, 2015 at 6:30 AM, Kelly Grizzle wrote: > Graham ... I don=E2=80=99t remember hearing any discussions around this.= The > first solution that pops to my mind is to create a new resource type for > user templates, but use the same user schema that you use for the Users > resource. This would keep the fake template users separated (when > searching, etc=E2=80=A6) from the real users. > > > > --Kelly > > > > *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Grahame Grieve > *Sent:* Friday, May 01, 2015 6:03 AM > *To:* scim@ietf.org > *Subject:* [scim] User templates > > > > hi > > > > I've just been working on my scim implementation. One of the things I ran > into is that my system - and others I've worked on - have the concept of > user Templates - the shell of a valid user that you copy and fill out whe= n > creating a real user. Some systems make these a different kind of entity, > some make them a special kind of user, and others just give a standard us= er > a special name. > > > > I also have an account for 'anonymous' - that's something different again= . > > > > Has this kind of differentiation been discussed? Note: in some ways, you > could achieve some of this using schema, but not other parts of it. > > > > Grahame > > > > -- > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.a= u > / +61 411 867 065 > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --047d7bb70c58df267405150c7bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kelly

You could achieve the same by = adding a enumerated field type to the existing resource : { normal, proxy, = template }. (though I'm not necessarily advocating for that - there'= ;s pros and cons).=C2=A0

I think that this will co= me up often enough to be justified addressing in a future version

Grahame


On Sat, May 2, 2015 at 6:30 AM, Kelly Griz= zle <kelly.grizzle@sailpoint.com> wrote:

Graham ... I don=E2=80=99= t remember hearing any discussions around this.=C2=A0 The first solution th= at pops to my mind is to create a new resource type for user templates, but use the same user schema that you use for the Users resource.=C2=A0 Th= is would keep the fake template users separated (when searching, etc=E2=80= =A6) from the real users.

=C2=A0

--Kelly

=C2=A0

From: scim [ma= ilto:scim-bounce= s@ietf.org] On Behalf Of Grahame Grieve
Sent: Friday, May 01, 2015 6:03 AM
To: scim@ietf.org=
Subject: [scim] User templates

=C2=A0

hi

=C2=A0

I've just been working on my scim implementation= . One of the things I ran into is that my system - and others I've work= ed on - have the concept of user Templates - the shell of a valid user that= you copy and fill out when creating a real user. Some systems make these a different kind of entity, some make them a= special kind of user, and others just give a standard user a special name.=

=C2=A0

I also have an account for 'anonymous' - tha= t's something different again.

=C2=A0

Has this kind of differentiation been discussed? Not= e: in some ways, you could achieve some of this using schema, but not other= parts of it.

=C2=A0

Grahame=C2=A0



--
-----
http://= www.healthintersections.com.au / gra= hame@healthintersections.com.au / +61 411 867 065




--
-----
http://www.healthintersections.com.au / grahame@he= althintersections.com.au / +61 411 867 065
--047d7bb70c58df267405150c7bef-- From nobody Sat May 2 08:47:58 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5615A1A8997; Sat, 2 May 2015 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.349 X-Spam-Level: ** X-Spam-Status: No, score=2.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc5oGgX9wt10; Sat, 2 May 2015 08:47:55 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id A439F1A8991; Sat, 2 May 2015 08:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430581672; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=N19qIYLab/vHViUZ/R+yGIMtYi7XgRrUG0kssy0qWZE=; b=p+huZCd3G4T8X17CZZe0NQKxGEROsAaaoCaEogwwWxuEVcuES5JsHmLuIkcYNBk0Yv5z0xHExOedC08BL1HyhY23gOw9H6eClTSNdWbql2sNfSLIf2DYunFv9BBG5a2p78syKVQo7UHbXwV896u153Y5i4uriiDfcMB6kzn5KRQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03048; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=7; RT=7; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 02 May 2015 23:47:50 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 02 May 2015 23:47:46 +0800 From: "Kepeng Li" To: Benoit Claise , The IESG Message-ID: Thread-Topic: Benoit Claise's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) References: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> In-Reply-To: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: scim@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, draft-ietf-scim-use-cases@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: Re: [scim] Benoit Claise's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 15:47:57 -0000 Hi Benoit, Thanks for your review and comments. Please find my proposed changes below. Kind Regards Kepeng =D4=DA 23/4/15 5:07 pm=A3=AC "Benoit Claise" =D0=B4=C8=EB: >Benoit Claise has entered the following ballot position for >draft-ietf-scim-use-cases-06: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- From the charter: > The use cases document will be a "living document", guiding the > working group during its development of the standards. The group may > take snapshots of that document for Informational publication, to > serve as documentation of the motivation for the work in progress > and to similarly guide planning and implementation. > > ... > Mar 2013 - Initial adoption of SCIM use cases, as a living document > >Looking at the charter and the draft name, I was ready to ask: is this a >living document? should it be published? >Reading the draft, it contains way more than the use cases: concepts and >requirements are included. >Which means that, even if you add new use cases, the requirements will >(hopefully) not change. This is a good reason to publish. >You should really update the title, and potentially the abstract to match >the content: a mix of use cases, requirements, some (framework type of >level) concepts and flows. Don't get me wrong, it's not a bad thing to >combine all these into a single document, and I enjoyed the read. >Proposal: from "SCIM Definitions, Overview, and Flows" to something such >as "SCIM Definitions, Overview, Concepts, and Requirements" OK, changed. I also changed the abstract and introduction. > >- I'm certainly not an expert in identity management, but I understood >the difference between SCIM and ABFAB as ABFAB =3D just in time >provisioning, as opposed to SCIM =3D pre-provisioning (ok, except maybe in >the SSO "special" use case). A few words on this in the intro would have >helped me to put the right context. As proposed by Leif, I added: Unlike the practice of some protocols like ABFAB and SAML2 WebSSO, SCIM provides provisioning and de-provisioning of resources in a separate context from authentication (aka just-in-time provisioning). > >Editorial: >- It's intent is to reduce -> Its intend is to reduce >- C.R.U.D -> CRUD (since you have it in the acronym section) OK, changed. From nobody Sat May 2 09:12:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19761A0143; Sat, 2 May 2015 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1AmBbYveDus; Sat, 2 May 2015 09:12:28 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E41A1A9C; Sat, 2 May 2015 09:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430583144; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=iNK4MvYWOheKYoT5mOkfiKk+Qwolo8mmjuw0O11VwmI=; b=eEmZ++6WMXdS3+zir2MNwY38F1cyjgvLfBWGEENTe/Fza4eRdnwpDH7JjmRja9ObRW/UHgOfd21goFr7ADhl0TpsocPHmQbtMRXMXxoc7QnlxYjuiaaqFNN80jJ8SMGfWm83yx+TL0BP/6dh3FBhc4rSBhQ1bVkle+iwovOT+RQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R891e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03018; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=7; RT=7; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 03 May 2015 00:12:22 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 03 May 2015 00:12:11 +0800 From: "Kepeng Li" To: Kathleen Moriarty , The IESG Message-ID: Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT) References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> In-Reply-To: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: scim@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, draft-ietf-scim-use-cases@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:12:29 -0000 Hi Kathleen, Thanks for your review and comments. Please find my proposed changes below. Kind Regards Kepeng =D4=DA 23/4/15 11:24 pm=A3=AC "Kathleen Moriarty" =D0=B4=C8=EB: >Kathleen Moriarty has entered the following ballot position for >draft-ietf-scim-use-cases-06: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I had a discuss on section 3.4, that should be quick to clear up on >privacy and security considerations. > >My concern is on the requirements in section 3.4 and maybe it's a >language issue where I am reading this differently than it was intended. >If that's the case, it would be good to make sure the text and intent is >clear. > >Current text: >Requirements: > > o YourHR must ensure that the personal information generated by the > local offices is timely available in a globally-accessible > database. > > o Identity management of the personal data must be protected against > unauthorised access and remain confidential to only authorised > parties. > > o All operation with identity data must be securely logged. > > o The logs should be available for auditing. > >My concern is with bullets 1 & 2. To me, this reads as though personal >information will be globally available and just the identity management >information is protected. What is meant by globally available and are >there some access restrictions? > >Sorry This was not in my review yesterday, I had a UI error. > See a separate email. > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Section 2.4 >I agree with Stephen's question on the assumption of using LDAP. If its' >just an example, could you say that or abstract it from LDAP or a >particular choice. The main idea is, ECS and CSP can provide service for CSU. We need something between ECS and CSP. I changed =A1=B0LDAP service=A1=B1 to =A1=B0information access service=A1=B1. > >Section 3.2 >I agree with Stephen (his comment on security considerations section) >that there should be some mention of regulatory concerns when moving >identity information between jurisdictional regions (countries, >state-by-state for regulations on privacy, and universities have >additional regulations on personal information). This also applies to >Section 3.4 (or likely all use cases) as personal information is >discussed in that use case description. For section 3.4, you'd need to >worry about where accounts are provisioned. I added this sentence in section 3.2 and 3.4: Regulatory requirements shall be met when migrating identity information between jurisdictional regions (countries, state-by-state for regulations on privacy). > >Nit: >Section 2.3.4 > At the protocol level, this class of scenarios may result in the use > of common protocol exchange patters between CSP-1 & CSP-2. >s/patters/patterns/ Changed, thanks!=20 From nobody Sat May 2 09:12:55 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0E1A1ABB; Sat, 2 May 2015 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKN9OeT4a9Lr; Sat, 2 May 2015 09:12:32 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0D53E1A0143; Sat, 2 May 2015 09:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430583150; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Ns73HTRtv4H/oj7pnR1EDBrEa1WBFORP4miF7lkWsX4=; b=SC/EN/lzxC6jOgOySLEeAH7aAqH9Paj9Ht+MN5GpaWwv3KJ5QYJYZpefqHV71y287Kc7fr/JeA293tVwJBZdj0HX1ls61x9dWZbreIaNDYgtPL0mQJXFeCxxDUR+4tpH5qJBT3SFfqR6AmA1P2GdqJ4qolg+gOFGg3qAX1QO9cY= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R771e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02010; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=7; RT=7; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 03 May 2015 00:12:26 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 03 May 2015 00:12:14 +0800 From: "Kepeng Li" To: Stephen Farrell , The IESG Message-ID: Thread-Topic: Stephen Farrell's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) References: <20150422154406.25657.29730.idtracker@ietfa.amsl.com> In-Reply-To: <20150422154406.25657.29730.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: scim@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, draft-ietf-scim-use-cases@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: Re: [scim] Stephen Farrell's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:12:38 -0000 Hi Stephen, Thanks for your review and comments. Please find my proposed changes below. Thanks, Kind Regards Kepeng =D4=DA 22/4/15 11:44 pm=A3=AC "Stephen Farrell" =D0=B4=C8=EB: >Stephen Farrell has entered the following ballot position for >draft-ietf-scim-use-cases-06: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- 2.1: "make ... easier" seems understated, presumably we >care about interop, security, scaling etc. and it'd actually >have been easier (in a sense) to just have everyone follow >one vendor or open-source thing. Changed it to this: The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud based applications and services in a standardized way to enable interoperability, security and scalability. > >- 2.1, "It's intent" - the It's is a little ambiguous. Changed it to this: The intent of SCIM specification ... > >- 2.2.1, last bullet: I don't get that. Are real-time things >even in charter I wonder? (CHECK) I removed =A1=B0real-time=A1=B1 in this paragraph. > >- 2.2.2, Better to use example.com, example.net than >FooBar.Inc etc unless there is a reason that the usual >examples do not work. I changed =A1=B0FooBar.Inc=A1=B1 to =A1=B0Example.com=A1=B1. >=20 >- 2.4, what is the impact for SCIM generally of "assuming" >use of LDAP here? If that's just an example, that's fine (but >it could be clarified), if it's more than that, then it'd be >good to know what exactly is meant. The main idea is, ECS and CSP can provide service for CSU. We need something between ECS and CSP. I changed =A1=B0LDAP service=A1=B1 to =A1=B0information access service=A1=B1. > >- 3.1, file permissions seem to me to be out of scope of >SCIM. Changing UIDs, UUIDs, or similar is in scope though but >this section doesn't make that clear. (Put another way: I am >correct that SCIM is not NFS, right? :-) Right, SCIM is not NFS. I removed this section. > >- 3.3, as per my comment on 3.1, this is unclear as to what >is in or out of scope of SCIM. "SSO" (Single-Sign On) use case is designed to capture a class of use case that makes sense to the actor requesting it rather than to describe a protocol operation. 2.3.4, 2.3.5 and 2.4.5 described that SSO can work as a trigger for the SCIM operations. The actual SSO processing is out of scope but as a trigger, I think it is fine to be listed as a use case. > >- 3.5 you say "selected attributes" a number of times. Don't >you need to say by whom and when? I added one sentence to say, web site B requires attributes from the user, And user selects some attributes. > >- 4: it'd be good if this explicitly called out that there >can be privacy issues here that go beyond transport security, >e.g. moving PII offshore between CSPs. I don't think you need >say more than that, but it'd be worth doing I think. I added the following sentence: There can be privacy issues that go beyond transport security, e.g. moving PII offshore between CSPs. Regulatory requirements shall be met when migrating identity information between jurisdictional regions (countries, state-by-state for regulations on privacy. From nobody Sat May 2 09:13:16 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB081A1ABB; Sat, 2 May 2015 09:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-0Nhr2TvOdn; Sat, 2 May 2015 09:12:56 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8E1A8A16; Sat, 2 May 2015 09:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430583171; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=cMn/jTCB8wk5AtUvIHafik8ikpm5vxE02akIsYLh3Qc=; b=Aa4enMpK0FrD4Ldghp7+TJQ1ttrOW7Ii+PfCMRqqo/QBw9v2ArEqTDX6iKVAxqBKqoSCWQPWMHm9TkBFdrhHajbC9j363S82hl8Cblv1aEk8rm4Mtaff+Cbspzfxsj+biaTZpubPJH+Tq+M8fQmOHLlD8xWWOK4t8oPtrM+hCDI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02011; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=9; RT=9; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 03 May 2015 00:12:49 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 03 May 2015 00:12:43 +0800 From: "Kepeng Li" To: Kathleen Moriarty , Phil Hunt Message-ID: Thread-Topic: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT) References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3513456769_1779492" Archived-At: Cc: "scim@ietf.org" , "draft-ietf-scim-use-cases.ad@ietf.org" , Leif Johansson , The IESG , "draft-ietf-scim-use-cases.shepherd@ietf.org" , "scim-chairs@ietf.org" , "draft-ietf-scim-use-cases@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:13:02 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3513456769_1779492 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hi Kathleen, >Although the second bullet covers security, it doesn't cover changing regulatory requirements for privacy based on location. The office might be= in a different country than the CSP. We can cover this in the first sentence. How about this: o Your HR must ensure that information generated by the local offices is provisioned securely and considers privacy requirements in a timely fashion across systems that may span technical (e.g., protocols and applications), administrative (e.g., corporate), regulatory (e.g. location) and jurisdictional domains. Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Kathleen Moriarty =C8=D5=C6=DA: Friday, 24 April, 2015 12:57 am =D6=C1: Phil Hunt =B3=AD=CB=CD: Leif Johansson , "draft-ietf-scim-use-cases.ad@ietf.org" , "scim@ietf.org" , The IESG , "draft-ietf-scim-use-cases.shepherd@ietf.org" , "scim-chairs@ietf.org" , "draft-ietf-scim-use-cases@ietf.org" =D6=F7=CC=E2: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT) Hi Phil, This looks good, but leaves out security and privacy considerations. How about a small addition (securely and considers privacy requirements), included in your first new bullet below? On Thu, Apr 23, 2015 at 12:17 PM, Phil Hunt wrote: > How about this=A1=AD >=20 > Old Text: > o YourHR must ensure that the personal information generated by the loca= l > offices is timely available in a globally-accessible database. >=20 > o Identity management of the personal data must be protected against > unauthorised access and remain confidential to only authorised parties. >=20 > New Text:=20 > o Your HR must ensure that information generated by the local offices is > provisioned securely and considers privacy requirements in a timely fashi= on > across systems that may span technical (e.g., protocols and applications)= , > administrative (e.g., corporate), and jurisdictional domains. >=20 > o Management of personal information must be protected against unauthori= zed > access, eavesdropping, and should be distributed only to authorized parti= es > and services. Although the second bullet covers security, it doesn't cover changing regulatory requirements for privacy based on location. The office might be in a different country than the CSP. Thanks, Kathleen=20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Apr 23, 2015, at 8:51 AM, Kathleen Moriarty >> wrote: >>=20 >>=20 >>=20 >> On Thu, Apr 23, 2015 at 11:49 AM, Phil Hunt wrote= : >>> Yes. Technically globally suggests scim is a db. Which is a sub case re= ally >>> (and not the current charter). >>>=20 >>> Better to say as a provisioning protocol, the issue (is better expresse= d) as >>> distribution personal info across domains: technically (eg protocols an= d >>> apps), administratively (eg controlling orgs), and jurisdictionally. >>=20 >> Could you propose some text and take a look at my response to Leif as we= ll, >> we sent at the same time. It would be good to get the privacy stuff in m= y >> comment addressed too and Im happy to assist with text if needed. >>=20 >> Thank you, >> Kathleen >>>=20 >>> Phil >>>=20 >>>> > On Apr 23, 2015, at 08:38, Leif Johansson wrote: >>>> > >>>> > >>>> > >>>>> >> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty >>>>> : >>>>> >> >>>>> >> Kathleen Moriarty has entered the following ballot position for >>>>> >> draft-ietf-scim-use-cases-06: Discuss >>>>> >> >>>>> >> When responding, please keep the subject line intact and reply to = all >>>>> >> email addresses included in the To and CC lines. (Feel free to cut= this >>>>> >> introductory paragraph, however.) >>>>> >> >>>>> >> >>>>> >> Please refer to >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> >> for more information about IESG DISCUSS and COMMENT positions. >>>>> >> >>>>> >> >>>>> >> The document, along with other ballot positions, can be found here= : >>>>> >> http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >>>>> >> >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------= ---- >>>>> >> DISCUSS: >>>>> >> ------------------------------------------------------------------= ---- >>>>> >> >>>>> >> I had a discuss on section 3.4, that should be quick to clear up o= n >>>>> >> privacy and security considerations. >>>>> >> >>>>> >> My concern is on the requirements in section 3.4 and maybe it's a >>>>> >> language issue where I am reading this differently than it was >>>>> intended. >>>>> >> If that's the case, it would be good to make sure the text and int= ent is >>>>> >> clear. >>>>> >> >>>>> >> Current text: >>>>> >> Requirements: >>>>> >> >>>>> >> o YourHR must ensure that the personal information generated by = the >>>>> >> local offices is timely available in a globally-accessible >>>>> >> database. >>>>> >> >>>>> >> o Identity management of the personal data must be protected aga= inst >>>>> >> unauthorised access and remain confidential to only authorised >>>>> >> parties. >>>>> >> >>>>> >> o All operation with identity data must be securely logged. >>>>> >> >>>>> >> o The logs should be available for auditing. >>>>> >> >>>>> >> My concern is with bullets 1 & 2. To me, this reads as though per= sonal >>>>> >> information will be globally available and just the identity manag= ement >>>>> >> information is protected. What is meant by globally available and= are >>>>> >> there some access restrictions? >>>> > >>>> > i think you are right - the word 'globally' should go away probably >>>> > >>>> > >>>>> >> >>>>> >> Sorry This was not in my review yesterday, I had a UI error. >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------= ---- >>>>> >> COMMENT: >>>>> >> ------------------------------------------------------------------= ---- >>>>> >> >>>>> >> Section 2.4 >>>>> >> I agree with Stephen's question on the assumption of using LDAP. = If >>>>> its' >>>>> >> just an example, could you say that or abstract it from LDAP or a >>>>> >> particular choice. >>>>> >> >>>>> >> Section 3.2 >>>>> >> I agree with Stephen (his comment on security considerations secti= on) >>>>> >> that there should be some mention of regulatory concerns when movi= ng >>>>> >> identity information between jurisdictional regions (countries, >>>>> >> state-by-state for regulations on privacy, and universities have >>>>> >> additional regulations on personal information). This also applie= s to >>>>> >> Section 3.4 (or likely all use cases) as personal information is >>>>> >> discussed in that use case description. For section 3.4, you'd ne= ed to >>>>> >> worry about where accounts are provisioned. >>>>> >> >>>>> >> Nit: >>>>> >> Section 2.3.4 >>>>> >> At the protocol level, this class of scenarios may result in the = use >>>>> >> of common protocol exchange patters between CSP-1 & CSP-2. >>>>> >> s/patters/patterns/ >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> scim mailing list >>>>> >> scim@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/scim >>>> > >>>> > _______________________________________________ >>>> > scim mailing list >>>> > scim@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 --=20 Best regards, Kathleen --B_3513456769_1779492 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi Kathleen,

>Although the second bulle= t covers security, it doesn't cover changing regulatory requirements for pri= vacy based on location.  The office might be in a different country tha= n the CSP.

We can cover this in the first sentenc= e. 

How about this:

o  Your HR must ensure that information generated by the local of= fices is provisioned securely and considers privacy requirements in a timely= fashion across systems that may span technical (e.g., protocols and applica= tions), administrative (e.g., corporate), <= b>regulatory (e.g. location) and jurisdictional domains.

Ki= nd Regards
Kepeng

=B7=A2=BC=FE=C8=CB: Kathleen Moriarty <= ;kathleen.moriarty.ietf@gm= ail.com>
=C8=D5=C6=DA: Friday, 24 A= pril, 2015 12:57 am
=D6=C1: Phil Hunt = <phil.hunt@oracle.com>
=B3=AD=CB=CD: Leif Johansson <leifj@mnt.se>, "draft-ietf-scim-use-cases.ad@ietf.org" <draft-ietf-scim-use-cases.ad@iet= f.org>, "scim@ietf.org" <scim@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-scim-use-cases.shepherd@ietf.org" &l= t;draft-ietf-sc= im-use-cases.shepherd@ietf.org>, "scim-chairs@ietf.org" <scim-= chairs@ietf.org>, "draft-ietf-scim-use-cases@ietf.org" <draft-ietf-scim-use-cases@ietf.org>
=D6=F7=CC=E2: Re: [scim] Kathleen Moriarty's Discuss = on draft-ietf-scim-use-cases-06: (with DISCUSS and COMMENT)
Hi Phil,

This looks good, but leav= es out security and privacy considerations.  How about a small addition= (securely and considers privacy r= equirements), included in your first new bullet below?

On Thu, Apr 23, 2015 at 12= :17 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
How about this…

Old Text:
o  YourHR must ensure that the personal informatio=
n generated by the local offices is timely available in a globally-accessibl=
e database.

o  Identity management of the personal data must be protected against unaut=
horised access and remain confidential to only authorised parties.

New Text: 
o  Your HR must ensure that information generated by the local off=
ices is provisioned securely and considers privacy requirements in a timely =
fashion across systems that may span technical (e.g., protocols and applicat=
ions), administrative (e.g., corporate), and jurisdictional domains.<=
/div>

o  Management of personal information must be protected against u=
nauthorized access, eavesdropping, and should be distributed only to authori=
zed parties and services.

Although the second bullet covers security, it doesn't cover changing= regulatory requirements for privacy based on location.  The office mig= ht be in a different country than the CSP.

Thanks,<= /div>
Kathleen 
<= div>


= On Apr 23, 2015, at 8:51 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



<= div class=3D"gmail_quote">On Thu, Apr 23, 2015 at 11:49 AM, Phil Hunt <phil.hunt@= oracle.com> wrote:
Yes. Technically globally sug= gests scim is a db. Which is a sub case really (and not the current charter)= .

Better to say as a provisioning protocol, the issue (is better expressed) a= s distribution personal info across domains: technically (eg protocols and a= pps), administratively (eg controlling orgs), and jurisdictionally.

Could you propose some text and take a look at m= y response to Leif as well, we sent at the same time. It would be good to ge= t the privacy stuff in my comment addressed too and Im happy to assist with = text if needed.

Thank you,
Kathleen
=

Phil

> On Apr 23, 2015, at 08:38, Leif Johansson <leifj@mnt.se> wrote:
>
>
>
>> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty <Kathleen.Moriarty.ietf@gma= il.com>:
>>
>> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-scim-use-cases-06: Discuss
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-= criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
= >>
>>
>> The document, along with other ballot positions, can be found here= :
>> http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases= /
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> DISCUSS:
>> ------------------------------------------------------------------= ----
>>
>> I had a discuss on section 3.4, that should be quick to clear up o= n
>> privacy and security considerations.
>>
>> My concern is on the requirements in section 3.4 and maybe it's a<= br> >> language issue where I am reading this differently than it was int= ended.
>> If that's the case, it would be good to make sure the text and int= ent is
>> clear.
>>
>> Current text:
>> Requirements:
>>
>>  o  YourHR must ensure that the personal information gen= erated by the
>>     local offices is timely available in a globally= -accessible
>>     database.
>>
>>  o  Identity management of the personal data must be pro= tected against
>>     unauthorised access and remain confidential to = only authorised
>>     parties.
>>
>>  o  All operation with identity data must be securely lo= gged.
>>
>>  o  The logs should be available for auditing.
>>
>> My concern is with bullets 1 & 2.  To me, this reads as t= hough personal
>> information will be globally available and just the identity manag= ement
>> information is protected.  What is meant by globally availabl= e and are
>> there some access restrictions?
>
> i think you are right - the word 'globally' should go away probably >
>
>>
>> Sorry This was not in my review yesterday, I had a UI error.
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> Section 2.4
>> I agree with Stephen's question on the assumption of using LDAP.&n= bsp; If its'
>> just an example, could you say that or abstract it from LDAP or a<= br> >> particular choice.
>>
>> Section 3.2
>> I agree with Stephen (his comment on security considerations secti= on)
>> that there should be some mention of regulatory concerns when movi= ng
>> identity information between jurisdictional regions (countries, >> state-by-state for regulations on privacy, and universities have >> additional regulations on personal information).  This also a= pplies to
>> Section 3.4 (or likely all use cases) as personal information is >> discussed in that use case description.  For section 3.4, you= 'd need to
>> worry about where accounts are provisioned.
>>
>> Nit:
>> Section 2.3.4
>>  At the protocol level, this class of scenarios may result in= the use
>>  of common protocol exchange patters between CSP-1 & CSP-= 2.
>> s/patters/patterns/
>>
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/scim



--

B= est regards,
Kathleen




--

= Best regards,
Kathleen
<= /body> --B_3513456769_1779492-- From nobody Sat May 2 09:23:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B91A1C04; Sat, 2 May 2015 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B4MmexU_S-Q; Sat, 2 May 2015 09:23:51 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id DE0DC1A1B6D; Sat, 2 May 2015 09:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430583829; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=CK4Uqarw08bmy9uq4bck9xTZE9/kMUf8XIXmdeYiRyo=; b=sh6aE2bnPViUy+2yQMyJSMq4A3Z8w+bmDDPUdeQF97ccV9sNDHhwNJ51pAarrZu7GNT+xQ332Let0TuGYRFoOf9W4EyVyjoGANNv+/PFjtm3Yy/u0iSYKeqGnzG6SaOk2urHIZr1r2SPWFa2XyXlsNspZbpbagQOZzrTBUGep2Q= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06005; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=6; RT=6; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 03 May 2015 00:23:47 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 03 May 2015 00:23:42 +0800 From: "Kepeng Li" To: Stephen Farrell , The IESG Message-ID: Thread-Topic: [scim] Stephen Farrell's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) References: <20150422154406.25657.29730.idtracker@ietfa.amsl.com> In-Reply-To: <20150422154406.25657.29730.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: scim@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: Re: [scim] Stephen Farrell's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:23:52 -0000 Hi Stephen, Thanks for your review and comments. Please find my proposed changes below. Thanks, Kind Regards Kepeng =D4=DA 22/4/15 11:44 pm=A3=AC "Stephen Farrell" =D0=B4=C8=EB: >Stephen Farrell has entered the following ballot position for >draft-ietf-scim-use-cases-06: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- 2.1: "make ... easier" seems understated, presumably we >care about interop, security, scaling etc. and it'd actually >have been easier (in a sense) to just have everyone follow >one vendor or open-source thing. Changed it to this: The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud based applications and services in a standardized way to enable interoperability, security and scalability. > >- 2.1, "It's intent" - the It's is a little ambiguous. Changed it to this: The intent of SCIM specification ... > >- 2.2.1, last bullet: I don't get that. Are real-time things >even in charter I wonder? (CHECK) I removed =A1=B0real-time=A1=B1 in this paragraph. > >- 2.2.2, Better to use example.com, example.net than >FooBar.Inc etc unless there is a reason that the usual >examples do not work. I changed =A1=B0FooBar.Inc=A1=B1 to =A1=B0Example.com=A1=B1. >- 2.4, what is the impact for SCIM generally of "assuming" >use of LDAP here? If that's just an example, that's fine (but >it could be clarified), if it's more than that, then it'd be >good to know what exactly is meant. The main idea is, ECS and CSP can provide service for CSU. We need something between ECS and CSP. I changed =A1=B0LDAP service=A1=B1 to =A1=B0information access service=A1=B1. > >- 3.1, file permissions seem to me to be out of scope of >SCIM. Changing UIDs, UUIDs, or similar is in scope though but >this section doesn't make that clear. (Put another way: I am >correct that SCIM is not NFS, right? :-) Right, SCIM is not NFS. I removed this section. > >- 3.3, as per my comment on 3.1, this is unclear as to what >is in or out of scope of SCIM. "SSO" (Single-Sign On) use case is designed to capture a class of use case that makes sense to the actor requesting it rather than to describe a protocol operation. 2.3.4, 2.3.5 and 2.4.5 described that SSO can work as a trigger for the SCIM operations. The actual SSO processing is out of scope but as a trigger, I think it is fine to be listed as a use case. > >- 3.5 you say "selected attributes" a number of times. Don't >you need to say by whom and when? I added one sentence to say, web site B requires attributes from the user, And user selects some attributes. > >- 4: it'd be good if this explicitly called out that there >can be privacy issues here that go beyond transport security, >e.g. moving PII offshore between CSPs. I don't think you need >say more than that, but it'd be worth doing I think. I added the following sentence: There can be privacy issues that go beyond transport security, e.g. moving PII offshore between CSPs. Regulatory requirements shall be met when migrating identity information between jurisdictional regions (countries, state-by-state for regulations on privacy. From nobody Sat May 2 09:36:14 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641C51A8A57; Sat, 2 May 2015 09:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxd0Q1CYJmry; Sat, 2 May 2015 09:36:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0161A8A4F; Sat, 2 May 2015 09:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150502163611.31734.22257.idtracker@ietfa.amsl.com> Date: Sat, 02 May 2015 09:36:11 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-07.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:36:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Definitions, Overview, Concepts and Requirements Authors : Kepeng LI Phil Hunt Bhumip Khasnabish Anthony Nadalin Zachary Zeltsan Filename : draft-ietf-scim-use-cases-07.txt Pages : 18 Date : 2015-05-02 Abstract: This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models and flows, and includes user scenarios, use cases, and requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-use-cases-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 2 09:43:15 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E911A1B23 for ; Sat, 2 May 2015 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1HuIDpdFDIx for ; Sat, 2 May 2015 09:43:13 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id BA98E1A038A for ; Sat, 2 May 2015 09:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430584992; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=vKpQ7VG6UIE43PeHlO4BKSRI4Z+XBZ7t6eZJTXTMx6w=; b=LIXCQ736ALyLOfgt0hzG/5kU1M9nD5+6ZZmhI9WUIlwW72Lzclng4uKJLZl/aERQEzQmCETAMeHQaMHoBKDig9HbEUiRpD2n6Eny+Wx+egsvGVo+58s8x0eBDGP+NPmk5dAZM9wonjQ84AZWjkYNHk2lJAHubwAzSkWfMvbBw7Y= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R921e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03020; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.61.82(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 03 May 2015 00:43:09 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 03 May 2015 00:43:07 +0800 From: "Kepeng Li" To: Barry Leiba , "scim@ietf.org" Message-ID: Thread-Topic: [scim] Status of use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:43:14 -0000 Hi Barry, Thanks for your reminder. >There's still a DISCUSS on the use-cases doc. What is the status of addressing that, as well as the non-blocking comments from IESG Evaluation? I just posted some resolutions to the review comments, and provided a new version: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-07 Hopefully we can close all the IESG comments. Kind Regards Kepeng =D4=DA 1/5/15 6:39 pm=A3=AC "Barry Leiba" =D0=B4=C8=EB: >There's still a DISCUSS on the use-cases doc. What is the status of >addressing that, as well as the non-blocking comments from IESG >evaluation? > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Mon May 4 16:04:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B91A8A12 for ; Mon, 4 May 2015 16:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxI7d3deYrtn for ; Mon, 4 May 2015 16:04:20 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BE61A8A09 for ; Mon, 4 May 2015 16:04:20 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t44N4ID0017701 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 May 2015 23:04:19 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t44N4HS8026401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2015 23:04:18 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t44N4HT8002477; Mon, 4 May 2015 23:04:17 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 May 2015 16:04:16 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2FFC91AC-A17B-4483-8328-EB0081B79A0D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Mon, 4 May 2015 16:04:14 -0700 Message-Id: <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Patrick Radtke , SCIM WG , Michael Frost Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 23:04:24 -0000 --Apple-Mail=_2FFC91AC-A17B-4483-8328-EB0081B79A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There are a couple of changes from the IESG review coming to core-schema = (for other reasons - emails to follow). With regards to this issue, I propose that the next update make = =E2=80=9Cmanager=E2=80=9D a multi-valued attribute so that it is = consistent with the examples and to correct the apparent inconsistency = in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Apr 30, 2015, at 1:50 PM, Kelly Grizzle = wrote: >=20 > It looks like this got changed back in October in revision 12 of the = core schema doc. > =20 > Draft 12 - PH - Nits / Corrections > =20 > ... > =20 > Corrected enterprise User manager attribute to use sub-attribute > value and make multi-valued > =20 > I hadn=E2=80=99t realized that this change went in. Up until then = manager had been single-valued since SCIM 1.0. If there is consensus = that this change should stay, then it seems like we need to update = section 4.3. > =20 > Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for the = =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, this = is consistent with the rest of the attribute definitions that are = references. I agree with you, Patrick, that these should be required. > =20 > --Kelly > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, April 30, 2015 2:21 PM > To: Michael Frost > Cc: Kelly Grizzle; Patrick Radtke; SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > =20 > Agreed. > =20 > Will need consensus/direction from the chairs on this and along with = the other issue (401/403/501 status code clarification). > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: > =20 > It is multi-valued in the example in 8.3 and in the schema on page 60, = and in our implementation. I think only the text in section 4.3 refers = to manager as singular. > =20 > -mrf > =20 > From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com = ]=20 > Sent: Thursday, April 30, 2015 10:28 AM > To: Phil Hunt > Cc: Patrick Radtke; SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > =20 > Does anyone have any strong opinions about making manager multi-valued = or leaving it as-is? >=20 > Either way we should probably clean up the text in section 4.3 and the = schema definition. > =20 > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 > Sent: Thursday, April 30, 2015 10:28 AM > To: Kelly Grizzle > Cc: Patrick Radtke; SCIM WG > Subject: Re: Manager attribute wording suggestion > =20 > I recall your comment and given lack of input at the time, it was = clear there was no consensus for change. I had to leave it as is despite = thinking it needed to be multi-valued.=20 >=20 > Phil >=20 > On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: >=20 > I had forgotten about that. The most discussion that I found was in = this email - = http://www.ietf.org/mail-archive/web/scim/current/msg02007.html = . > =20 > Note, the schema also needs to be updated. It looks like it should = be multi-valued > since many orgs have people with multiple reporting relationships. > =20 > I don=E2=80=99t remember ever discussing this any further or if we = achieved consensus on changing this. The email thread doesn=E2=80=99t = have any more discussion. > =20 > I=E2=80=99m not sure that I agree that this should be multivalued. If = anything else, I would never wish multiple managers upon anyone. ;) = Being serious, though, this might fit better as a second attribute that = describes other reporting relationships. > =20 > Anyone else remember this? > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 > Sent: Wednesday, April 29, 2015 6:41 PM > To: Kelly Grizzle > Cc: Patrick Radtke; SCIM WG > Subject: Re: Manager attribute wording suggestion > =20 > I believe I raised this issue before and the consensus was to leave = it. Maybe I am mistaken? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Apr 29, 2015, at 4:06 PM, Kelly Grizzle = > = wrote: > =20 > Patrick =E2=80=A6 thanks for the feedback. > =20 > I think that the schema section is incorrect. The $ref and value are = required and manager is still single valued. I think the text in 4.3 = should say: > =20 > manager > The user's manager. A complex type that optionally allows = service > providers to represent organizational hierarchy by referencing = the > "id" attribute of another User. > =20 > Phil, do you agree? > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org = ] On Behalf Of Patrick Radtke > Sent: Friday, April 24, 2015 5:47 PM > To: SCIM WG > Subject: [scim] Manager attribute wording suggestion > =20 > There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D attribute = that seem inconsistent. > =20 > In 4.3 Enterprise User Schema extension it says > "manager > The user's manager. A complex type that optionally allows = service > providers to represent organizational hierarchy by referencing = the > "id" attribute of another User. > =20 > value The "id" of the SCIM resource representing the user's > manager. RECOMMENDED. > =20 > $ref The URI of the SCIM resource representing the User's > manager. RECOMMENDED. > =E2=80=9C > To me that says that a user may have a single manager, and =E2=80=98valu= e=E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not required. > =20 > However in the Schema section, manager is listed as "multiValued: = true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80=9D and = =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D the = description attribute says each is required. > =20 > If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t = required, can the Manager schema description be adjusted? > Since manager is multi-valued, can section 4.3 be updated to say. "The = user's managers. A multi-valued complex type that=E2=80=A6=E2=80=9D = Otherwise, at first read (or for anyone coming from SCIM 1.1) it is not = obvious that it has become multi-valued. > =20 > Thanks, > =20 > Patrick > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = > =20 --Apple-Mail=_2FFC91AC-A17B-4483-8328-EB0081B79A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
There are a couple of changes from the IESG = review coming to core-schema (for other reasons - emails to = follow).

With = regards to this issue, I propose that the next update make =E2=80=9Cmanage= r=E2=80=9D a multi-valued attribute so that it is consistent with the = examples and to correct the apparent inconsistency in the = draft.

If = there are any strong objections, please respond and discuss.

Thanks,


On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

It looks like this got changed back in = October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / = Corrections

 

      ...

 

      Corrected enterprise User = manager attribute to use sub-attribute

      value and make = multi-valued

 

I hadn=E2=80=99t realized that this = change went in.  Up until then manager had been single-valued since = SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that =E2=80=9Crequired= =E2=80=9D is false for the =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80= =9D sub-attributes, this is consistent with the rest of the attribute = definitions that are references.  I agree with you, Patrick, that these should be = required.

 

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion

 

Agreed.

 

Will need consensus/direction = from the chairs on this and along with the other issue (401/403/501 = status code clarification).

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 30, 2015, at 11:42 AM, = Michael Frost <michael.frost@oracle.com> wrote:

 

It is multi-valued in the example in = 8.3 and in the schema on page 60, and in our implementation.  I = think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion

 

Does anyone have any strong opinions = about making manager multi-valued or leaving it as-is?


Either way we should probably clean up the text in section 4.3 and the = schema definition.

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion

 

I recall your comment and given = lack of input at the time, it was clear there was no consensus for = change. I had to leave it as is despite thinking it needed to be = multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I had forgotten about that.  The = most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html= .

 

   Note, the schema also = needs to be updated. It looks like it should be multi-valued

  since many orgs have people = with multiple reporting relationships.

 

I don=E2=80=99t remember ever = discussing this any further or if we achieved consensus on changing = this.  The email thread doesn=E2=80=99t have any more = discussion.

 

I=E2=80=99m not sure that I agree that = this should be multivalued.  If anything else, I would never wish = multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describes other reporting = relationships.

 

Anyone else remember this?

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion

 

I believe I raised this issue before and the = consensus was to leave it.  Maybe I am mistaken?

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 29, 2015, at 4:06 PM, = Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

 

Patrick =E2=80=A6 thanks for the = feedback.

 

I think that the schema section is = incorrect.  The $ref and value are required and manager is still = single valued.  I think the text in 4.3 should say:

 

manager

      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute =
of another User.

 

Phil, do you agree?

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording = suggestion

 

There are a couple aspects of the =E2=80=9Cmanager=E2=80= =9D attribute that seem inconsistent.

 

In 4.3 Enterprise User Schema extension it = says

"manager

      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute of another =
User.
 
      value  The "id" of the =
SCIM resource representing the user's
         =
manager.  RECOMMENDED.
 
      $ref  The URI of the SCIM =
resource representing the User's
         =
manager.  RECOMMENDED.

=E2=80=9C

To me that says that a user may have a single = manager, and =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 = attributes are not required.

 

However in the Schema section, manager is listed as = "multiValued: true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80= =9D and =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D = the description attribute says each is required.

 

If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D = aren=E2=80=99t required, can the Manager schema description be = adjusted?

Since manager is multi-valued, can section 4.3 be updated to = say. "The user's managers.  A multi-valued complex = type that=E2=80=A6=E2=80=9D  Otherwise, at first read (or for anyone = coming from SCIM 1.1) it is not obvious that it has become = multi-valued.

 

Thanks,

 

Patrick

 

 

 

 

 

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

 


= --Apple-Mail=_2FFC91AC-A17B-4483-8328-EB0081B79A0D-- From nobody Mon May 4 16:10:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EB61A8A4C for ; Mon, 4 May 2015 16:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i9AgF_Y4YZx for ; Mon, 4 May 2015 16:10:14 -0700 (PDT) Received: from heisenberg.jivesoftware.com (heisenberg.jivesoftware.com [204.93.66.11]) by ietfa.amsl.com (Postfix) with ESMTP id B9FDC1A8A39 for ; Mon, 4 May 2015 16:10:14 -0700 (PDT) X-ASG-Debug-ID: 1430781013-059a6d2704135f70001-bGWiwh Received: from mail.jiveland.com (phxcas01.corp.jiveland.com [10.81.2.11]) by heisenberg.jivesoftware.com with ESMTP id MSYeGI4QwHcCYOjq; Mon, 04 May 2015 16:10:13 -0700 (PDT) X-Barracuda-Envelope-From: patrick.radtke@jivesoftware.com Received: from MBX01.jiveland.com ([fe80::9982:7054:baaa:ab73]) by PHXCAS01.jiveland.com ([10.81.2.11]) with mapi id 14.03.0158.001; Mon, 4 May 2015 16:10:13 -0700 From: Patrick Radtke To: Phil Hunt , Kelly Grizzle Thread-Topic: [scim] Manager attribute wording suggestion X-ASG-Orig-Subj: Re: [scim] Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAB/ooCAAOrKAIAAHcCAgAAhm4CAABSbAIAACsEAgAAZKACABm6nAP//jFGA Date: Mon, 4 May 2015 23:10:12 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> In-Reply-To: <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.32.204] Content-Type: multipart/alternative; boundary="_000_D16D49D81789patrickradtkejivesoftwarecom_" MIME-Version: 1.0 X-Barracuda-Connect: phxcas01.corp.jiveland.com[10.81.2.11] X-Barracuda-Start-Time: 1430781013 X-Barracuda-URL: https://spamfirewall3.jiveland.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at jivesoftware.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -0.36 X-Barracuda-Spam-Status: No, SCORE=-0.36 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=HTML_MESSAGE, SARE_STILLSINGLE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18619 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.66 SARE_STILLSINGLE BODY: Contains phrasing used by spammers 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: SCIM WG , Michael Frost Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 23:10:19 -0000 --_000_D16D49D81789patrickradtkejivesoftwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Is it too late in the process to make the attribute name plural (=93manager= s=94)? All the other multiValued attributes I saw in core-schema use the pl= ural form for the attribute name. From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle > Cc: Michael Frost >, Jive IT >, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). With regards to this issue, I propose that the next update make =93manager= =94 a multi-valued attribute so that it is consistent with the examples and= to correct the apparent inconsistency in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: It looks like this got changed back in October in revision 12 of the core s= chema doc. Draft 12 - PH - Nits / Corrections ... Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued I hadn=92t realized that this change went in. Up until then manager had be= en single-valued since SCIM 1.0. If there is consensus that this change sh= ould stay, then it seems like we need to update section 4.3. Regarding the fact that =93required=94 is false for the =93value=94 and =93= $ref=94 sub-attributes, this is consistent with the rest of the attribute d= efinitions that are references. I agree with you, Patrick, that these shou= ld be required. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Agreed. Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. -mrf From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued. Phil On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. I don=92t remember ever discussing this any further or if we achieved conse= nsus on changing this. The email thread doesn=92t have any more discussion= . I=92m not sure that I agree that this should be multivalued. If anything e= lse, I would never wish multiple managers upon anyone. ;) Being serious, t= hough, this might fit better as a second attribute that describes other rep= orting relationships. Anyone else remember this? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: Patrick =85 thanks for the feedback. I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. Phil, do you agree? --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion There are a couple aspects of the =93manager=94 attribute that seem inconsi= stent. In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. =93 To me that says that a user may have a single manager, and =91value=92 and = =91$ref=92 attributes are not required. However in the Schema section, manager is listed as "multiValued: true=94 a= nd though subAttributes of =93$ref=94 and =93value=94 have =93required:fals= e=94 the description attribute says each is required. If =93value=94 and =93$ref=94 aren=92t required, can the Manager schema des= cription be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that=85=94 Otherwise, at first r= ead (or for anyone coming from SCIM 1.1) it is not obvious that it has beco= me multi-valued. Thanks, Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16D49D81789patrickradtkejivesoftwarecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6FD141B62D8A5945BF8E63C94F2410A6@jivesoftware.com> Content-Transfer-Encoding: quoted-printable
Is it too late in the process to make the attribute name plural (=93ma= nagers=94)? All the other multiValued attributes I saw in core-schema use t= he plural form for the attribute name.

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 P= M
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT &l= t;patrick.radtke@jivesof= tware.com>, SCIM WG <scim@ietf.o= rg>
Subject: Re: [scim] Manager attribu= te wording suggestion

There are a couple of changes from the IESG review coming t= o core-schema (for other reasons - emails to follow).

With regards to this issue, I propose that the next update = make =93manager=94 a multi-valued attribute so that it is consistent with t= he examples and to correct the apparent inconsistency in the draft.

If there are any strong objections, please respond and disc= uss.

Thanks,

Phil

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

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

It looks like this got c= hanged back in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 

      ...

 

      Corrected enterprise Use= r manager attribute to use sub-attribute

      value and make multi-val= ued

 

I hadn=92t realized that= this change went in.  Up until then manager had been single-valued si= nce SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that = =93required=94 is false for the =93value=94 and =93$ref=94 sub-attributes, = this is consistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that the= se should be required.

 

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= o:p class=3D"">

 

Agreed.

 

Will need consensus/direction from the chairs on thi= s and along with the other issue (401/403/501 status code clarification).

 

Phil

 

@independentid

www.independentid.com

phil.hunt@ora= cle.com

 

On Apr 30, 2015, at 11:42 AM, Michael Frost <michael.frost@oracle.com= > wrote:

 

It is multi-valued in th= e example in 8.3 and in the schema on page 60, and in our implementation.&n= bsp; I think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.grizzl= e@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

Does anyone have any str= ong opinions about making manager multi-valued or leaving it as-is?<= o:p class=3D"">


Either way we should probably clean up the text in section 4.3 and the sche= ma definition.

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= o:p class=3D"">

 

I recall your comment and given lack of input at the= time, it was clear there was no consensus for change. I had to leave it as= is despite thinking it needed to be multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I had forgotten about th= at.  The most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=

 

   Note, the schema also ne= eds to be updated. It looks like it should be multi-valued

  s= ince many orgs have people with multiple reporting relationships.

 

I don=92t remember ever = discussing this any further or if we achieved consensus on changing this.&n= bsp; The email thread doesn=92t have any more discussion.

 

I=92m not sure that I ag= ree that this should be multivalued.  If anything else, I would never = wish multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describe= s other reporting relationships.

 

Anyone else remember thi= s?

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= o:p class=3D"">

 

I believe I raised this issue before and the consens= us was to leave it.  Maybe I am mistaken?

 

Phil

 

@independentid

www.independentid.com

phil.hunt@ora= cle.com

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <kelly.grizzle@sailpoin= t.com> wrote:

 

Patrick =85 thanks for t= he feedback.

 

I think that the schema = section is incorrect.  The $ref and value are required and manager is = still single valued.  I think the text in 4.3 should say:

 

manager

    &nbs=
p; The user's manager.  A complex type that optionally allows service<=
/span>
      provide=
rs to represent organizational hierarchy by referencing the
    =
  "id" attribute of another User.<=
/pre>

 


Phil, do you agree?


 


--Kelly


 






From: scim [mailto:scim-bounces@ietf.org]
On Behalf Of Patrick Radtke

Sent: Friday, April 24, 2015 5:47 PM

To: SCIM WG

Subject: [scim] Manager attribute wording suggestion






 




There are a couple aspects of the =93manager=94=
 attribute that seem inconsistent.






 






In 4.3 Enterprise User Schema extension it says=







"manager<=
/o:p>




    &nbs=
p; The user's manager.  A complex type that optionally allows service<=
/span>


      provide=
rs to represent organizational hierarchy by referencing the


      "i=
d" attribute of another User.


 

      value&n=
bsp; The "id" of the SCIM resource representing the user's=



      &n=
bsp;  manager.  RECOMMENDED.


 

      $ref&nb=
sp; The URI of the SCIM resource representing the User's


      &n=
bsp;  manager.  RECOMMENDED.




=93






To me that says that a user may have a single m=
anager, and =91value=92 and =91$ref=92 attributes are not required.<=
o:p class=3D"">






 






However in the Schema section, manager is liste=
d as "multiValued: true=94 and though subAttributes of =93$ref=94 and =
=93value=94 have =93required:false=94 the description attribute
 says each is required.






 






If =93value=94 and =93$ref=94 aren=92t required=
, can the Manager schema description be adjusted?






Since manager is multi-valued, can section 4.3 be updated to say. =
"The user's managers.  A multi-valued
 complex type that=85=94  Otherwise, at first read (or for anyone comi=
ng from SCIM 1.1) it is not obvious that it has become multi-valued.=







 






Thanks,






 






Patrick






 






 






 






 

 

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

 


 --_000_D16D49D81789patrickradtkejivesoftwarecom_-- From nobody Tue May 5 09:55:04 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5D1A1AE8 for ; Tue, 5 May 2015 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Level: * X-Spam-Status: No, score=1.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at9jozYZy2w1 for ; Tue, 5 May 2015 09:54:57 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BDA1A1A6E for ; Tue, 5 May 2015 09:52:06 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 5 May 2015 18:52:04 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Tue, 5 May 2015 18:52:04 +0200 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: SCIM WG Thread-Topic: A short review of the password mgmt draft - Password Policy and the passwordState attribute Thread-Index: AQHQh1PPDVS4kH6sDk+a1gzvY+a6dg== Date: Tue, 5 May 2015 16:52:03 +0000 Message-ID: <35B03F44-EA7C-46DB-8C3C-2AA330283640@nexusgroup.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [94.234.170.158] Content-Type: text/plain; charset="utf-8" Content-ID: <64A705017C0C6446948C1CD7532384B9@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [scim] A short review of the password mgmt draft - Password Policy and the passwordState attribute X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:55:00 -0000 UmVhZCB0aHJvdWdoIHRoZSBkcmFmdC1odW50LXNjaW0tcGFzc3dvcmQtbWdtdCBkcmFmdCB0byBz ZWUgaG93IGl0IG1hdGNoZXMgb3VyIEFQSXMgZm9yIGl0IGNyZWRlbnRpYWwgbWFuYWdlbWVudC4g Rm91bmQgc29tZSBvcGVuIGlzc3VlcyB0aGF0IHdlIGNhbiB1c2UgZm9yIGRpc2N1c3Npb24gcG9p bnRzLg0KDQpCdXQgZmlyc3Qgb2YgYWxsLCB0aGFua3MgZm9yIHdvcmtpbmcgb24gdGhpcyENCg0K U3BsaXQgdGhpcyB1cCBpbnRvIHR3byBlbWFpbHMsIG9uZSByZWdhcmRpbmcg4oCccGFzc3dvcmRT dGF0ZeKAnSBhbmQgUGFzc3dvcmQgcG9saWNlcyAodGhpcyksIGFuZCBhbm90aGVyIG9uZSBhYm91 dCBNYW5hZ2VtZW50IHJlcXVlc3RzLg0KDQpJIHRoaW5rIHRoZSBtb3N0IGltcG9ydGFudCBwb2lu dCBpdCB0aGUgZm9sbG93aW5nLiBJIHRoaW5rIHdlIG11c3QgY3JlYXRlIGEgbGV2ZWwgb2YgYWJz dHJhY3Rpb24gb24gdG9wIG9mIHRoZSBwYXNzd29yZCBwb2xpY3kgdGhpcywgbWF5YmUgY2FsbGVk IOKAnENyZWRlbnRpYWwgUG9saWN54oCdIGFuZCBtYXliZSBhIGNyZWRlbnRpYWxTdGF0ZSBleHRl bnNpb24gYXR0cmlidXRlIGZvciBVc2VyL0dyb3VwIHRoYXQgY2FuIGhhdmUgMSB0byBtYW55IGRp ZmZlcmVudCB2YWx1ZXMgIGJhc2VkIG9uIGRpZmZlcmVudCBwb2xpY2llcyBib3VuZCB0byBpdC4g U29tZXRpbWVzIGl04oCZcyBhIG5vcm1hbCBwYXNzd29yZCBleHRlbnNpb24gYXR0cmlidXRlcyBm b3IgVXNlci9Hcm91cCBkZWZpbmVkIGluIHRoZSBzcGVjIGFuZCBzb21ldGltZSBpdOKAmXMgYW4g T0FUSCB0b2tlbiBQSU4gcG9saWN5IGFuZCBtYXliZSBpbmZvcm1hdGlvbiBvZiBhIHR3byBmYWN0 b3IgYXV0aGVudGljYXRpb24gc29mdGVuIGlzIGZ1bGx5IHByb3Zpc2lvbmVkIG9yIGlmIG9ubHkg YW4gYWN0aXZhdGlvbiBtZXNzYWdlIGlzIHNlbnQgdG8gdGhlIHVzZXIsIGJ1dCBpdOKAmXMgbm90 IHlldCB1c2VkIGFuZCBzbyBvbi4NCg0KSW4gb3VyIHR3byBmYWN0b3IgYXV0aGVudGljYXRpb24g c29mdHdhcmUgKHJhZGl1cywgc2FtbCwgb2F1dGgyLCBwbHVnaW4gaW50ZXJmYWNlIGFuZCBhIGJ1 bmNoIG9mIGRpZmZlcmVudCBtZXRob2RzLXRoaW5naWUpIGRpZmZlcmVudCB0eXBlcyBvZiBjcmVk ZW50aWFscyAoYXV0aGVudGljYXRpb24gbWV0aG9kcykgY2FuIGJlIGFzc2lnbmVkIHRvIGEgVXNl ci4gVGhhdCBtZWFucyB0aGF0IGEgdXNlciBjYW4gaGF2ZSBib3RoIHRoZSBuZVh1cyBQYXNzd29y ZCBtZXRob2QsIHRoYXTigJlzIGEgbm9ybWFsIHVzZXJuYW1lL3Bhc3N3b3JkIGJhc2VkIG1ldGhv ZC4gVXNlciBjYW4gYWxzbyBoYXZlIG5lWHVzIE1vYmlsZSBUZXh0IHRoYXTigJlzIGEgYSAyRkEg bWV0aG9kIHRoYXQgc2VuZHMgYW4gT1RQIHRocm91Z2ggU01TIGFuZCBhbiBPQVRIIGJhc2VkIDJG QSBiYXNlZCB0b2tlbiB3aXRoIGEgUElOIGFzc2lnbmVkIHRvIHRoZSBzYW1lIFVzZXIuDQoNCkRp ZmZlcmVudCBwb2xpY2llcyBhcmUgY29uZmlndXJlZCBmb3IgYWxsIHRoZSBkaWZmZXJlbnQgYXV0 aGVudGljYXRpb24gbWV0aG9kcyAobWF0Y2hlcyB0aGUgUGFzc3dvcmQgUG9saWN5IGRlZmluZWQg aW4gdGhlIGRyYWZ0KS4gVGhlIHVzZXJuYW1lL3Bhc3N3b3JkIGJhc2VkIG1ldGhvZHMgbGFyZ2Vs eSBtYXRjaGVzIHRoZSBwYXNzd29yZCBwb2xpY3kgaW4gdGhlIHNwZWMsIGJ1dCBob3cgdG8gZGVm aW5lIGEgUElOIGFuZCBjb25maWd1cmUgaWYgYSB1c2VybmFtZS9wYXNzd29yZCtvdHAgc2hvdWxk IGJlIGVudGVyZWQgaW4gb25lIG9yIHR3byBzdGVwcyBjYW7igJl0IGJlIGFkZGVkIHdpdGggdGhl IGhlbHAgb2YgdGhpcyBkcmFmdC4gWW91IGFsc28gd291bGQgbGlrZSB0byBkZWZpbmUgcGFzc3dv cmQgcG9saWNpZXMgb24gaW5kaXZpZHVhbCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLCB1c2VycyBh bmQgZ3JvdXBzIGRlcGVuZGluZyBvbiB0aGUgc2V0dXAuDQoNCkRpZCBhIHF1aWNrIG1hcHBpbmcg b2YgdGhlIGF0dHJpYnV0ZXMgYWdhaW5zdCBvdXIgQVBJcy4NCuKAlOKAlOKAlOKAlOKAlA0KDQpJ biBvdXIgSUFNIHN5c3RlbSBjYWxsZWQgbmVYdXMgSHlicmlkIEFjY2VzcyBHYXRld2F5LCB0aGUg bnVtYmVyIG9mIHJldHJpZXMgaXMgbm90IGJhc2VkIG9uIG9uZSBvZiB0aGUgYXV0aGVudGljYXRp b24gbWV0aG9kcywgYnV0IGl04oCZcyBhIGNvbWJpbmF0aW9uIG9mIGFsbCB0aGUgZGlmZmVyZW50 IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgKHVwIG9uIENyZWRlbnRpYWwgUG9saWN5IGxldmVsPyku DQoNCuKAlOKAlOKAlOKAlOKAlA0KDQpBbHNvIG1pc3Npbmcg4oCcVXNlIHBhc3N3b3JkIGZyb20g ZGlyZWN0b3J5IHNlcnZpY2Vz4oCdLiBJZiBhbiBhY2NvdW50IGlzIGJvdW5kIHRvIGEgZGlyZWN0 b3J5IHNlcnZpY2UgKEFELCBMREFQLCBEQuKApikgaXQgY2FuIHVzZSB0aGF0IHBhc3N3b3JkIGlu c3RlYWQgb2YgYSBidWlsdCBpbiBvbmUgaW4gdGhlIHN5c3RlbS4gSXTigJlzIHVwIHRvIHRoZSBh ZG1pbmlzdHJhdG9yIHRvIHNlbGVjdCB3aGF0IHBhc3N3b3JkIHNob3VsZCBiZSBlbmFibGVkIChw ZXIgYXV0aGVudGljYXRpb24gbWV0aG9kKSBmb3IgYSB1c2VyLiBBIHBhc3N3b3JkIHJlc2V0IG1l dGhvZCBhbHNvIHJlc2V0cyB0aGUgQUQgcGFzc3dvcmQgaWYgaXTigJlzIGNoZWNrZWQgaW5zdGVh ZCBvZiBhIGxvY2FsIHBhc3N3b3JkIGluIHRoZSBJQU0gc3lzdGVtLg0KDQrigJTigJTigJTigJQN Cg0KRXhhbXBsZSBvZiBtaXNzaW5nIGF0dHJpYnV0ZXMgb24gdGhlIHBhc3N3b3JkIHNjaGVtYSBm b3IgdXNlIGJ5IGRpZmZlcmVudCB0eXBlcyBvZiAyRkEgYXV0aGVudGljYXRpb24gbWV0aG9kcy4g Rm9yIGV4YW1wbGUgc29tZXRpbWVzIHlvdSB3b3VsZCBsaWtlIHRvIGFjdGl2YXRlIGEgMkZBIHRv a2VuIGFuZCBzZW5kIG91dCBhIHByb3Zpc2lvbmluZyBsaW5rIHRvIHRoZSBlbmQgdXNlciB0aGF0 4oCZcyB1c2VkIHRvIGVzdGFibGlzaCBzZWVkcyB1c2VkIGZvciBPQVRIIGNhbGN1bGF0aW9ucy4g VGhhdOKAmXMgc2V0IG9uIGEgcGFzc3dvcmQgcG9saWN5IHNheWluZyDigJxTZWxlY3QgdG8gKHJl KWFjdGl2YXRlIHNvZnR0b2tlbiBieSBzZWVk4oCdIG9yIOKAnFNlbGVjdCB0byAocmUpYWN0aXZh dGUgc29mdCB0b2tlbiBieSBhY3RpdmF0aW9uIGNvZGXigJ0uDQoNClNvbWUgd2ViIChodG1sK2pz KSBiYXNlZCAyRkEgYmFzZWQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBjYW4gYWxzbyBiZSBwcm92 aXNpb25lZCB1c2luZyAyRkEgYXV0b21hdGljYWxseSBmb3Igc3BlY2lmaWMgdXNlcnMgKHRoYXTi gJlzIHVzdWFsbHkgbm9uIHRlY2huaWNhbCBwZW9wbGUgd2l0aCB0aGUgcG93ZXIgdG8gb3ZlcnJp ZGUgc2VjdXJpdHkgcG9saWNpZXMpIGNhbGxlZCDigJxhdXRvbWF0aWNhbGx5IGFjdGl2YXRlIG9u IGZpcnN0IGxvZ29u4oCdLiBEb27igJl0IHNlZSBob3cgdGhhdCBjb3VsZCBiZSBpbXBsZW1lbnRl ZCBlaXRoZXIuDQoNCklmIGl04oCZcyBhbiBhdXRoZW50aWNhdGlvbiBtZXRob2QgdGhhdCBzZW5k cyBPVFA6cyBpbiBzb21lIGZvcm0gKHBhcGVyLCBzbXMsIGVtYWls4oCmKSB0aGVuIHRoZSBsZW5n dGggb2YgdGhlIE9UUCBzaG91bGQgYWxzbyBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgb24gdGhl IG1ldGhvZC4gIk9UUCBsZW5ndGjigJ0uIEl04oCZcyBhbHNvIGJ1bmRsZWQgd2l0aCAiR2VuZXJh dGUgQWN0aXZhdGlvbiBDb2RlIGZyb23igJ0gdGhhdCBjb250YWlucyBhIGxpc3Qgb2YgY2hhcnMg dGhhdOKAmXMgdXNlZCB0byBnZW5lcmF0ZSB0aGUgT1RQIChwcmVmZXJhYmxlIGEgbG9uZyBsaXN0 KS4gQnV0IGFsc28gYW4gaW5kaXZpZHVhbCAiTm90aWZpY2F0aW9uIE1lc3NhZ2XigJ0uIFNvbWV0 aW1lcyB0aGUgbWVzc2FnZSBzaG91bGQgYWxzbyBiZSBzZW50IHRvIGFub3RoZXIgcGVyc29uIChh IGJvc3MgdGhhdCBoZWxwcyBhIHVzZXIgb3V0IG9mIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBzeXN0 ZW0sIHRoZW4gYW5vdGhlciBub3RpZmljYXRpb24gbWVzc2FnZSBmb3Igb3RoZXIgcGVyc29ucyBz aG91bGQgYWxzbyBiZSBkZWZpbmVkICh3aXRoIHJlcGxhY2VtZW50cyB7MH0gYW5kIHsxfSBmb3Ig dXNlcm5hbWVzIGFuZCBPVFBzLg0KDQpBIHZpcnR1YWwga2V5IGJvYXJkIChpbiBKUyBvciBhcHBs ZXQpIGNhbiBhbHNvIGJlIGNvbmZpZ3VyZWQgaW4gdGhlIHBvbGljeSB0byBoYXZlIGVpdGhlciBy YW5kb20ga2V5Ym9hcmRzIG9yIGluIG51bWVyaWNhbCBvcmRlci4NCg0KT0FUSCBiYXNlZCBtZXRo b2RzIChUT1RQL0hPVFAvT0NSQSkgaGF2ZSBvZmZzZXRzIGFuZCBhY2NlcHQgd2luZG93cy4gDQoN CuKAlOKAlOKAlOKAlOKAlOKAlOKAlA0KDQrigJxyZXNldEF0dGVtcHRz4oCdLCBzaG91bGQgYmUg YSBnbG9iYWwgdmFsdWUgZm9yIHRoZSBDcmVkZW50aWFsIFBvbGljeSBhbGwgYXV0aGVudGljYXRp b24gbWV0aG9kcywgYW5kIG5vdCBib3VuZCB0byBvbmUgc3BlY2lmaWMgcGFzc3dvcmQuDQoNCuKA lOKAlOKAlOKAlOKAlOKAlOKAlA0KDQrigJxjaGFsbGVuZ2Vz4oCdIGlzIG5vdCB1c2VkIGFsbCwg Y29uY2VwdCBpcyB0byBmcmFnaWxlLiBJIHdvdWxkIHJlY29tbWVuZCBtZW50aW9uaW5nIHRoaXMg aW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zLg0KDQrigJTigJTigJTigJTi gJQNCg0KRGlkIG5vdCByZWFsbHkgZ2V0IHRoZSDigJxwYXNzd29yZEhpc3RvcnnigJ0gYXR0cmli dXRlLCBhdCBsZWFzdCBub3QgdGhlIHBvbGljeS5wYXNzd29yZEhpc3RvcnlTaXplIHRoaW5naWUu DQoNCuKAlOKAlOKAlOKAlOKAlOKAlA0KDQrigJxtaW5TcGVjaWFsQ2hhcnPigJ0gaXMgbm90IHVz ZWQgaW4gdGhlIHN5c3RlbSwgYnV0IG9uIHRoZSBvdGhlciBoYW5kICJEaXNhbGxvd2VkIGNoYXJh Y3RlcnMiIGlzLiBTb21ldGltZXMgdGhlIGNoYXJzIOKAmDEnIGFuZCDigJhsJyBpcyB0b28gY2xv c2UgdG8gZWFjaCBvdGhlciBhbmQgdGhlbiBhIGxpc3Qgb2YgZGlzYWxsb3dlZCBjaGFycyBjYW4g YmUgYWRkZWQuIEVzcGVjaWFsbHkgd2hlbiBhIHBhc3N3b3JkIGlzIGluaXRpYWxseSBnZW5lcmF0 ZWQgaW4gdGhlIHN5c3RlbSBhbmQgc2VudCB0byBhIHVzZXIgdGhyb3VnaCBzb21lIHNlY29uZCBj aGFubmVsIChzbXMgYW5kIHNvIGZvcnRoKS4NCg0K4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQoNCg0K LyBFcmlrDQoNCg== From nobody Tue May 5 09:55:06 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029811A1A6E for ; Tue, 5 May 2015 09:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zykPwYkv6JVO for ; Tue, 5 May 2015 09:54:58 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145E21A1B05 for ; Tue, 5 May 2015 09:52:08 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 5 May 2015 18:52:06 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Tue, 5 May 2015 18:52:06 +0200 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: SCIM WG Thread-Topic: A short review of the password mgmt draft - Management requests Thread-Index: AQHQh1PRhSt2ES90TU2UMnIPqqAxGA== Date: Tue, 5 May 2015 16:52:05 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [94.234.170.158] Content-Type: multipart/alternative; boundary="_000_E3DAA0426CAD465F9740D00D3008C6AAnexusgroupcom_" MIME-Version: 1.0 Archived-At: Subject: [scim] A short review of the password mgmt draft - Management requests X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:55:00 -0000 --_000_E3DAA0426CAD465F9740D00D3008C6AAnexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2Vjb25kIGVtYWlsIGluIHRoZSB2ZXJ5IGV4aXRpbmcgc2VyaWVzIG9mIEVyaWsgcmVhZGluZyB0 aHJvdWdoIHRoZSBwYXNzd29yZCBtZ210IGRyYWZ0IDopDQrigJTigJTigJTigJQNCg0KUGFzc3dv cmQgcmVzZXQgZmxvdyBhcmUgc3VwZXIgc2NhcnkuIEJ1dCBJIGd1ZXNzIHRoZSBtb3N0IGNvbW1v biB3YXkgZm9yIHVzIHRvIHJlc2V0IHBhc3N3b3JkIGlzIHVzaW5nLCBieSBkZXZpY2UgcG9saWNp ZXMsIGEgUElOIHByb3RlY3RlZCBwaG9uZS4gVGhpcyBtZWFucyB0aGF0IGFuIGFkbWluaXN0cmF0 b3IgaGF2ZSBwcmUtY29uZmlndXJlZCBhIHVzZXIgd2l0aCBhIHBob25lIG51bWJlciAob3IgaXTi gJlzIHJlYWQgZnJvbSBBRCkuIFRoaXMgY2FuIHRoZW4gYnkgdXNlZCBieSB0aGUgdXNlciB0byBn ZXQgb3V0IG9mIHRoZSBkcmVhZGVkIGNoYWxsZW5nZS9yZXNwb25zZSBmbG93cy4NCg0KQXMgbG9u ZyBhcyB5b3UgaGF2ZSBhIHBob25lIG51bWJlciwgeW91IGNhbiBhdCBsZWFzdCBoYXZlIHNvbWUg a2luZCBvZiBzZW1pLXNlY3VyZSBwYXNzd29yZCByZXNldCBmbG93LiBJIGd1ZXNzIHRoZSBmbG93 cyBsb29rcyBraW5kYSBsaWtlIHRoZSBzZWN0aW9uICIyLjQuMi4gIFJlc2V0IFdpdGggRW1haWwg Q29uZmlybWF0aW9u4oCdLCBidXQgSSBkb27igJl0IHJlYWxseSBnZXQgaG93IHRoYXQgd291bGQg d29yay4gQW4gT1RQIGlzIHNlbnQgdG8gdGhlIHVzZXIsIGhvdyBzaG91bGQgdGhhdCBsYXRlciBv biBiZSBzZW50IHRvIHRoZSBzZXJ2ZXIgYWdhaW4/IFdvdWxkIHRoYXQgYmUgYSBwcmUtY29uZmln dXJlZCB3YXkgYnkgdGhlIGNsaWVudCB0byB0aGVuIGF1dG9tYXRpY2FsbHkgc2VuZCBhIG5vcm1h bCAiMi40LjEuICBQYXNzd29yZCBSZXNldCBXaXRoIENoYWxsZW5nZXPigJ0gYnV0IHRoYXQgaXQg d291bGQgbG9vayBraW5kYSBsaWtlIHRoaXMgaW5zdGVhZDoNCg0KDQpQT1NUIC9QYXNzd29yZFJl c2V0UmVxdWVzdHMgIEhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5j b20+DQpBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24NCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v anNvbg0KQ29udGVudC1MZW5ndGg6IC4uLg0Kew0KICAgICJzY2hlbWFzIjoNCiAgICAgICAgWyJ1 cm46aWV0ZjpwYXJhbXM6c2NpbTpzY2hlbWFzOmNvcmU6Mi4wOnBhc3N3b3JkOlBhc3N3b3JkUmVz ZXRSZXF1ZXN0Il0sDQogICAgInVzZXJOYW1lIjoNCiAgICAgICAgImhhcHB5QWxpY2UiLA0KICAg ICJjaGFsbGVuZ2VzIjogWw0KICAgIHsNCiAgICAgICAgImNoYWxsZW5nZeKAnTrigJ1zbXMtb3Rw IiwNCiAgICAgICAgInJlc3BvbnNl4oCdOiIxMjNBQkMiDQogICAgfV0sDQogICAgInBhc3N3b3Jk IjogIjxuZXcgcGFzc3dvcmQ+Ig0KfQ0KDQoNCknigJltIG1pc3NpbmcgbW9yZSBhdHRyaWJ1dGVz IG9uIHRoZSBQYXNzd29yZFJlc2V0UmVxdWVzdCBmdW5jdGlvbmFsaXR5IGFsc28uIFNvbWV0aW1l cyBhIHVzZXIgaGF2ZSB0byBlbnRlciBib3RoLCB1c2VybmFtZSwgcGhvbmUgbnVtYmVyIGFuZCBl bWFpbCBhbmQgdGhleSBhbGwgaGF2ZSB0byBtYXRjaCBhZ2FpbnN0IGF0dHJpYnV0ZXMgb24gdGhl IFVzZXIgdG8gYmUgYWJsZSB0byBzZW5kIG91dCBhbiBlbWFpbCBvciBhbiBTTVMuIERvbuKAmXQg cmVhbGx5IHNlZSBob3cgdGhhdCB3b3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBjdXJyZW50IGRyYWZ0 4oCZLg0KDQrigJTigJTigJTigJQNCg0KUGFzc3dvcmRWYWxpZGF0ZVJlcXVlc3Qgd291bGQgbmVl ZCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgd2hhdCBwYXNzd29yZD8gSXMgaXQgZm9yIHRoZSBwYXNz d29yZCBiYXNlZCBtZXRob2Qgb3IgZm9yIHRoZSAyRkEgbWV0aG9kIChzZWUgb3RoZXIgZW1haWwp Pw0KDQrigJTigJQNCg0KRE9u4oCZdCBoYXZlIHRoZSByZXF1aXJlbWVudCwgYnV0IHdvdWxkIGJl IGludGVyZXN0aW5nIHRvIHNlZSBpZiBzbXMgY291bGQgYWxzbyBiZSBhIHBhcnQgb2YgYSBVc2Vy bmFtZVJlY292ZXJSZXF1ZXN0IHJlcXVlc3QuDQoNCuKAlOKAlOKAlA0KDQovIEVyaWsNCg0KDQoN Cg== --_000_E3DAA0426CAD465F9740D00D3008C6AAnexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: <644AC38F74BF76448CB7C7319D8F1DCE@nexusgroup.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KU2Vjb25kIGVtYWlsIGluIHRoZSB2 ZXJ5IGV4aXRpbmcgc2VyaWVzIG9mIEVyaWsgcmVhZGluZyB0aHJvdWdoIHRoZSZuYnNwO3Bhc3N3 b3JkIG1nbXQgZHJhZnQgOikNCjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCU4oCUPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QYXNzd29yZCBy ZXNldCBmbG93IGFyZSBzdXBlciBzY2FyeS4gQnV0IEkgZ3Vlc3MgdGhlIG1vc3QgY29tbW9uIHdh eSBmb3IgdXMgdG8gcmVzZXQgcGFzc3dvcmQgaXMgdXNpbmcsIGJ5IGRldmljZSBwb2xpY2llcywg YSBQSU4gcHJvdGVjdGVkIHBob25lLiBUaGlzIG1lYW5zIHRoYXQgYW4gYWRtaW5pc3RyYXRvciBo YXZlIHByZS1jb25maWd1cmVkIGEgdXNlciB3aXRoIGEgcGhvbmUgbnVtYmVyIChvciBpdOKAmXMg cmVhZCBmcm9tDQogQUQpLiBUaGlzIGNhbiB0aGVuIGJ5IHVzZWQgYnkgdGhlIHVzZXIgdG8gZ2V0 IG91dCBvZiB0aGUgZHJlYWRlZCBjaGFsbGVuZ2UvcmVzcG9uc2UgZmxvd3MuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcyBsb25nIGFz IHlvdSBoYXZlIGEgcGhvbmUgbnVtYmVyLCB5b3UgY2FuIGF0IGxlYXN0IGhhdmUgc29tZSBraW5k IG9mIHNlbWktc2VjdXJlIHBhc3N3b3JkIHJlc2V0IGZsb3cuIEkgZ3Vlc3MgdGhlIGZsb3dzIGxv b2tzIGtpbmRhIGxpa2UgdGhlIHNlY3Rpb24gJnF1b3Q7Mi40LjIuICZuYnNwO1Jlc2V0IFdpdGgg RW1haWwgQ29uZmlybWF0aW9u4oCdLCBidXQgSSBkb27igJl0IHJlYWxseSBnZXQgaG93IHRoYXQg d291bGQgd29yay4gQW4gT1RQDQogaXMgc2VudCB0byB0aGUgdXNlciwgaG93IHNob3VsZCB0aGF0 IGxhdGVyIG9uIGJlIHNlbnQgdG8gdGhlIHNlcnZlciBhZ2Fpbj8gV291bGQgdGhhdCBiZSBhIHBy ZS1jb25maWd1cmVkIHdheSBieSB0aGUgY2xpZW50IHRvIHRoZW4gYXV0b21hdGljYWxseSBzZW5k IGEgbm9ybWFsICZxdW90OzIuNC4xLiAmbmJzcDtQYXNzd29yZCBSZXNldCBXaXRoIENoYWxsZW5n ZXPigJ0gYnV0IHRoYXQgaXQgd291bGQgbG9vayBraW5kYSBsaWtlIHRoaXMgaW5zdGVhZDo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PHByZSBzdHlsZT0id2lkb3dzOiAxOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiIGNsYXNzPSIiPlBPU1QgL1Bhc3N3b3JkUmVzZXRSZXF1ZXN0cyAgSFRUUC8x LjENCkhvc3Q6IDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSIgY2xhc3M9IiI+ZXhhbXBsZS5j b208L2E+DQpBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24NCkNvbnRlbnQtVHlwZTogYXBwbGljYXRp b24vanNvbg0KQ29udGVudC1MZW5ndGg6IC4uLg0Kew0KICAgICZxdW90O3NjaGVtYXMmcXVvdDs6 DQogICAgICAgIFsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpzY2hlbWFzOmNvcmU6Mi4wOnBh c3N3b3JkOlBhc3N3b3JkUmVzZXRSZXF1ZXN0JnF1b3Q7XSwNCiAgICAmcXVvdDt1c2VyTmFtZSZx dW90OzoNCiAgICAgICAgJnF1b3Q7aGFwcHlBbGljZSZxdW90OywNCiAgICAmcXVvdDtjaGFsbGVu Z2VzJnF1b3Q7OiBbDQogICAgew0KICAgICAgICAmcXVvdDtjaGFsbGVuZ2XigJ064oCdc21zLW90 cCZxdW90OywNCiAgICAgICAgJnF1b3Q7cmVzcG9uc2XigJ06JnF1b3Q7MTIzQUJDJnF1b3Q7DQog ICAgfV0sDQogICAgJnF1b3Q7cGFzc3dvcmQmcXVvdDs6ICZxdW90OyZsdDtuZXcgcGFzc3dvcmQm Z3Q7JnF1b3Q7DQp9DQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBtaXNzaW5n IG1vcmUgYXR0cmlidXRlcyBvbiB0aGUmbmJzcDtQYXNzd29yZFJlc2V0UmVxdWVzdCBmdW5jdGlv bmFsaXR5IGFsc28uIFNvbWV0aW1lcyBhIHVzZXIgaGF2ZSB0byBlbnRlciBib3RoLCB1c2VybmFt ZSwgcGhvbmUgbnVtYmVyIGFuZCBlbWFpbCBhbmQgdGhleSBhbGwgaGF2ZSB0byBtYXRjaCBhZ2Fp bnN0IGF0dHJpYnV0ZXMgb24gdGhlIFVzZXIgdG8gYmUgYWJsZSB0byBzZW5kIG91dCBhbiBlbWFp bCBvciBhbiBTTVMuDQogRG9u4oCZdCByZWFsbHkgc2VlIGhvdyB0aGF0IHdvdWxkIGJlIGltcGxl bWVudGVkIGluIGN1cnJlbnQgZHJhZnTigJkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJTigJTigJTigJQ8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBhc3N3b3JkVmFsaWRh dGVSZXF1ZXN0IHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHdoYXQgcGFzc3dvcmQ/ IElzIGl0IGZvciB0aGUgcGFzc3dvcmQgYmFzZWQgbWV0aG9kIG9yIGZvciB0aGUgMkZBIG1ldGhv ZCAoc2VlIG90aGVyIGVtYWlsKT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RE9u4oCZdCBoYXZlIHRoZSByZXF1aXJlbWVu dCwgYnV0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHNlZSBpZiBzbXMgY291bGQgYWxzbyBiZSBh IHBhcnQgb2YgYSBVc2VybmFtZVJlY292ZXJSZXF1ZXN0IHJlcXVlc3QuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJTigJTigJQ8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8g RXJpazwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E3DAA0426CAD465F9740D00D3008C6AAnexusgroupcom_-- From nobody Tue May 5 10:13:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB101A877E for ; Tue, 5 May 2015 10:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce8V-t-jCAwp for ; Tue, 5 May 2015 10:13:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659281A87AC for ; Tue, 5 May 2015 10:13:17 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t45HDFuQ001087 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 May 2015 17:13:16 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t45HDEQa011599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2015 17:13:15 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t45HDE00007165; Tue, 5 May 2015 17:13:14 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2015 10:13:14 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0C29CE97-EFF9-412A-85C1-67D1F3451DF2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Tue, 5 May 2015 10:13:12 -0700 Message-Id: <9AE2B59D-E418-4DF4-BBF9-E838EDC69127@oracle.com> References: To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: SCIM WG Subject: Re: [scim] A short review of the password mgmt draft - Management requests X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:13:29 -0000 --Apple-Mail=_0C29CE97-EFF9-412A-85C1-67D1F3451DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erik Thanks for your comments. Re your previous email, I agree. The = higher-level notion of credentials and multi-factor policy make a lot of = sense. I think Tony echoed this in Hawaii. The password reset stuff bothers me the most. I think some more group = discussion (such as other factors/methodologies) would really help here. = The current draft really reflects common practice and not what I would = call =E2=80=9Cgood=E2=80=9D practice (in the absence of other security = measures). In addition to SMS, it would be nice to support strong-auth mechanisms = (e.g. from FIDO). Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 5, 2015, at 9:52 AM, Erik Wahlstr=C3=B6m neXus = wrote: >=20 > Second email in the very exiting series of Erik reading through the = password mgmt draft :) > =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > Password reset flow are super scary. But I guess the most common way = for us to reset password is using, by device policies, a PIN protected = phone. This means that an administrator have pre-configured a user with = a phone number (or it=E2=80=99s read from AD). This can then by used by = the user to get out of the dreaded challenge/response flows. >=20 > As long as you have a phone number, you can at least have some kind of = semi-secure password reset flow. I guess the flows looks kinda like the = section "2.4.2. Reset With Email Confirmation=E2=80=9D, but I don=E2=80=99= t really get how that would work. An OTP is sent to the user, how should = that later on be sent to the server again? Would that be a = pre-configured way by the client to then automatically send a normal = "2.4.1. Password Reset With Challenges=E2=80=9D but that it would look = kinda like this instead: >=20 > POST /PasswordResetRequests HTTP/1.1 > Host: example.com > Accept: application/json > Content-Type: application/json > Content-Length: ... > { > "schemas": > = ["urn:ietf:params:scim:schemas:core:2.0:password:PasswordResetRequest"], > "userName": > "happyAlice", > "challenges": [ > { > "challenge=E2=80=9D:=E2=80=9Dsms-otp", > "response=E2=80=9D:"123ABC" > }], > "password": "" > } > I=E2=80=99m missing more attributes on the PasswordResetRequest = functionality also. Sometimes a user have to enter both, username, phone = number and email and they all have to match against attributes on the = User to be able to send out an email or an SMS. Don=E2=80=99t really see = how that would be implemented in current draft=E2=80=99. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > PasswordValidateRequest would need to be able to specify what = password? Is it for the password based method or for the 2FA method (see = other email)? >=20 > =E2=80=94=E2=80=94 >=20 > DOn=E2=80=99t have the requirement, but would be interesting to see if = sms could also be a part of a UsernameRecoverRequest request. >=20 > =E2=80=94=E2=80=94=E2=80=94 >=20 > / Erik >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_0C29CE97-EFF9-412A-85C1-67D1F3451DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Erik

Thanks= for your comments.  Re your previous email, I agree.  The = higher-level notion of credentials and multi-factor policy make a lot of = sense. I think Tony echoed this in Hawaii.

The password reset stuff bothers me the = most. I think some more group discussion (such as other = factors/methodologies) would really help here.  The current draft = really reflects common practice and not what I would call =E2=80=9Cgood=E2= =80=9D practice (in the absence of other security measures).

In addition to SMS, it = would be nice to support strong-auth mechanisms (e.g. from = FIDO).


On May 5, 2015, at 9:52 AM, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrote:

Second email in the very exiting series of Erik reading through = the password mgmt draft :)
=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Password reset flow are super scary. But I guess the = most common way for us to reset password is using, by device policies, a = PIN protected phone. This means that an administrator have = pre-configured a user with a phone number (or it=E2=80=99s read from AD). This can then by used by the user to get out of the dreaded = challenge/response flows.

As long as you have a phone number, you can at least = have some kind of semi-secure password reset flow. I guess the flows = looks kinda like the section "2.4.2.  Reset With Email = Confirmation=E2=80=9D, but I don=E2=80=99t really get how that would = work. An OTP is sent to the user, how should that later on be sent to the server = again? Would that be a pre-configured way by the client to then = automatically send a normal "2.4.1.  Password Reset With = Challenges=E2=80=9D but that it would look kinda like this = instead:

POST /PasswordResetRequests  HTTP/1.1
Host: example.com
Accept: application/json
Content-Type: application/json
Content-Length: ...
{
    "schemas":
        =
["urn:ietf:params:scim:schemas:core:2.0:password:PasswordResetRequest"],
    "userName":
        "happyAlice",
    "challenges": [
    {
        "challenge=E2=80=9D:=E2=80=9Dsms-otp",
        "response=E2=80=9D:"123ABC"
    }],
    "password": "<new password>"
}
I=E2=80=99m missing more attributes on = the PasswordResetRequest functionality also. Sometimes a user have = to enter both, username, phone number and email and they all have to = match against attributes on the User to be able to send out an email or = an SMS. Don=E2=80=99t really see how that would be implemented in current = draft=E2=80=99.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94

PasswordValidateRequest would need to be able to specify = what password? Is it for the password based method or for the 2FA method = (see other email)?

=E2=80=94=E2=80=94

DOn=E2=80=99t have the requirement, but would be = interesting to see if sms could also be a part of a = UsernameRecoverRequest request.

=E2=80=94=E2=80=94=E2=80=94

/ Erik



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

= --Apple-Mail=_0C29CE97-EFF9-412A-85C1-67D1F3451DF2-- From nobody Tue May 5 10:26:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6741A700B for ; Tue, 5 May 2015 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQKuNx9k15QY for ; Tue, 5 May 2015 10:26:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6FA1A8879 for ; Tue, 5 May 2015 10:26:46 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t45HQj7c020223 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 5 May 2015 17:26:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t45HQj89014491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 May 2015 17:26:45 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t45HQi66004320 for ; Tue, 5 May 2015 17:26:44 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2015 10:26:44 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_E7F4FC2F-EF0F-4F4A-B5E0-32C3308D6F54" Message-Id: Date: Tue, 5 May 2015 10:26:43 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [scim] Clarification on authentication related status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:26:51 -0000 --Apple-Mail=_E7F4FC2F-EF0F-4F4A-B5E0-32C3308D6F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii During the IESG review process regarding authentication, I have been = asked to make some changes to the authentication section (the text of = which is to to be posted in another email).=20 While reviewing this, I (and a couple others) noticed that we may have = documented the HTTP status codes somewhat incorrectly. Particularly = HTTP Status code 403. I propose to correct section 3.12 as follows: CURRENT TEXT: > | 401 | GET, POST, | Authorization failure | > | UNAUTHORIZED | PUT, PATCH, | | > | | DELETE | | > | 403 | GET, POST, | Server does not support requested | > | FORBIDDEN | PUT, PATCH, | operation | NEW TEXT: | 401 | GET, POST, | Authorization failure. The author- | | UNAUTHORIZED | PUT, PATCH, | ization header is invalid/missing | | | DELETE | | | 403 | GET, POST, | Operation not permitted based on | | FORBIDDEN | PUT, PATCH, | the supplied authorization. | Note that anyone using 403 to indicate an unimplemented SCIM method = should be returning the 501 NOT IMPLEMENTED status. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_E7F4FC2F-EF0F-4F4A-B5E0-32C3308D6F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii During the IESG review process regarding authentication, I = have been asked to make some changes to the authentication section (the = text of which is to to be posted in another email). 

While reviewing this, I = (and a couple others) noticed that we may have documented the HTTP = status codes somewhat incorrectly.  Particularly HTTP Status code = 403.

I propose to = correct section 3.12 as follows:

CURRENT TEXT:
| 401          | GET, POST,    | =
Authorization failure              |
| UNAUTHORIZED | PUT, PATCH,   |                                    |
|              | DELETE        |                                    |
| 403          | GET, POST,    | Server does not support requested  |
| FORBIDDEN    | PUT, PATCH,   | operation                          |


NEW TEXT:
| 401          | =
GET, POST,    | Authorization failure. The author- |
| UNAUTHORIZED | PUT, PATCH,   | ization header is invalid/missing  |
|              | DELETE        |                                    |
| 403          | GET, POST,    | Operation not permitted based on   |
| FORBIDDEN    | PUT, PATCH,   | the supplied authorization.        |

Note that anyone using 403 to indicate = an unimplemented SCIM method should be returning the 501 NOT IMPLEMENTED = status.

Phil

= --Apple-Mail=_E7F4FC2F-EF0F-4F4A-B5E0-32C3308D6F54-- From nobody Tue May 5 14:15:01 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5781B29E4 for ; Tue, 5 May 2015 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-U5TvlLUaXR for ; Tue, 5 May 2015 14:14:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3171B29F0 for ; Tue, 5 May 2015 14:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46216; q=dns/txt; s=iport; t=1430860495; x=1432070095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6XLAAMMtKLOb8owUdtTl0bRtalNqlyxN8EnsDCHP26U=; b=FbhACZfj48lWjq4BpQBaIhiCEh2k6LZ4w9kGu9RauFLoKkf5fjNs+MKw qAqOZx8RcmqzedwOYyhaMw//EJhKqlQe8fa2PBD+8InksOx+g1G84LIPG TM7a4kYAEdPEE1jmo/v+RXNZ8CCOYA6H+3+gwMiUDgIoUs8/yN6NyVKjV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcBACEMUlV/51dJa1cgkVHU1wFxRpmCYEzGQEJhgUCgUA4FAEBAQEBAQGBCoQgAQEBBAEBASocJQQHEAIBCAcKAwEBASEBBgcnCxQJCAIEAQ0FCYgjDcR4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4o3gQKBT4JTEAIBPw0EBgEJhCQFiyCEToIvilaBJINWgnWHBYNog1MjgWWCD28BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,375,1427760000"; d="scan'208,217";a="147378401" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 05 May 2015 21:14:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t45LEq7l027938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 21:14:52 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.175]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 5 May 2015 16:14:52 -0500 From: "Morteza Ansari (moransar)" To: Patrick Radtke , Phil Hunt , Kelly Grizzle Thread-Topic: [scim] Manager attribute wording suggestion Thread-Index: AQHQg2sVZVjYkzoIEUeRKQK3UrtUk51mN7IAgAAKwQCAABkoAIAGbqcAgAABqwCAAPzAAA== Date: Tue, 5 May 2015 21:14:52 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.154.16.12] Content-Type: multipart/alternative; boundary="_000_D16E7F09123FF4moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG , Michael Frost Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:14:59 -0000 --_000_D16E7F09123FF4moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual =96 I am not aware of any IdM system that has mul= tivalued =93manager=94. In addition in many cases a multivalued manager bra= kes many applications as the reporting hierarchy is assumed to be a tree st= ructure with a one to many relationship not many to many. Unless someone ha= s a solid use case for turning this into a multivalued attribute, my vote a= s one of the implementors is to fix the example and leave it as single valu= ed. Cheers, Morteza From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM To: Phil Hunt >, Kelly Gr= izzle > Cc: "scim@ietf.org" >, Michael Frost > Subject: Re: [scim] Manager attribute wording suggestion Is it too late in the process to make the attribute name plural (=93manager= s=94)? All the other multiValued attributes I saw in core-schema use the pl= ural form for the attribute name. From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle > Cc: Michael Frost >, Jive IT >, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). With regards to this issue, I propose that the next update make =93manager= =94 a multi-valued attribute so that it is consistent with the examples and= to correct the apparent inconsistency in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: It looks like this got changed back in October in revision 12 of the core s= chema doc. Draft 12 - PH - Nits / Corrections ... Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued I hadn=92t realized that this change went in. Up until then manager had be= en single-valued since SCIM 1.0. If there is consensus that this change sh= ould stay, then it seems like we need to update section 4.3. Regarding the fact that =93required=94 is false for the =93value=94 and =93= $ref=94 sub-attributes, this is consistent with the rest of the attribute d= efinitions that are references. I agree with you, Patrick, that these shou= ld be required. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Agreed. Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. -mrf From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued. Phil On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. I don=92t remember ever discussing this any further or if we achieved conse= nsus on changing this. The email thread doesn=92t have any more discussion= . I=92m not sure that I agree that this should be multivalued. If anything e= lse, I would never wish multiple managers upon anyone. ;) Being serious, t= hough, this might fit better as a second attribute that describes other rep= orting relationships. Anyone else remember this? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: Patrick =85 thanks for the feedback. I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. Phil, do you agree? --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion There are a couple aspects of the =93manager=94 attribute that seem inconsi= stent. In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. =93 To me that says that a user may have a single manager, and =91value=92 and = =91$ref=92 attributes are not required. However in the Schema section, manager is listed as "multiValued: true=94 a= nd though subAttributes of =93$ref=94 and =93value=94 have =93required:fals= e=94 the description attribute says each is required. If =93value=94 and =93$ref=94 aren=92t required, can the Manager schema des= cription be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that=85=94 Otherwise, at first r= ead (or for anyone coming from SCIM 1.1) it is not obvious that it has beco= me multi-valued. Thanks, Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16E7F09123FF4moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Speaking as an individual =96 I am not aware of any IdM system that ha= s multivalued =93manager=94. In addition in many cases a multivalued manage= r brakes many applications as the reporting hierarchy is assumed to be a tr= ee structure with a one to many relationship not many to many. Unless someone has a solid use case for turning this int= o a multivalued attribute, my vote as one of the implementors is to fix the= example and leave it as single valued.


Cheers,
Morteza

From: Patrick Radtke <patrick.radtke@jivesoftware.com>
Date: Monday, May 4, 2015 at 4:10 P= M
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com&= gt;
Cc: "scim@ietf.org" <scim@i= etf.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re: [scim] Manager attribu= te wording suggestion

Is it too late in the process to make the attribute name plural (=93ma= nagers=94)? All the other multiValued attributes I saw in core-schema use t= he plural form for the attribute name.

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 P= M
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT &l= t;patrick.radtke@jivesof= tware.com>, SCIM WG <scim@ietf.o= rg>
Subject: Re: [scim] Manager attribu= te wording suggestion

There are a couple of changes from the IESG review coming t= o core-schema (for other reasons - emails to follow).

With regards to this issue, I propose that the next update = make =93manager=94 a multi-valued attribute so that it is consistent with t= he examples and to correct the apparent inconsistency in the draft.

If there are any strong objections, please respond and disc= uss.

Thanks,

Phil

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

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

It looks like this got c= hanged back in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 

      ...

 

      Corrected enterprise Use= r manager attribute to use sub-attribute

      value and make multi-val= ued

 

I hadn=92t realized that= this change went in.  Up until then manager had been single-valued si= nce SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that = =93required=94 is false for the =93value=94 and =93$ref=94 sub-attributes, = this is consistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that the= se should be required.

 

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= o:p class=3D"">

 

Agreed.

 

Will need consensus/direction from the chairs on thi= s and along with the other issue (401/403/501 status code clarification).

 

Phil

 

@independentid

www.independentid.com

phil.hunt@ora= cle.com

 

On Apr 30, 2015, at 11:42 AM, Michael Frost <michael.frost@oracle.com= > wrote:

 

It is multi-valued in th= e example in 8.3 and in the schema on page 60, and in our implementation.&n= bsp; I think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.grizzl= e@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

Does anyone have any str= ong opinions about making manager multi-valued or leaving it as-is?<= o:p class=3D"">


Either way we should probably clean up the text in section 4.3 and the sche= ma definition.

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= o:p class=3D"">

 

I recall your comment and given lack of input at the= time, it was clear there was no consensus for change. I had to leave it as= is despite thinking it needed to be multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I had forgotten about th= at.  The most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=

 

   Note, the schema also ne= eds to be updated. It looks like it should be multi-valued

  s= ince many orgs have people with multiple reporting relationships.

 

I don=92t remember ever = discussing this any further or if we achieved consensus on changing this.&n= bsp; The email thread doesn=92t have any more discussion.

 

I=92m not sure that I ag= ree that this should be multivalued.  If anything else, I would never = wish multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describe= s other reporting relationships.

 

Anyone else remember thi= s?

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= o:p class=3D"">

 

I believe I raised this issue before and the consens= us was to leave it.  Maybe I am mistaken?

 

Phil

 

@independentid

www.independentid.com

phil.hunt@ora= cle.com

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <kelly.grizzle@sailpoin= t.com> wrote:

 

Patrick =85 thanks for t= he feedback.

 

I think that the schema = section is incorrect.  The $ref and value are required and manager is = still single valued.  I think the text in 4.3 should say:

 

manager

    &nbs=
p; The user's manager.  A complex type that optionally allows service<=
/span>
      provide=
rs to represent organizational hierarchy by referencing the
    =
  "id" attribute of another User.<=
/pre>

 


Phil, do you agree?


 


--Kelly


 






From: scim [mailto:scim-bounces@ietf.org]
On Behalf Of Patrick Radtke

Sent: Friday, April 24, 2015 5:47 PM

To: SCIM WG

Subject: [scim] Manager attribute wording suggestion






 




There are a couple aspects of the =93manager=94=
 attribute that seem inconsistent.






 






In 4.3 Enterprise User Schema extension it says=







"manager<=
/o:p>




    &nbs=
p; The user's manager.  A complex type that optionally allows service<=
/span>


      provide=
rs to represent organizational hierarchy by referencing the


      "i=
d" attribute of another User.


 

      value&n=
bsp; The "id" of the SCIM resource representing the user's=



      &n=
bsp;  manager.  RECOMMENDED.


 

      $ref&nb=
sp; The URI of the SCIM resource representing the User's


      &n=
bsp;  manager.  RECOMMENDED.




=93






To me that says that a user may have a single m=
anager, and =91value=92 and =91$ref=92 attributes are not required.<=
o:p class=3D"">






 






However in the Schema section, manager is liste=
d as "multiValued: true=94 and though subAttributes of =93$ref=94 and =
=93value=94 have =93required:false=94 the description attribute
 says each is required.






 






If =93value=94 and =93$ref=94 aren=92t required=
, can the Manager schema description be adjusted?






Since manager is multi-valued, can section 4.3 be updated to say. =
"The user's managers.  A multi-valued
 complex type that=85=94  Otherwise, at first read (or for anyone comi=
ng from SCIM 1.1) it is not obvious that it has become multi-valued.=







 






Thanks,






 






Patrick






 






 






 






 

 

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

 


 --_000_D16E7F09123FF4moransarciscocom_-- From nobody Tue May 5 15:25:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E321B2A63 for ; Tue, 5 May 2015 15:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoRCSV0VpS68 for ; Tue, 5 May 2015 15:25:12 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1586D1B2A72 for ; Tue, 5 May 2015 15:24:47 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t45MOiHC002849 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 May 2015 22:24:45 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t45MOixF014535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2015 22:24:44 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t45MOiBP029587; Tue, 5 May 2015 22:24:44 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2015 15:24:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_21B1ABC4-7889-4F06-8F5D-64D6DC416507" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Tue, 5 May 2015 15:24:42 -0700 Message-Id: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> To: Morteza Ansari X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Patrick Radtke , SCIM WG , Michael Frost , Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:25:16 -0000 --Apple-Mail=_21B1ABC4-7889-4F06-8F5D-64D6DC416507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My understanding is that we do. Dotted line and multi-reporting = relationships are a reality for many enterprise organizations. At least = one (or more) of our implementations is multi-valued. This was also = raised to me as an issue. I think the reality is that we=92ll all run into enterprises wanting = multi-valued managers sooner or later. Having it multi-valued doesn=92t = mean you have to support multiple values. But the important thing is = that SCIM parsers will need to expect an array. Maybe we need a general note that parsers should accept a single value = JSON object even when an attribute is multi-valued (for any multi-valued = attribute). This would make the issue non-breaking for clients (who = think any attribute is single-valued). As for servers, it seems to me = we have a compatibility issue due to the spec inconsistency (while = definition is single-value, examples are multi-valued). That means = regardless of our decisions some servers will have to be updated. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) = wrote: >=20 > Speaking as an individual =96 I am not aware of any IdM system that = has multivalued =93manager=94. In addition in many cases a multivalued = manager brakes many applications as the reporting hierarchy is assumed = to be a tree structure with a one to many relationship not many to many. = Unless someone has a solid use case for turning this into a multivalued = attribute, my vote as one of the implementors is to fix the example and = leave it as single valued. >=20 >=20 > Cheers, > Morteza >=20 > From: Patrick Radtke > > Date: Monday, May 4, 2015 at 4:10 PM > To: Phil Hunt >, = Kelly Grizzle > > Cc: "scim@ietf.org " >, Michael Frost > > Subject: Re: [scim] Manager attribute wording suggestion >=20 > Is it too late in the process to make the attribute name plural = (=93managers=94)? All the other multiValued attributes I saw in = core-schema use the plural form for the attribute name. >=20 > From: Phil Hunt > > Date: Monday, May 4, 2015 at 4:04 PM > To: Kelly Grizzle > > Cc: Michael Frost >, Jive IT = >, SCIM WG > > Subject: Re: [scim] Manager attribute wording suggestion >=20 > There are a couple of changes from the IESG review coming to = core-schema (for other reasons - emails to follow). >=20 > With regards to this issue, I propose that the next update make = =93manager=94 a multi-valued attribute so that it is consistent with the = examples and to correct the apparent inconsistency in the draft. >=20 > If there are any strong objections, please respond and discuss. >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Apr 30, 2015, at 1:50 PM, Kelly Grizzle = > = wrote: >>=20 >> It looks like this got changed back in October in revision 12 of the = core schema doc. >> =20 >> Draft 12 - PH - Nits / Corrections >> =20 >> ... >> =20 >> Corrected enterprise User manager attribute to use = sub-attribute >> value and make multi-valued >> =20 >> I hadn=92t realized that this change went in. Up until then manager = had been single-valued since SCIM 1.0. If there is consensus that this = change should stay, then it seems like we need to update section 4.3. >> =20 >> Regarding the fact that =93required=94 is false for the =93value=94 = and =93$ref=94 sub-attributes, this is consistent with the rest of the = attribute definitions that are references. I agree with you, Patrick, = that these should be required. >> =20 >> --Kelly >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Thursday, April 30, 2015 2:21 PM >> To: Michael Frost >> Cc: Kelly Grizzle; Patrick Radtke; SCIM WG >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> Agreed. >> =20 >> Will need consensus/direction from the chairs on this and along with = the other issue (401/403/501 status code clarification). >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >>> On Apr 30, 2015, at 11:42 AM, Michael Frost = > wrote: >>> =20 >>> It is multi-valued in the example in 8.3 and in the schema on page = 60, and in our implementation. I think only the text in section 4.3 = refers to manager as singular. >>> =20 >>> -mrf >>> =20 >>> From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com = ]=20 >>> Sent: Thursday, April 30, 2015 10:28 AM >>> To: Phil Hunt >>> Cc: Patrick Radtke; SCIM WG >>> Subject: Re: [scim] Manager attribute wording suggestion >>> =20 >>> Does anyone have any strong opinions about making manager = multi-valued or leaving it as-is? >>>=20 >>> Either way we should probably clean up the text in section 4.3 and = the schema definition. >>> =20 >>> =20 >>> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >>> Sent: Thursday, April 30, 2015 10:28 AM >>> To: Kelly Grizzle >>> Cc: Patrick Radtke; SCIM WG >>> Subject: Re: Manager attribute wording suggestion >>> =20 >>> I recall your comment and given lack of input at the time, it was = clear there was no consensus for change. I had to leave it as is despite = thinking it needed to be multi-valued.=20 >>>=20 >>> Phil >>>=20 >>> On Apr 30, 2015, at 06:41, Kelly Grizzle = > = wrote: >>>=20 >>>> I had forgotten about that. The most discussion that I found was = in this email - = http://www.ietf.org/mail-archive/web/scim/current/msg02007.html = . >>>> =20 >>>> Note, the schema also needs to be updated. It looks like it = should be multi-valued >>>> since many orgs have people with multiple reporting = relationships. >>>> =20 >>>> I don=92t remember ever discussing this any further or if we = achieved consensus on changing this. The email thread doesn=92t have = any more discussion. >>>> =20 >>>> I=92m not sure that I agree that this should be multivalued. If = anything else, I would never wish multiple managers upon anyone. ;) = Being serious, though, this might fit better as a second attribute that = describes other reporting relationships. >>>> =20 >>>> Anyone else remember this? >>>> =20 >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >>>> Sent: Wednesday, April 29, 2015 6:41 PM >>>> To: Kelly Grizzle >>>> Cc: Patrick Radtke; SCIM WG >>>> Subject: Re: Manager attribute wording suggestion >>>> =20 >>>> I believe I raised this issue before and the consensus was to leave = it. Maybe I am mistaken? >>>> =20 >>>> Phil >>>> =20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> =20 >>>>> On Apr 29, 2015, at 4:06 PM, Kelly Grizzle = > = wrote: >>>>> =20 >>>>> Patrick =85 thanks for the feedback. >>>>> =20 >>>>> I think that the schema section is incorrect. The $ref and value = are required and manager is still single valued. I think the text in = 4.3 should say: >>>>> =20 >>>>> manager >>>>> The user's manager. A complex type that optionally allows = service >>>>> providers to represent organizational hierarchy by = referencing the >>>>> "id" attribute of another User. >>>>> =20 >>>>> Phil, do you agree? >>>>> =20 >>>>> --Kelly >>>>> =20 >>>>> From: scim [mailto:scim-bounces@ietf.org = ] On Behalf Of Patrick Radtke >>>>> Sent: Friday, April 24, 2015 5:47 PM >>>>> To: SCIM WG >>>>> Subject: [scim] Manager attribute wording suggestion >>>>> =20 >>>>> There are a couple aspects of the =93manager=94 attribute that = seem inconsistent. >>>>> =20 >>>>> In 4.3 Enterprise User Schema extension it says >>>>> "manager >>>>> The user's manager. A complex type that optionally allows = service >>>>> providers to represent organizational hierarchy by = referencing the >>>>> "id" attribute of another User. >>>>> =20 >>>>> value The "id" of the SCIM resource representing the user's >>>>> manager. RECOMMENDED. >>>>> =20 >>>>> $ref The URI of the SCIM resource representing the User's >>>>> manager. RECOMMENDED. >>>>> =93 >>>>> To me that says that a user may have a single manager, and =91value=92= and =91$ref=92 attributes are not required. >>>>> =20 >>>>> However in the Schema section, manager is listed as "multiValued: = true=94 and though subAttributes of =93$ref=94 and =93value=94 have = =93required:false=94 the description attribute says each is required. >>>>> =20 >>>>> If =93value=94 and =93$ref=94 aren=92t required, can the Manager = schema description be adjusted? >>>>> Since manager is multi-valued, can section 4.3 be updated to say. = "The user's managers. A multi-valued complex type that=85=94 = Otherwise, at first read (or for anyone coming from SCIM 1.1) it is not = obvious that it has become multi-valued. >>>>> =20 >>>>> Thanks, >>>>> =20 >>>>> Patrick >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>=20 >>>> =20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim = >> =20 >=20 --Apple-Mail=_21B1ABC4-7889-4F06-8F5D-64D6DC416507 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <As Individual>
My understanding is that = we do.  Dotted line and multi-reporting relationships are a reality = for many enterprise organizations.  At least one (or more) of our = implementations is multi-valued. This was also raised to me as an = issue.

<As Editor>
I think the reality is = that we=92ll all run into enterprises wanting multi-valued managers = sooner or later.  Having it multi-valued doesn=92t mean you have to = support multiple values.  But the important thing is that SCIM = parsers will need to expect an array.

Maybe we need a general = note that parsers should accept a single value JSON object even when an = attribute is multi-valued (for any multi-valued attribute). =  This would make the issue non-breaking for clients (who think any = attribute is single-valued).  As for servers, it seems to me we = have a compatibility issue due to the spec inconsistency (while = definition is single-value, examples are multi-valued). That means = regardless of our decisions some servers will have to be = updated.


On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) <moransar@cisco.com> = wrote:

Speaking as an individual =96 I am not aware of any IdM = system that has multivalued =93manager=94. In addition in many cases a = multivalued manager brakes many applications as the reporting hierarchy = is assumed to be a tree structure with a one to many relationship not many to many. Unless someone has a solid use case for turning this = into a multivalued attribute, my vote as one of the implementors is to = fix the example and leave it as single valued.


Cheers,
Morteza

From: Patrick Radtke = <patrick.radtke@jivesoftware.com>
Date: Monday, May 4, = 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>, Michael = Frost <michael.frost@oracle.com>
Subject: Re: [scim] = Manager attribute wording suggestion

Is it too late in the process to make the attribute name = plural (=93managers=94)? All the other multiValued attributes I saw in = core-schema use the plural form for the attribute name.

From: Phil Hunt = <phil.hunt@oracle.com>
Date: Monday, May 4, = 2015 at 4:04 PM
To: Kelly Grizzle = <kelly.grizzle@sailpoint.com>
Cc: Michael Frost = <michael.frost@oracle.com>, Jive IT <patrick.radtke@jivesoftware.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] = Manager attribute wording suggestion

There are a couple of changes from the IESG review = coming to core-schema (for other reasons - emails to follow).

With regards to this issue, I propose that the next = update make =93manager=94 a multi-valued attribute so that it is = consistent with the examples and to correct the apparent inconsistency = in the draft.

If there are any strong objections, please respond and = discuss.

Thanks,


On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

It looks like this got changed back in = October in revision 12 of the core schema doc.
 
   Draft 12 - PH - Nits / = Corrections
 
      ...
 
      Corrected enterprise User = manager attribute to use sub-attribute
      value and make = multi-valued
 
I hadn=92t realized that this change went = in.  Up until then manager had been single-valued since SCIM = 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3. =
 
Regarding the = fact that =93required=94 is false for the =93value=94 and =93$ref=94 = sub-attributes, this is consistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that = these should be required.
 
--Kelly
 
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion
 
Agreed.
 
Will need consensus/direction = from the chairs on this and along with the other issue (401/403/501 = status code clarification).
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Apr 30, 2015, at 11:42 AM, = Michael Frost <michael.frost@oracle.com> wrote:
 
It = is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation.  I think only the text in section 4.3 refers to manager as singular.
 
-mrf
 
From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion
 
Does anyone = have any strong opinions about making manager multi-valued or leaving it = as-is?

Either way we should probably clean up the text in section 4.3 and the = schema definition.
 
 
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion
 
I recall your comment and given = lack of input at the time, it was clear there was no consensus for = change. I had to leave it as is despite thinking it needed to be = multi-valued. 

Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I = had forgotten about that.  The most discussion that I found was in = this email - = http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.
 
   Note, the schema also = needs to be updated. It looks like it should be multi-valued
  since many orgs have people = with multiple reporting relationships.
 
I don=92t = remember ever discussing this any further or if we achieved consensus on = changing this.  The email thread doesn=92t have any more = discussion.
 
I=92m not sure = that I agree that this should be multivalued.  If anything else, I = would never wish multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that = describes other reporting relationships.
 
Anyone else = remember this?
 
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion
 
I believe I raised this issue before and the = consensus was to leave it.  Maybe I am mistaken?
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Apr 29, 2015, at 4:06 PM, = Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
 
Patrick =85 thanks for the feedback.
 
I think that = the schema section is incorrect.  The $ref and value are required = and manager is still single valued.  I think the text in 4.3 should say:
 
manager
      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute =
of=
 another User.
 
Phil, do you = agree?
 
--Kelly
 
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording = suggestion
 
There are a couple = aspects of the =93manager=94 attribute that seem = inconsistent.
 
In 4.3 Enterprise = User Schema extension it says
"manager
      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute of another =
User.
 
      value  The "id" of the =
SCIM resource representing the user's
         =
manager.  RECOMMENDED.
 
      $ref  The URI of the SCIM =
resource representing the User's
         =
manager.  RECOMMENDED.
=93
To me that says = that a user may have a single manager, and =91value=92 and =91$ref=92 = attributes are not required.
 
However in the = Schema section, manager is listed as "multiValued: true=94 and though = subAttributes of =93$ref=94 and =93value=94 have =93required:false=94 = the description attribute says each is required.
 
If =93value=94 and = =93$ref=94 aren=92t required, can the Manager schema description be = adjusted?
Since manager is multi-valued, can = section 4.3 be updated to say. "The user's managers. =  A multi-valued complex type that=85=94  Otherwise, at first read (or for anyone = coming from SCIM 1.1) it is not obvious that it has become = multi-valued.
 
Thanks,
 
Patrick
 
 
 
 
 
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
 

= --Apple-Mail=_21B1ABC4-7889-4F06-8F5D-64D6DC416507-- From nobody Tue May 5 21:16:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70A1B2AA2 for ; Tue, 5 May 2015 21:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQTqsdKBNam0 for ; Tue, 5 May 2015 21:16:30 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491D61B2A86 for ; Tue, 5 May 2015 21:16:30 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so143925266lbc.1 for ; Tue, 05 May 2015 21:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YxTFlru3FejGVsktyknZ1y2gzoHyDBlZN27rzLKEfR4=; b=lyrRTxsTPdpamtWtRWB4hoFSRwpYH9kYtrbpHFYXCAr8+DY4nsj133ITdPTuZnKfER eClx+GLVUMfiLv3Oyt49CrbffQ9JeltheeS9sn3Qsvyaua/DbYAVICh+DJFW1rZbEzAr l1Ng6CPh2BeRE0NuTuiSulPVIXYqMqcxuir2O6VnOPqWadXthQi8PXEJpTU8eUgTEier 8Y+KHMNDKA5ghLNee7xlNzGxEOHR6QqtkeRRwzU4CaclM617P/3xnGsVAPoX11u1VemY TDlWyjWLLIRNZf5RQR5eeDI1xQVOQMilon772W4wcACafPTgk70ZhhZatr8lvU6n797G nddQ== MIME-Version: 1.0 X-Received: by 10.152.7.97 with SMTP id i1mr26095095laa.49.1430885788819; Tue, 05 May 2015 21:16:28 -0700 (PDT) Received: by 10.114.175.133 with HTTP; Tue, 5 May 2015 21:16:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 May 2015 21:16:28 -0700 Message-ID: From: Craig McClanahan To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c27b7a2827fc0515620fee Archived-At: Cc: SCIM WG Subject: Re: [scim] Clarification on authentication related status codes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: craigmcc@gmail.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 04:16:32 -0000 --001a11c27b7a2827fc0515620fee Content-Type: text/plain; charset=UTF-8 Returning 501 for not-implemented functions makes total sense to me. Craig McClanahan On Tue, May 5, 2015 at 10:26 AM, Phil Hunt wrote: > During the IESG review process regarding authentication, I have been asked > to make some changes to the authentication section (the text of which is to > to be posted in another email). > > While reviewing this, I (and a couple others) noticed that we may have > documented the HTTP status codes somewhat incorrectly. Particularly HTTP > Status code 403. > > I propose to correct section 3.12 as follows: > > CURRENT TEXT: > > | 401 | GET, POST, | Authorization failure | > | UNAUTHORIZED | PUT, PATCH, | | > | | DELETE | | > | 403 | GET, POST, | Server does not support requested | > | FORBIDDEN | PUT, PATCH, | operation | > > > NEW TEXT: > > | 401 | GET, POST, | Authorization failure. The author- | > | UNAUTHORIZED | PUT, PATCH, | ization header is invalid/missing | > | | DELETE | | > | 403 | GET, POST, | Operation not permitted based on | > | FORBIDDEN | PUT, PATCH, | the supplied authorization. | > > > > Note that anyone using 403 to indicate an unimplemented SCIM method should > be returning the 501 NOT IMPLEMENTED status. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --001a11c27b7a2827fc0515620fee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Returning 501 for not-implemented functions makes total se= nse to me.

Craig McClanahan


On Tue, May 5, 2015= at 10:26 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
=
During t= he IESG review process regarding authentication, I have been asked to make = some changes to the authentication section (the text of which is to to be p= osted in another email).=C2=A0

While reviewing this, I (= and a couple others) noticed that we may have documented the HTTP status co= des somewhat incorrectly.=C2=A0 Particularly HTTP Status code 403.

=
I propose to correct section 3.12 as follows:

CURRENT TEXT:
| 401          | GET, POST,   =
 | Authorization failure              |
| UNAUTHORIZED | PUT, PATCH,   |                                    |
|              | DELETE        |                                    |
| 403          | GET, POST,    | Server does not support requested  |
| FORBIDDEN    | PUT, PATCH,   | operation                          |


NEW TEXT:
| 401   =
       | GET, POST,    | Authorization failure. The author- |
| UNAUTHORIZED | PUT, PATCH,   | ization header is invalid/missing  |
|              | DELETE        |                                    |
| 403          | GET, POST,    | Operation not permitted based on   |
| FORBIDDEN    | PUT, PATCH,   | the supplied authorization.        |


Note that anyone using= 403 to indicate an unimplemented SCIM method should be returning the 501 N= OT IMPLEMENTED status.

Phil

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


--001a11c27b7a2827fc0515620fee-- From nobody Wed May 6 02:20:21 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8E1A1A4A for ; Wed, 6 May 2015 02:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wChdBzSJDWW for ; Wed, 6 May 2015 02:20:18 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A011A1A42 for ; Wed, 6 May 2015 02:20:17 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so2958078lbc.1 for ; Wed, 06 May 2015 02:20:16 -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=eyuD9Fbkg7YCvL9BG5EPD/x4faiTX37NAxI2dl0PF9c=; b=pcuge++jfQjgyPbyaStQYNYf87Z5XQZyJOaTV0UR86TSpPFdkUO095DUOHJKW/wa3Q 6i3ZcpCZ4Fru+X/fcT/QchO3YucoUUkmvglXqxpPlqA7Eng81R7DBRc2Uh9GyD/+6ga3 kcGVbNcHzQlj4Kn3tgn9macb/HUeQsrSdgEZWcodguZ7qGhu33rYxxs4QKJGFPSJlxTk sdT7vovxA55whBNjtsI858yg/bXLddDM965f2pjK0ZKO08e/XASqB4W0MgpjtjMw7DxB PjeURWmc20nAIxbqgvVzublUYVxX3qe9dexfdDUZdCFubqQw65xbzQ9WDsqRJZ4ML3Dy FFog== MIME-Version: 1.0 X-Received: by 10.112.97.202 with SMTP id ec10mr25640571lbb.4.1430904016212; Wed, 06 May 2015 02:20:16 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Wed, 6 May 2015 02:20:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 May 2015 05:20:16 -0400 Message-ID: From: Kathleen Moriarty To: Kepeng Li Content-Type: multipart/alternative; boundary=001a1133b1c49819310515664d92 Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 09:20:20 -0000 --001a1133b1c49819310515664d92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the updates to the draft. It would be good to also see a statement in the security considerations section that includes leaving out data elements or obscuring them to protect users privacy. Privacy concerns aren't limited to regulations and this would help to make that point. Perhaps something like the following, after the third paragraph: Additionally, privacy sensitive data elements may be omitted or obscured in SCIM transactions or stored records to protect these data elements for a user. For instance a role based identifier might be used in place of an individual's name. Best regards, Kathleen On Sat, May 2, 2015 at 12:43 PM, Kepeng Li wrote: > Hi Barry, > > Thanks for your reminder. > > >There's still a DISCUSS on the use-cases doc. What is the status of > addressing that, as well as the non-blocking comments from IESG > Evaluation? > > I just posted some resolutions to the review comments, and provided a new > version: > https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-07 > > > Hopefully we can close all the IESG comments. > > > Kind Regards > Kepeng > > =E5=9C=A8 1/5/15 6:39 pm=EF=BC=8C "Barry Leiba" = =E5=86=99=E5=85=A5: > > >There's still a DISCUSS on the use-cases doc. What is the status of > >addressing that, as well as the non-blocking comments from IESG > >evaluation? > > > >Barry > > > >_______________________________________________ > >scim mailing list > >scim@ietf.org > >https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --=20 Best regards, Kathleen --001a1133b1c49819310515664d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the updates to the draft.=C2=A0 It would be = good to also see a statement in the security considerations section that in= cludes leaving out data elements or obscuring them to protect users privacy= .=C2=A0 Privacy concerns aren't limited to regulations and this would h= elp to make that point.=C2=A0 Perhaps something like the following, after t= he third paragraph:

Additionally, privacy sensitive data= elements may be omitted or obscured in SCIM transactions or stored records= to protect these data elements for a user.=C2=A0 For instance a role based= identifier might be used in place of an individual's name.
<= br>
Best regards,
Kathleen


On S= at, May 2, 2015 at 12:43 PM, Kepeng Li <kepeng.lkp@alibaba-inc.co= m> wrote:
Hi Barry,

Thanks for your reminder.

>There's still a DISCUSS on the use-cases doc.=C2=A0 What is the sta= tus of
addressing that, as well as the non-blocking comments from IESG
Evaluation?

I just posted some resolutions to the review comments, and provided a new version:
https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/<= /a>

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use= -cases-07


Hopefully we can close all the IESG comments.


Kind Regards
Kepeng

=E5=9C=A8 1/5/15 6:39 pm=EF=BC=8C "Barry Leiba" <barryleiba@computer.org> =E5=86=99=E5= =85=A5:

>There's still a DISCUSS on the use-cases doc.=C2=A0 What is the sta= tus of
>addressing that, as well as the non-blocking comments from IESG
>evaluation?
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>https://www.ietf.org/mailman/listinfo/scim


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



--
=

Best regards,
Kathleen
--001a1133b1c49819310515664d92-- From nobody Wed May 6 02:58:39 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C859A1A8756 for ; Wed, 6 May 2015 02:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjH2GYUk5CFP for ; Wed, 6 May 2015 02:58:36 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 141BC1A6EE6 for ; Wed, 6 May 2015 02:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430906315; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=DnFTbIkBR6u+mIHbFWwfYsYtTXhSbEQ2kQd1H506sKo=; b=hLxn4WA8yGMU9TXBweLIrzYKhhzzltYuqwwpeHIW0FLaeJR6RkjcR0Q4EJCQm+OJB7BIyUkP/390/O7XpWnUHbMkkGPKOUVIWyQB4n+zF9cRCzj1pIYeZ4pIQDrefYezSSI1uR0SUniygVddGFM4Ea4aD3F0bJGQz8gVmmhl7M8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R651e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06005; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.1.88.185(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.157) by smtp.aliyun-inc.com(127.0.0.1); Wed, 06 May 2015 17:58:33 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 06 May 2015 17:58:28 +0800 From: "Kepeng Li" To: Kathleen Moriarty Message-ID: Thread-Topic: [scim] Status of use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3513779913_3946593" Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 09:58:39 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3513779913_3946593 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable > Perhaps something like the following, after the third paragraph: > Additionally, privacy sensitive data elements may be omitted or obscured = in SCIM transactions or stored records to protect these data elements for a us= er. For instance a role based identifier might be used in place of an individua= l's name. OK, thank you! Will add to the draft. Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Kathleen Moriarty =C8=D5=C6=DA: Wednesday, 6 May, 2015 5:20 pm =D6=C1: Li Kepeng =B3=AD=CB=CD: Barry Leiba , "scim@ietf.org" =D6=F7=CC=E2: Re: [scim] Status of use-cases Thank you for the updates to the draft. It would be good to also see a statement in the security considerations section that includes leaving out data elements or obscuring them to protect users privacy. Privacy concerns aren't limited to regulations and this would help to make that point. Perhaps something like the following, after the third paragraph: Additionally, privacy sensitive data elements may be omitted or obscured in SCIM transactions or stored records to protect these data elements for a user. For instance a role based identifier might be used in place of an individual's name. Best regards, Kathleen On Sat, May 2, 2015 at 12:43 PM, Kepeng Li wrote: > Hi Barry, >=20 > Thanks for your reminder. >=20 >> >There's still a DISCUSS on the use-cases doc. What is the status of > addressing that, as well as the non-blocking comments from IESG > Evaluation? >=20 > I just posted some resolutions to the review comments, and provided a new > version: > https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >=20 > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-07 >=20 >=20 > Hopefully we can close all the IESG comments. >=20 >=20 > Kind Regards > Kepeng >=20 > =D4=DA 1/5/15 6:39 pm=A3=AC "Barry Leiba" =D0=B4=C8=EB: >=20 >> >There's still a DISCUSS on the use-cases doc. What is the status of >> >addressing that, as well as the non-blocking comments from IESG >> >evaluation? >> > >> >Barry >> > >> >_______________________________________________ >> >scim mailing list >> >scim@ietf.org >> >https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --=20 Best regards, Kathleen --B_3513779913_3946593 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
> Perhaps something like the = following, after the third paragraph:

> Additionally, = privacy sensitive data elements may be omitted or obscured in SCIM transacti= ons or stored records to protect these data elements for a user.  For i= nstance a role based identifier might be used in place of an individual's na= me.

OK, thank you!

W= ill add to the draft.

Kind Regards
Kepeng=

=B7=A2=BC=FE=C8=CB: Kathleen Mo= riarty <kathleen.moriar= ty.ietf@gmail.com>
=C8=D5=C6=DA: We= dnesday, 6 May, 2015 5:20 pm
=D6=C1: L= i Kepeng <kepeng.lkp@alibaba-= inc.com>
=B3=AD=CB=CD: Barry Leiba = <barryleiba@computer.org>= , "scim@ietf.org" <scim@ietf.org>
=D6=F7=CC=E2: Re: [scim] Status of use-cases

= Thank you for the updates to the draft.  It would be good to also see a= statement in the security considerations section that includes leaving out = data elements or obscuring them to protect users privacy.  Privacy conc= erns aren't limited to regulations and this would help to make that point.&n= bsp; Perhaps something like the following, after the third paragraph:
Additionally, privacy sensitive data elements may be omitted or= obscured in SCIM transactions or stored records to protect these data eleme= nts for a user.  For instance a role based identifier might be used in = place of an individual's name.

Best regards,
<= div>Kathleen



On Sat, May 2, 2015 at 12:43 PM, Kepeng Li <= span dir=3D"ltr"><kepeng.lkp@alibaba-inc.com> wrote:
Hi Barry,

Thanks for your reminder.

>There's still a DISCUSS on the use-cases doc.  What is the status = of
addressing that, as well as the non-blocking comments from IESG
E= valuation?

I just posted some resolutions to the review comments, and provided a new version:
https://datatracker.ietf.org/doc/draft-ietf-scim-use-= cases/

Diff from previous version:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-scim-use-cases-07


Hopefully we can close all the IESG comments.


Kind Regards
Kepeng

=D4=DA 1/5/15 6:39 pm=A3=AC "Barry Leiba" <barryleiba@computer.org> =D0=B4=C8=EB:

>There's still a DISCUSS on the use-cases doc.  What is the status = of
>addressing that, as well as the non-blocking comments from IESG
>evaluation?
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>ht= tps://www.ietf.org/mailman/listinfo/scim


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

=

--

Best regards,
Kathleen
--B_3513779913_3946593-- From nobody Wed May 6 04:21:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28D21B2B72; Wed, 6 May 2015 04:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.061 X-Spam-Level: X-Spam-Status: No, score=-12.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2kKCNKzP806; Wed, 6 May 2015 04:21:50 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3C71B2B61; Wed, 6 May 2015 04:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3112; q=dns/txt; s=iport; t=1430911288; x=1432120888; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iFUQbiYuDdFZbvo3JI4tAABQH+nljYuCMGgPq+euL74=; b=cgWROkbP5gq8GogXXFoHX9wjspjXqZpJSw8V4lg0ADDLmMhGp7Y+vDi6 AJYIMzCzWgI6h4tUq8xhGyDQD+7LjffjiZWujwHjgt8oI8eQkkDgBSHpu SE9JOZ217DSOtvzqxgkts2R0hhcB3xVc8rO2O0Ud0qnkeZ5L2ng5dKc6n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBAC8+ElV/xbLJq1TCYNfXIMduiqII4FWhgUCgWQTAQEBAQEBAYEKhCEBAQQnCwEFMw0BEAkCHAUWDQIJAwIBAgFFBgEMAQUCAQEFiCMNk0idAQiUAwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBHYocgmSBPgcKAVEHgmSBSQEEhlSEUIsVhkSBJD2DGYJXIYcHg2yDUyNggQVTgT49MQGBCoE6AQEB X-IronPort-AV: E=Sophos;i="5.13,379,1427760000"; d="scan'208";a="461277148" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 06 May 2015 11:21:25 +0000 Received: from [10.61.211.137] ([10.61.211.137]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t46BLOX0020056; Wed, 6 May 2015 11:21:25 GMT Message-ID: <5549F934.9050006@cisco.com> Date: Wed, 06 May 2015 12:21:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kepeng Li , The IESG References: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: scim@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, draft-ietf-scim-use-cases@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: Re: [scim] Benoit Claise's No Objection on draft-ietf-scim-use-cases-06: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 11:21:53 -0000 Thank you Kepeng, Regards, Benoit > Hi Benoit, > > Thanks for your review and comments. > > Please find my proposed changes below. > > Kind Regards > Kepeng > > 在 23/4/15 5:07 pm， "Benoit Claise" 写入: > >> Benoit Claise has entered the following ballot position for >> draft-ietf-scim-use-cases-06: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - From the charter: >> The use cases document will be a "living document", guiding the >> working group during its development of the standards. The group may >> take snapshots of that document for Informational publication, to >> serve as documentation of the motivation for the work in progress >> and to similarly guide planning and implementation. >> >> ... >> Mar 2013 - Initial adoption of SCIM use cases, as a living document >> >> Looking at the charter and the draft name, I was ready to ask: is this a >> living document? should it be published? >> Reading the draft, it contains way more than the use cases: concepts and >> requirements are included. >> Which means that, even if you add new use cases, the requirements will >> (hopefully) not change. This is a good reason to publish. >> You should really update the title, and potentially the abstract to match >> the content: a mix of use cases, requirements, some (framework type of >> level) concepts and flows. Don't get me wrong, it's not a bad thing to >> combine all these into a single document, and I enjoyed the read. >> Proposal: from "SCIM Definitions, Overview, and Flows" to something such >> as "SCIM Definitions, Overview, Concepts, and Requirements" > OK, changed. I also changed the abstract and introduction. > >> - I'm certainly not an expert in identity management, but I understood >> the difference between SCIM and ABFAB as ABFAB = just in time >> provisioning, as opposed to SCIM = pre-provisioning (ok, except maybe in >> the SSO "special" use case). A few words on this in the intro would have >> helped me to put the right context. > As proposed by Leif, I added: > > Unlike the practice of some protocols like ABFAB and SAML2 WebSSO, SCIM > provides provisioning and de-provisioning of resources in a separate > context from authentication (aka just-in-time provisioning). > > > >> Editorial: >> - It's intent is to reduce -> Its intend is to reduce >> - C.R.U.D -> CRUD (since you have it in the acronym section) > OK, changed. > > > . > From nobody Wed May 6 08:51:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0021B2B9D for ; Wed, 6 May 2015 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INUpy-Sp2M7I for ; Wed, 6 May 2015 08:51:17 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938931B2B9B for ; Wed, 6 May 2015 08:51:17 -0700 (PDT) Received: by iepj10 with SMTP id j10so14174929iep.0 for ; Wed, 06 May 2015 08:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mtklIvIU5V0uoLbWLuSKgZn9+DNxhNVv0pfb7Ifa4tg=; b=SXJo1CEYu7Oj6YK39EP0wv1lcGdh280qhwG5d3sTnJw7/S6MWoUQ94yfzxPPMj5L/v dXBau3xkrXk2wMPWpberXeDjPtp+ppmIWc7MZUdIGbWVStbMT2lvV/bKX61/3hwZOqJr eUosb2nFUvScZKj2r9UIbFVhJicT/rEo1Q6ubLe56QxycWdyiCbUS+BbyfRWVkgWJF3q AKH6qhcHeXE7aPF9fl0Ok2JUVCenXMs7GjQJDbM1JB4HKQrdoiUuNmP9/g38crHb9msc xdeNbv6sndds2Q7V8B3VNgAgy49BueEcQXjyy37QXSkpeVo/eZSPEgQAEv1QEr6IerIO krrg== X-Gm-Message-State: ALoCoQnse3lQVu+339WA+099c4a27rFZoSjhptgzX/ykV9WNnmJxM83S8QbH2/Ic4pknsT6uDqLj X-Received: by 10.50.143.33 with SMTP id sb1mr8763742igb.33.1430927033528; Wed, 06 May 2015 08:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.116.15 with HTTP; Wed, 6 May 2015 08:43:33 -0700 (PDT) In-Reply-To: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> From: Ian Glazer Date: Wed, 6 May 2015 17:43:33 +0200 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1134b38a88961905156ba903 Archived-At: Cc: Patrick Radtke , SCIM WG , Morteza Ansari , Michael Frost , Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:51:25 -0000 --001a1134b38a88961905156ba903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am against changing manager to be multi-valued. I've built 3 user provisioning engines and have never seen a case where manager is multi-valued. If you have a matrix-ed organization where there are dotted line relationships, then I recommend an extension. But we ought to keep SCIM focused on the mainstream scenario where a person has a single manager= . On Wed, May 6, 2015 at 12:24 AM, Phil Hunt wrote: > > My understanding is that we do. Dotted line and multi-reporting > relationships are a reality for many enterprise organizations. At least > one (or more) of our implementations is multi-valued. This was also raise= d > to me as an issue. > > > I think the reality is that we=E2=80=99ll all run into enterprises wantin= g > multi-valued managers sooner or later. Having it multi-valued doesn=E2= =80=99t mean > you have to support multiple values. But the important thing is that SCI= M > parsers will need to expect an array. > > *Maybe we need a general note that parsers should accept a single value > JSON object even when an attribute is multi-valued (for any multi-valued > attribute)*. This would make the issue non-breaking for clients (who > think any attribute is single-valued). As for servers, it seems to me we > have a compatibility issue due to the spec inconsistency (while definitio= n > is single-value, examples are multi-valued). That means regardless of our > decisions some servers will have to be updated. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) > wrote: > > Speaking as an individual =E2=80=93 I am not aware of any IdM system tha= t has > multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many cases a multiv= alued manager > brakes many applications as the reporting hierarchy is assumed to be a tr= ee > structure with a one to many relationship not many to many. Unless someon= e > has a solid use case for turning this into a multivalued attribute, my vo= te > as one of the implementors is to fix the example and leave it as single > valued. > > > Cheers, > Morteza > > From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM > To: Phil Hunt , Kelly Grizzle < > kelly.grizzle@sailpoint.com> > Cc: "scim@ietf.org" , Michael Frost < > michael.frost@oracle.com> > Subject: Re: [scim] Manager attribute wording suggestion > > Is it too late in the process to make the attribute name plural > (=E2=80=9Cmanagers=E2=80=9D)? All the other multiValued attributes I saw = in core-schema use > the plural form for the attribute name. > > From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM > To: Kelly Grizzle > Cc: Michael Frost , Jive IT < > patrick.radtke@jivesoftware.com>, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > > There are a couple of changes from the IESG review coming to > core-schema (for other reasons - emails to follow). > > With regards to this issue, I propose that the next update make > =E2=80=9Cmanager=E2=80=9D a multi-valued attribute so that it is consiste= nt with the > examples and to correct the apparent inconsistency in the draft. > > If there are any strong objections, please respond and discuss. > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: > > It looks like this got changed back in October in revision 12 of the > core schema doc. > > Draft 12 - PH - Nits / Corrections > > ... > > Corrected enterprise User manager attribute to use sub-attribute > value and make multi-valued > > I hadn=E2=80=99t realized that this change went in. Up until then manage= r had > been single-valued since SCIM 1.0. If there is consensus that this chang= e > should stay, then it seems like we need to update section 4.3. > > Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for the =E2= =80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D > sub-attributes, this is consistent with the rest of the attribute > definitions that are references. I agree with you, Patrick, that these > should be required. > > --Kelly > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] > *Sent:* Thursday, April 30, 2015 2:21 PM > *To:* Michael Frost > *Cc:* Kelly Grizzle; Patrick Radtke; SCIM WG > *Subject:* Re: [scim] Manager attribute wording suggestion > > Agreed. > > Will need consensus/direction from the chairs on this and along with the > other issue (401/403/501 status code clarification). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: > > It is multi-valued in the example in 8.3 and in the schema on page 60, > and in our implementation. I think only the text in section 4.3 refers t= o > manager as singular. > > -mrf > > *From:* Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com > ] > *Sent:* Thursday, April 30, 2015 10:28 AM > *To:* Phil Hunt > *Cc:* Patrick Radtke; SCIM WG > *Subject:* Re: [scim] Manager attribute wording suggestion > > Does anyone have any strong opinions about making manager multi-valued or > leaving it as-is? > > Either way we should probably clean up the text in section 4.3 and the > schema definition. > > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] > *Sent:* Thursday, April 30, 2015 10:28 AM > *To:* Kelly Grizzle > *Cc:* Patrick Radtke; SCIM WG > *Subject:* Re: Manager attribute wording suggestion > > I recall your comment and given lack of input at the time, it was clear > there was no consensus for change. I had to leave it as is despite thinki= ng > it needed to be multi-valued. > > Phil > > > On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: > > I had forgotten about that. The most discussion that I found was in this > email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. > > Note, the schema also needs to be updated. It looks like it should be > multi-valued > since many orgs have people with multiple reporting relationships. > > I don=E2=80=99t remember ever discussing this any further or if we achiev= ed > consensus on changing this. The email thread doesn=E2=80=99t have any mo= re > discussion. > > I=E2=80=99m not sure that I agree that this should be multivalued. If an= ything > else, I would never wish multiple managers upon anyone. ;) Being serious= , > though, this might fit better as a second attribute that describes other > reporting relationships. > > Anyone else remember this? > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] > *Sent:* Wednesday, April 29, 2015 6:41 PM > *To:* Kelly Grizzle > *Cc:* Patrick Radtke; SCIM WG > *Subject:* Re: Manager attribute wording suggestion > > I believe I raised this issue before and the consensus was to leave it. > Maybe I am mistaken? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: > > Patrick =E2=80=A6 thanks for the feedback. > > I think that the schema section is incorrect. The $ref and value are > required and manager is still single valued. I think the text in 4.3 > should say: > > manager > > The user's manager. A complex type that optionally allows service > > providers to represent organizational hierarchy by referencing the > > "id" attribute of another User. > > > Phil, do you agree? > > --Kelly > > *From:* scim [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Patrick Radtke > *Sent:* Friday, April 24, 2015 5:47 PM > *To:* SCIM WG > *Subject:* [scim] Manager attribute wording suggestion > > There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D attribute tha= t seem > inconsistent. > > In 4.3 Enterprise User Schema extension it says > "manager > > The user's manager. A complex type that optionally allows service > > providers to represent organizational hierarchy by referencing the > > "id" attribute of another User. > > > > value The "id" of the SCIM resource representing the user's > > manager. RECOMMENDED. > > > > $ref The URI of the SCIM resource representing the User's > > manager. RECOMMENDED. > > =E2=80=9C > To me that says that a user may have a single manager, and =E2=80=98valu= e=E2=80=99 and > =E2=80=98$ref=E2=80=99 attributes are not required. > > However in the Schema section, manager is listed as "multiValued: true= =E2=80=9D > and though subAttributes of =E2=80=9C$ref=E2=80=9D and =E2=80=9Cvalue=E2= =80=9D have =E2=80=9Crequired:false=E2=80=9D the > description attribute says each is required. > > If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t req= uired, can the Manager schema > description be adjusted? > Since manager is multi-valued, can section 4.3 be updated to say. "The > user's managers. A multi-valued complex type that=E2=80=A6=E2=80=9D Oth= erwise, at first > read (or for anyone coming from SCIM 1.1) it is not obvious that it has > become multi-valued. > > Thanks, > > Patrick > > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a1134b38a88961905156ba903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am against changing manager to be multi-valued. I've= built 3 user provisioning engines and have never seen a case where manager= is multi-valued. If you have a matrix-ed organization where there are dott= ed line relationships, then I recommend an extension. But we ought to keep = SCIM focused on the mainstream scenario where a person has a single manager= .

On Wed, Ma= y 6, 2015 at 12:24 AM, Phil Hunt <phil.hunt@oracle.com> w= rote:
<As Individual>
My understanding is that we do.=C2=A0 Dotted lin= e and multi-reporting relationships are a reality for many enterprise organ= izations.=C2=A0 At least one (or more) of our implementations is multi-valu= ed. This was also raised to me as an issue.

<As = Editor>
I think the reality is that we=E2=80=99ll all run into= enterprises wanting multi-valued managers sooner or later.=C2=A0 Having it= multi-valued doesn=E2=80=99t mean you have to support multiple values.=C2= =A0 But the important thing is that SCIM parsers will need to expect an arr= ay.

Maybe we need a general note that parsers s= hould accept a single value JSON object even when an attribute is multi-val= ued (for any multi-valued attribute).=C2=A0 This would make the issue n= on-breaking for clients (who think any attribute is single-valued).=C2=A0 A= s for servers, it seems to me we have a compatibility issue due to the spec= inconsistency (while definition is single-value, examples are multi-valued= ). That means regardless of our decisions some servers will have to be upda= ted.


On May 5, 2015, at 2:14 PM, Morteza= Ansari (moransar) <moransar@cisco.com> wrote:

Speaking as an individual =E2=80=93 I am not aware of any IdM system t= hat has multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many cases a = multivalued manager brakes many applications as the reporting hierarchy is = assumed to be a tree structure with a one to many relationship not many to many. Unless someone has a solid use case for turning this int= o a multivalued attribute, my vote as one of the implementors is to fix the= example and leave it as single valued.


Cheers,
Morteza

From: Patrick Radtke <patrick.radtke@j= ivesoftware.com>
Date: Monday, May 4, 2015 at 4:10 P= M
To: Phil Hunt <phil.hunt@oracle.com>, Kell= y Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>, Michael Frost <michael.frost@ora= cle.com>
Subject: Re: [scim] Manager attribu= te wording suggestion

Is it too late in the process to make the attribute name plural (=E2= =80=9Cmanagers=E2=80=9D)? All the other multiValued attributes I saw in cor= e-schema use the plural form for the attribute name.

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 P= M
To: Kelly Grizzle <kelly.grizzle@sailpoint= .com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT <patrick.radtke@jivesoftware.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribu= te wording suggestion

There are a couple of changes from the IESG review coming to core-sche= ma (for other reasons - emails to follow).

With regards to this issue, I propose that the next update make =E2=80= =9Cmanager=E2=80=9D a multi-valued attribute so that it is consistent with = the examples and to correct the apparent inconsistency in the draft.

If there are any strong objections, please respond and discuss.

Thanks,


On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:

It looks like this got changed back i= n October in revision 12 of the core schema doc.
=
=C2=A0
=C2=A0=C2=A0 Draft 12 - = PH - Nits / Corrections
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
<= span style=3D"font-size:10pt;font-family:'Courier New'">=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Corrected enterpr= ise User manager attribute to use sub-attribute
<= div class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value and make multi-valued=
=C2=A0
I hadn=E2=80=99t realized that this change went in.=C2=A0= Up until then manager had been single-valued since SCIM 1.0.=C2=A0 If ther= e is consensus that this change should stay, then it seems like we need to update section 4.3. <= /u>
=C2=A0
Regarding the fact that =E2=80=9Crequired=E2=80=9D is false f= or the =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, t= his is consistent with the rest of the attribute definitions that are references.=C2=A0 I agree with you, Patrick, that the= se should be required.
=C2=A0=
--Kelly
=C2=A0
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion
=C2=A0
Agreed.
=C2=A0
Will need consensus/direction from the chairs= on this and along with the other issue (401/403/501 status code clarificat= ion).
=C2=A0
Phil
= =C2=A0
@independentid
phil.hunt@or= acle.com
=C2=A0
On Apr 30, 2015, at 11:42 AM, Michael Frost &= lt;michael.fr= ost@oracle.com> wrote:
=C2=A0
It is multi-valued in the example in = 8.3 and in the schema on page 60, and in our implementation.=C2=A0 I think = only the text in section 4.3 refers to manager as singular.
=C2=A0
= -mrf
=C2=A0
From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion
=C2=A0
Does anyone have any strong opinions about making manager mu= lti-valued or leaving it as-is?

Either way we should probably clean up the text in section 4.3 and the sche= ma definition.
= =C2=A0
=C2=A0
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion
=C2=A0
I recall your comment and given lack of input= at the time, it was clear there was no consensus for change. I had to leav= e it as is despite thinking it needed to be multi-valued.=C2=A0

Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrot= e:

I had forgotten about that.=C2=A0 The= most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=
=C2=A0
=C2=A0=C2=A0 Note, the schema also needs to be u= pdated. It looks like it should be multi-valued
<= div class=3D"MsoNormal">=C2=A0 since many = orgs have people with multiple reporting relationships.
=C2=A0
I don=E2=80=99t remember ever discussing thi= s any further or if we achieved consensus on changing this.=C2=A0 The email= thread doesn=E2=80=99t have any more discussion.
=C2=A0
I=E2=80=99m not sure that I agree that this should= be multivalued.=C2=A0 If anything else, I would never wish multiple manage= rs upon anyone. ;)=C2=A0 Being serious, though, this might fit better as a second attribute that describe= s other reporting relationships.
=C2=A0
= Anyone else remember this?
=C2=A0
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion
=C2=A0
I believe I raised this issue before and the consensus was to leave = it.=C2=A0 Maybe I am mistaken?
=C2=A0
Phil
=C2=A0
@independentid
phil.hunt@or= acle.com
=C2=A0
On Apr 29, 2015, at 4:06 PM, Kelly Grizzle &l= t;kelly.gr= izzle@sailpoint.com> wrote:
=C2=A0
Patrick =E2=80=A6 thanks for the feed= back.
=C2=A0
I think that the sc= hema section is incorrect.=C2=A0 The $ref and value are required and manage= r is still single valued.=C2=A0 I think the text in 4.3 should say:
=C2= =A0
manager 
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 The user's manager.=C2=A0 A complex type that optionally allo=
ws service
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 providers to represent organizational hierarchy by referencing the
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "id" attribute of another User.
=C2=A0
Phil, do you agree?
=C2=A0
--Kelly
=C2=A0
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording suggestion
=C2=A0
There are a couple aspects of the =E2=80=9Cmanager=E2=80= =9D attribute that seem inconsistent.
=C2=A0
In 4.3 Enterprise User Schema extension it says
"manager
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 The user's manager.=C2=A0 A complex type that optionally allo=
ws service
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 providers to represent organizational hierarchy by referencing th=
e
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 "id" attribute of another User.

=C2=A0=



=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 value=C2=A0 The "id" of the SCIM resource representing =
the user's


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 manager.=C2=A0 RECOMMENDED.


=C2=A0=



=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 $ref=C2=A0 The URI of the SCIM resource representing the User'=
;s


=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 manager.=C2=A0 RECOMMENDED.


=E2=80=9C




To me that says that a user may have a single manager, a=
nd =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not re=
quired.




=C2=A0




However in the Schema section, manager is listed as &quo=
t;multiValued: true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=
=80=9D and =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D th=
e description attribute
 says each is required.




=C2=A0




If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D ar=
en=E2=80=99t required, can the Manager schema description be adjusted?




Since manager is multi-valued, can section 4.3 be updated to say. "<=
/span>The use=
r's managers.=C2=A0 A multi-valued
 complex type that=E2=80=A6=E2=80=9D =C2=A0Otherwise, at first read (or for=
 anyone coming from SCIM 1.1) it is not obvious that it has become multi-va=
lued.




=C2=A0




Thanks,




=C2=A0




Patrick




=C2=A0




=C2=A0




=C2=A0




=C2=A0
=C2=A0
____________________________________________= ___
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim
=C2=A0



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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--001a1134b38a88961905156ba903-- From nobody Wed May 6 08:55:35 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649221A19E5 for ; Wed, 6 May 2015 08:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 655xK-PqCLWt for ; Wed, 6 May 2015 08:55:30 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D1B1A19F2 for ; Wed, 6 May 2015 08:55:27 -0700 (PDT) Received: by lagv1 with SMTP id v1so10754002lag.3 for ; Wed, 06 May 2015 08:55:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dWlyR/DnYPeslWrssso/6NYqlQFEhFKjrgwMjAbyAU4=; b=dJvV4rbuiksifIlYS9g1/DaPjiQKyA1JKz4JudvMb+iRjSSoMDzCIpIWH7IyUfk6wZ qL6No0hzYDqmWUwL2AjG5WAFLbSH3DVfK5bUvUTEkFaG59szBu0ZFHQ3LqHj19dIFqtH e6QZ9yAMKTGsn9joU5p/t0CWDf2X1E1PBHr9TsiLD/FnvllZUq4D3UFdiEDLpbGBg5tE v+wTEJQbqJ3wUC9qNl9zpx/1trZ1XyWF1KXuAxADQuWTPBQkd8uTyZTXnzfhYoEhn3vz ixl+vY7MBRYoCJ/b5owP/yFI4ic4vLUVwrrfXNzyu/0JbuXu7cQfA0YxUuZKn7AUDj/O 2RfQ== X-Gm-Message-State: ALoCoQn8KmkwhfRFYCbmq2nMrdju4mhwGpFZNiJpYjiBCcQAmoTzHOsQJCDA0N8mTgxpqD5b+dbu X-Received: by 10.152.163.36 with SMTP id yf4mr2491960lab.55.1430927725642; Wed, 06 May 2015 08:55:25 -0700 (PDT) Received: from [2.67.94.117] (2.67.94.117.mobile.tre.se. [2.67.94.117]) by mx.google.com with ESMTPSA id x2sm446759laj.8.2015.05.06.08.55.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 08:55:24 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-53A1060E-87A6-43C8-83DC-A6B89882A834 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 6 May 2015 17:55:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> To: Ian Glazer Archived-At: Cc: Michael Frost , Patrick Radtke , SCIM WG , Kelly Grizzle , Morteza Ansari , Phil Hunt Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:55:34 -0000 --Apple-Mail-53A1060E-87A6-43C8-83DC-A6B89882A834 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 6 maj 2015 kl. 17:43 skrev Ian Glazer : >=20 > I am against changing manager to be multi-valued. I've built 3 user provis= ioning engines and have never seen a case where manager is multi-valued. If y= ou have a matrix-ed organization where there are dotted line relationships, t= hen I recommend an extension. But we ought to keep SCIM focused on the mains= tream scenario where a person has a single manager. +1 (as individual) >=20 >> On Wed, May 6, 2015 at 12:24 AM, Phil Hunt wrote: >> >> My understanding is that we do. Dotted line and multi-reporting relation= ships are a reality for many enterprise organizations. At least one (or mor= e) of our implementations is multi-valued. This was also raised to me as an i= ssue. >>=20 >> >> I think the reality is that we=E2=80=99ll all run into enterprises wantin= g multi-valued managers sooner or later. Having it multi-valued doesn=E2=80= =99t mean you have to support multiple values. But the important thing is t= hat SCIM parsers will need to expect an array. >>=20 >> Maybe we need a general note that parsers should accept a single value JS= ON object even when an attribute is multi-valued (for any multi-valued attri= bute). This would make the issue non-breaking for clients (who think any at= tribute is single-valued). As for servers, it seems to me we have a compati= bility issue due to the spec inconsistency (while definition is single-value= , examples are multi-valued). That means regardless of our decisions some se= rvers will have to be updated. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) wrote: >>>=20 >>> Speaking as an individual =E2=80=93 I am not aware of any IdM system tha= t has multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many cases a mul= tivalued manager brakes many applications as the reporting hierarchy is assu= med to be a tree structure with a one to many relationship not many to many.= Unless someone has a solid use case for turning this into a multivalued att= ribute, my vote as one of the implementors is to fix the example and leave i= t as single valued. >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>> From: Patrick Radtke >>> Date: Monday, May 4, 2015 at 4:10 PM >>> To: Phil Hunt , Kelly Grizzle >>> Cc: "scim@ietf.org" , Michael Frost >>> Subject: Re: [scim] Manager attribute wording suggestion >>>=20 >>> Is it too late in the process to make the attribute name plural (=E2=80=9C= managers=E2=80=9D)? All the other multiValued attributes I saw in core-schem= a use the plural form for the attribute name. >>>=20 >>> From: Phil Hunt >>> Date: Monday, May 4, 2015 at 4:04 PM >>> To: Kelly Grizzle >>> Cc: Michael Frost , Jive IT , SCIM WG >>> Subject: Re: [scim] Manager attribute wording suggestion >>>=20 >>> There are a couple of changes from the IESG review coming to core-schema= (for other reasons - emails to follow). >>>=20 >>> With regards to this issue, I propose that the next update make =E2=80=9C= manager=E2=80=9D a multi-valued attribute so that it is consistent with the e= xamples and to correct the apparent inconsistency in the draft. >>>=20 >>> If there are any strong objections, please respond and discuss. >>>=20 >>> Thanks, >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On Apr 30, 2015, at 1:50 PM, Kelly Grizzle wrote: >>>>=20 >>>> It looks like this got changed back in October in revision 12 of the co= re schema doc. >>>> =20 >>>> Draft 12 - PH - Nits / Corrections >>>> =20 >>>> ... >>>> =20 >>>> Corrected enterprise User manager attribute to use sub-attribute >>>> value and make multi-valued >>>> =20 >>>> I hadn=E2=80=99t realized that this change went in. Up until then mana= ger had been single-valued since SCIM 1.0. If there is consensus that this c= hange should stay, then it seems like we need to update section 4.3. >>>> =20 >>>> Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for the =E2= =80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, this is cons= istent with the rest of the attribute definitions that are references. I ag= ree with you, Patrick, that these should be required. >>>> =20 >>>> --Kelly >>>> =20 >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>> Sent: Thursday, April 30, 2015 2:21 PM >>>> To: Michael Frost >>>> Cc: Kelly Grizzle; Patrick Radtke; SCIM WG >>>> Subject: Re: [scim] Manager attribute wording suggestion >>>> =20 >>>> Agreed. >>>> =20 >>>> Will need consensus/direction from the chairs on this and along with th= e other issue (401/403/501 status code clarification). >>>> =20 >>>> Phil >>>> =20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> =20 >>>>> On Apr 30, 2015, at 11:42 AM, Michael Frost = wrote: >>>>> =20 >>>>> It is multi-valued in the example in 8.3 and in the schema on page 60,= and in our implementation. I think only the text in section 4.3 refers to m= anager as singular. >>>>> =20 >>>>> -mrf >>>>> =20 >>>>> From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 >>>>> Sent: Thursday, April 30, 2015 10:28 AM >>>>> To: Phil Hunt >>>>> Cc: Patrick Radtke; SCIM WG >>>>> Subject: Re: [scim] Manager attribute wording suggestion >>>>> =20 >>>>> Does anyone have any strong opinions about making manager multi-valued= or leaving it as-is? >>>>>=20 >>>>> Either way we should probably clean up the text in section 4.3 and the= schema definition. >>>>> =20 >>>>> =20 >>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>> Sent: Thursday, April 30, 2015 10:28 AM >>>>> To: Kelly Grizzle >>>>> Cc: Patrick Radtke; SCIM WG >>>>> Subject: Re: Manager attribute wording suggestion >>>>> =20 >>>>> I recall your comment and given lack of input at the time, it was clea= r there was no consensus for change. I had to leave it as is despite thinkin= g it needed to be multi-valued.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Apr 30, 2015, at 06:41, Kelly Grizzle wrote: >>>>>>=20 >>>>>> I had forgotten about that. The most discussion that I found was in t= his email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.= >>>>>> =20 >>>>>> Note, the schema also needs to be updated. It looks like it should= be multi-valued >>>>>> since many orgs have people with multiple reporting relationships. >>>>>> =20 >>>>>> I don=E2=80=99t remember ever discussing this any further or if we ac= hieved consensus on changing this. The email thread doesn=E2=80=99t have an= y more discussion. >>>>>> =20 >>>>>> I=E2=80=99m not sure that I agree that this should be multivalued. I= f anything else, I would never wish multiple managers upon anyone. ;) Being= serious, though, this might fit better as a second attribute that describes= other reporting relationships. >>>>>> =20 >>>>>> Anyone else remember this? >>>>>> =20 >>>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>>> Sent: Wednesday, April 29, 2015 6:41 PM >>>>>> To: Kelly Grizzle >>>>>> Cc: Patrick Radtke; SCIM WG >>>>>> Subject: Re: Manager attribute wording suggestion >>>>>> =20 >>>>>> I believe I raised this issue before and the consensus was to leave i= t. Maybe I am mistaken? >>>>>> =20 >>>>>> Phil >>>>>> =20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> =20 >>>>>>> On Apr 29, 2015, at 4:06 PM, Kelly Grizzle wrote: >>>>>>> =20 >>>>>>> Patrick =E2=80=A6 thanks for the feedback. >>>>>>> =20 >>>>>>> I think that the schema section is incorrect. The $ref and value ar= e required and manager is still single valued. I think the text in 4.3 shou= ld say: >>>>>>> =20 >>>>>>> manager >>>>>>> The user's manager. A complex type that optionally allows ser= vice >>>>>>> providers to represent organizational hierarchy by referencing= the >>>>>>> "id" attribute of another User. >>>>>>> =20 >>>>>>> Phil, do you agree? >>>>>>> =20 >>>>>>> --Kelly >>>>>>> =20 >>>>>>> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtk= e >>>>>>> Sent: Friday, April 24, 2015 5:47 PM >>>>>>> To: SCIM WG >>>>>>> Subject: [scim] Manager attribute wording suggestion >>>>>>> =20 >>>>>>> There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D attribut= e that seem inconsistent. >>>>>>> =20 >>>>>>> In 4.3 Enterprise User Schema extension it says >>>>>>> "manager >>>>>>> The user's manager. A complex type that optionally allows ser= vice >>>>>>> providers to represent organizational hierarchy by referencing= the >>>>>>> "id" attribute of another User. >>>>>>> =20 >>>>>>> value The "id" of the SCIM resource representing the user's >>>>>>> manager. RECOMMENDED. >>>>>>> =20 >>>>>>> $ref The URI of the SCIM resource representing the User's >>>>>>> manager. RECOMMENDED. >>>>>>> =E2=80=9C >>>>>>> To me that says that a user may have a single manager, and =E2=80=98= value=E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not required. >>>>>>> =20 >>>>>>> However in the Schema section, manager is listed as "multiValued: tr= ue=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80=9D and =E2=80=9C= value=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D the description attribu= te says each is required. >>>>>>> =20 >>>>>>> If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t= required, can the Manager schema description be adjusted? >>>>>>> Since manager is multi-valued, can section 4.3 be updated to say. "T= he user's managers. A multi-valued complex type that=E2=80=A6=E2=80=9D Oth= erwise, at first read (or for anyone coming from SCIM 1.1) it is not obvious= that it has become multi-valued. >>>>>>> =20 >>>>>>> Thanks, >>>>>>> =20 >>>>>>> Patrick >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-53A1060E-87A6-43C8-83DC-A6B89882A834 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


6 maj 20= 15 kl. 17:43 skrev Ian Glazer <= iglazer@salesforce.com>:

=
I am against changing manager to be multi-valued. I've buil= t 3 user provisioning engines and have never seen a case where manager is mu= lti-valued. If you have a matrix-ed organization where there are dotted line= relationships, then I recommend an extension. But we ought to keep SCIM foc= used on the mainstream scenario where a person has a single manager.

+1 (as individual)


On Wed, May 6, 2015 at 12:24 AM, Phil Hunt <phil.hunt@oracle.com>= wrote:
<As Individual>
My understanding is that we do.  Dott= ed line and multi-reporting relationships are a reality for many enterprise o= rganizations.  At least one (or more) of our implementations is multi-v= alued. This was also raised to me as an issue.

<A= s Editor>
I think the reality is that we=E2=80=99ll all run int= o enterprises wanting multi-valued managers sooner or later.  Having it= multi-valued doesn=E2=80=99t mean you have to support multiple values. = ; But the important thing is that SCIM parsers will need to expect an array.=

Maybe we need a general note that parsers shoul= d accept a single value JSON object even when an attribute is multi-valued (= for any multi-valued attribute).  This would make the issue non-bre= aking for clients (who think any attribute is single-valued).  As for s= ervers, it seems to me we have a compatibility issue due to the spec inconsi= stency (while definition is single-value, examples are multi-valued). That m= eans regardless of our decisions some servers will have to be updated.
=


On May 5, 2015, at 2:14 PM, Morteza A= nsari (moransar) <moransar@cisco.com> wrote:

Speaking as an individual =E2=80=93 I am not aware of any IdM system th= at has multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many cases a mu= ltivalued manager brakes many applications as the reporting hierarchy is ass= umed to be a tree structure with a one to many relationship not many to many. Unless someone has a solid use case for turning this into= a multivalued attribute, my vote as one of the implementors is to fix the e= xample and leave it as single valued.


Cheers,
Morteza

From: Patrick Radtke <patrick.radtke@jiv= esoftware.com>
Date: Monday, May 4, 2015 at 4:10 PM=
To: Phil Hunt <phil.hunt@oracle.com>, Kelly G= rizzle <= kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>, Michael Frost <michael.frost@oracle.com>=
Subject: Re: [scim] Manager attribut= e wording suggestion

Is it too late in the process to make the attribute name plural (=E2=80= =9Cmanagers=E2=80=9D)? All the other multiValued attributes I saw in core-sc= hema use the plural form for the attribute name.

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM=
To: Kelly Grizzle <kelly.grizzle@sailpoint.c= om>
Cc: Michael Frost <michael.frost@oracle.com= >, Jive IT <patrick.radtke@jivesoftware.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribut= e wording suggestion

There are a couple of changes from the IESG review coming to core-schem= a (for other reasons - emails to follow).

With regards to this issue, I propose that the next update make =E2=80=9C= manager=E2=80=9D a multi-valued attribute so that it is consistent with the e= xamples and to correct the apparent inconsistency in the draft.

If there are any strong objections, please respond and discuss.

Thanks,


On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com>= wrote:

It looks like this got changed back in O= ctober in revision 12 of the core schema doc.
 
   Draft 12 - PH - Nits / Cor= rections
 
    &n= bsp; ...
 
    &n= bsp; Corrected enterprise User manager attribute to use sub-attribute=
      value and make mult= i-valued
 
I hadn=E2=80=99t realized that this change went in= .  Up until then manager had been single-valued since SCIM 1.0.  I= f there is consensus that this change should stay, then it seems like we need to update section 4.3.
 
Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for t= he =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, this i= s consistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that thes= e should be required.
 
--Kelly
 
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion
 
Agreed.
 
Will need consensus/direction from the chairs o= n this and along with the other issue (401/403/501 status code clarification= ).
 
Phil
&nb= sp;
@independentid
phil.hunt@orac= le.com
 
On Apr 30, 2015, at 11:42 AM, Michael Frost &l= t;michael.fros= t@oracle.com> wrote:
 
It is multi-valued in the example in 8.= 3 and in the schema on page 60, and in our implementation.  I think onl= y the text in section 4.3 refers to manager as singular.
=  
-mrf=
 <= /u>
From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion
 
Does anyone have any strong opinions about making manager multi= -valued or leaving it as-is?

Either way we should probably clean up the text in section 4.3 and the schem= a definition.
&nbs= p;
 
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion
 
I recall your comment and given lack of input a= t the time, it was clear there was no consensus for change. I had to leave i= t as is despite thinking it needed to be multi-valued. 

Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:=

I had forgotten about that.  The m= ost discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.<= u>
 
   Note, the schema also needs to be up= dated. It looks like it should be multi-valued
  since many org= s have people with multiple reporting relationships.
 
I don=E2=80=99t remember ever discussing this any fu= rther or if we achieved consensus on changing this.  The email thread d= oesn=E2=80=99t have any more discussion.
 
I=E2=80=99m not sure that I agree that this should be multivalue= d.  If anything else, I would never wish multiple managers upon anyone.= ;)  Being serious, though, this might fit better as a second attribute that describes= other reporting relationships.
 
Anyone else remember this?
 <= /u>
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion
 
I believe I raised this issue before and the consensus was to leave it= .  Maybe I am mistaken?
 
 
On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <= ;kelly.griz= zle@sailpoint.com> wrote:
 
Patrick =E2=80=A6 thanks for the feedba= ck.
 <= u>
I think that the schema s= ection is incorrect.  The $ref and value are required and manager is st= ill single valued.  I think the text in 4.3 should say:
 <= /span>
manager
    =
  The user's manager.  A complex type that optionally allows servi=
ce
    =
  providers to represent organizational hierarchy by referencing the=

   &nb=
sp;  "id" attribute of another User.
<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,= 125)"> 
Phil, d= o you agree?
 <= /span>
--Kelly<= /u>
 <= /div>
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording suggestion=
 
There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D= attribute that seem inconsistent.
 
In 4.3 Enterprise User Schema extension it says<= /u>
"manager
    =
  The user's manager.  A complex type that optionally allows servi=
ce
    =
  providers to represent organizational hierarchy by referencing the
    =
  "id" attribute of another User.
 <=
/u>
    =
  value  The "id" of the SCIM resource representing the user's
    =
     manager.  RECOMMENDED.

 <=
/u>


    =
  $ref  The URI of the SCIM resource representing the User's


    =
     manager.  RECOMMENDED.

=E2=80=9C




To me that says that a user may have a single manager, and=
 =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not requi=
red.




 




However in the Schema section, manager is listed as "multi=
Valued: true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80=9D and=
 =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D the descripti=
on attribute
 says each is required.




 




If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=
=E2=80=99t required, can the Manager schema description be adjusted?<=
u>




Since manager is multi-valued, can section 4.3 be updated to say. "<=
span style=3D"font-size:10pt;font-family:Calibri,sans-serif">The user's mana=
gers.  A multi-valued
 complex type that=E2=80=A6=E2=80=9D  Otherwise, at first read (or for a=
nyone coming from SCIM 1.1) it is not obvious that it has become multi-value=
d.




 




Thanks,




 




Patrick




 




 




 




 
 
_____________________________________________= __
scim mailing list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim
 



_______= ________________________________________
scim mailing list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior D= irector, Identity
+1 202 255 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-53A1060E-87A6-43C8-83DC-A6B89882A834-- From nobody Wed May 6 09:05:42 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5691B2BCC for ; Wed, 6 May 2015 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M71a8-yd3s6x for ; Wed, 6 May 2015 09:05:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8474F1B2BAB for ; Wed, 6 May 2015 09:05:32 -0700 (PDT) Received: from BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) by BN1PR04MB470.namprd04.prod.outlook.com (10.141.59.16) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 6 May 2015 16:05:13 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.154.19; Wed, 6 May 2015 16:05:12 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.208]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.208]) with mapi id 15.01.0148.019; Wed, 6 May 2015 16:05:12 +0000 From: Kelly Grizzle To: Leif Johansson , Ian Glazer Thread-Topic: [scim] Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAAKSYCAAOjR4IAAH7qAgAAhU9CAABTiAIAACsIAgAAXPuCABnCQAIAAAasAgAFyHACAABODAIABIkCAgAADTICAAAEHkA== Date: Wed, 6 May 2015 16:05:12 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> In-Reply-To: <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 550BC82D009C30550BC97A authentication-results: mnt.se; dkim=none (message not signed) header.d=none; x-originating-ip: [97.79.140.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB470; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0568F32D91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(24454002)(51914003)(76576001)(15975445007)(102836002)(99286002)(16601075003)(122556002)(77156002)(62966003)(74316001)(19617315012)(106116001)(189998001)(92566002)(16236675004)(40100003)(46102003)(2900100001)(86362001)(2950100001)(5001770100001)(19609705001)(19300405004)(50986999)(5001960100002)(5001920100001)(76176999)(54356999)(19580395003)(19580405001)(33656002)(66066001)(19625215002)(93886004)(2656002)(87936001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB3928DB41F838D3382B4A8B1E2D00BN1PR04MB392namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2015 16:05:12.2924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 X-OriginatorOrg: sailpoint.com Archived-At: Cc: Patrick Radtke , SCIM WG , Morteza Ansari , Michael Frost , Phil Hunt Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 16:05:40 -0000 --_000_BN1PR04MB3928DB41F838D3382B4A8B1E2D00BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIElhbi4gIFdoaWxlIG11bHRpcGxlIG1hbmFnZXJzIGlzIHBvc3NpYmxlLCBJ IGhhdmUgbmV2ZXIgc2VlbiBpdCBpbiBhbnkgc3lzdGVtIHRoYXQgSSBoYXZlIGRlYWx0IHdpdGgg 4oCmIGFuZCBJIGhhdmUgc2VlbiBhIGxvdC4gIEl0IGZlZWxzIGxpa2Ugd2Ugd291bGQgYmUgcGVu YWxpemluZyB0aGUgbWFqb3JpdHkgYnkgbWFraW5nIGNsaWVudHMgaGF2ZSB0byBkZWFsIHdpdGgg bXVsdGlwbGUgdmFsdWVzIHdoZW4gdGhleSB3aWxsIGFsbW9zdCBuZXZlciBiZSBtdWx0aS12YWx1 ZWQuDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQga2VlcCBtYW5hZ2VyIHNpbmdsZS12YWx1ZWQs IGFuZCBpZiBhIHNlcnZlciByZXF1aXJlcyBtdWx0aXBsZSBtYW5hZ2VyIHJlbGF0aW9uc2hpcHMg dGhpcyBjb3VsZCBiZSBhZGRlZCBhcyBhbiBleHRlbnNpb24uICBUaGUgc2luZ2xlLXZhbHVlZCBt YW5hZ2VyIHdvdWxkIGJlIHRoZWlyIHByaW1hcnkgYW5kIHRoZSBleHRlbmRlZCBhdHRyaWJ1dGUg d291bGQgYmUgYWxsIG9mIHRoZSBkb3R0ZWQgbGluZSBtYW5hZ2Vycy4gIEluIGZhY3QsIGlmIHRo ZXJlIGFyZSBtdWx0aXBsZSBtYW5hZ2VycyBpdCBtaWdodCBtYWtlIHNlbnNlIHRvIG1ha2UgdGhp cyBhIGNvbXBsZXggYXR0cmlidXRlIHRoYXQgY2FuIGZ1cnRoZXIgZGVzY3JpYmUgdGhlIHJlbGF0 aW9uc2hpcC4NClRvIG1lIHRoaXMgZmVlbHMgbGlrZSBpdCBpcyBsaW5lIHdpdGggdGhlIDgwLzIw IHJ1bGUgb2YgdGh1bWIgdGhhdCB3ZSBoYXZlIGJlZW4gdXNpbmcgd2hlbiBjb21pbmcgdXAgd2l0 aCB0aGlzIHNwZWMuDQoNCkZyb206IExlaWYgSm9oYW5zc29uIFttYWlsdG86bGVpZmpAbW50LnNl XQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMDYsIDIwMTUgMTA6NTUgQU0NClRvOiBJYW4gR2xhemVy DQpDYzogUGhpbCBIdW50OyBQYXRyaWNrIFJhZHRrZTsgU0NJTSBXRzsgTW9ydGV6YSBBbnNhcmk7 IE1pY2hhZWwgRnJvc3Q7IEtlbGx5IEdyaXp6bGUNClN1YmplY3Q6IFJlOiBbc2NpbV0gTWFuYWdl ciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0aW9uDQoNCg0KDQo2IG1haiAyMDE1IGtsLiAxNzo0 MyBza3JldiBJYW4gR2xhemVyIDxpZ2xhemVyQHNhbGVzZm9yY2UuY29tPG1haWx0bzppZ2xhemVy QHNhbGVzZm9yY2UuY29tPj46DQpJIGFtIGFnYWluc3QgY2hhbmdpbmcgbWFuYWdlciB0byBiZSBt dWx0aS12YWx1ZWQuIEkndmUgYnVpbHQgMyB1c2VyIHByb3Zpc2lvbmluZyBlbmdpbmVzIGFuZCBo YXZlIG5ldmVyIHNlZW4gYSBjYXNlIHdoZXJlIG1hbmFnZXIgaXMgbXVsdGktdmFsdWVkLiBJZiB5 b3UgaGF2ZSBhIG1hdHJpeC1lZCBvcmdhbml6YXRpb24gd2hlcmUgdGhlcmUgYXJlIGRvdHRlZCBs aW5lIHJlbGF0aW9uc2hpcHMsIHRoZW4gSSByZWNvbW1lbmQgYW4gZXh0ZW5zaW9uLiBCdXQgd2Ug b3VnaHQgdG8ga2VlcCBTQ0lNIGZvY3VzZWQgb24gdGhlIG1haW5zdHJlYW0gc2NlbmFyaW8gd2hl cmUgYSBwZXJzb24gaGFzIGEgc2luZ2xlIG1hbmFnZXIuDQoNCisxIChhcyBpbmRpdmlkdWFsKQ0K DQoNCg0KT24gV2VkLCBNYXkgNiwgMjAxNSBhdCAxMjoyNCBBTSwgUGhpbCBIdW50IDxwaGlsLmh1 bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCjxBcyBJ bmRpdmlkdWFsPg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHdlIGRvLiAgRG90dGVkIGxpbmUg YW5kIG11bHRpLXJlcG9ydGluZyByZWxhdGlvbnNoaXBzIGFyZSBhIHJlYWxpdHkgZm9yIG1hbnkg ZW50ZXJwcmlzZSBvcmdhbml6YXRpb25zLiAgQXQgbGVhc3Qgb25lIChvciBtb3JlKSBvZiBvdXIg aW1wbGVtZW50YXRpb25zIGlzIG11bHRpLXZhbHVlZC4gVGhpcyB3YXMgYWxzbyByYWlzZWQgdG8g bWUgYXMgYW4gaXNzdWUuDQoNCjxBcyBFZGl0b3I+DQpJIHRoaW5rIHRoZSByZWFsaXR5IGlzIHRo YXQgd2XigJlsbCBhbGwgcnVuIGludG8gZW50ZXJwcmlzZXMgd2FudGluZyBtdWx0aS12YWx1ZWQg bWFuYWdlcnMgc29vbmVyIG9yIGxhdGVyLiAgSGF2aW5nIGl0IG11bHRpLXZhbHVlZCBkb2VzbuKA mXQgbWVhbiB5b3UgaGF2ZSB0byBzdXBwb3J0IG11bHRpcGxlIHZhbHVlcy4gIEJ1dCB0aGUgaW1w b3J0YW50IHRoaW5nIGlzIHRoYXQgU0NJTSBwYXJzZXJzIHdpbGwgbmVlZCB0byBleHBlY3QgYW4g YXJyYXkuDQoNCk1heWJlIHdlIG5lZWQgYSBnZW5lcmFsIG5vdGUgdGhhdCBwYXJzZXJzIHNob3Vs ZCBhY2NlcHQgYSBzaW5nbGUgdmFsdWUgSlNPTiBvYmplY3QgZXZlbiB3aGVuIGFuIGF0dHJpYnV0 ZSBpcyBtdWx0aS12YWx1ZWQgKGZvciBhbnkgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZSkuICBUaGlz IHdvdWxkIG1ha2UgdGhlIGlzc3VlIG5vbi1icmVha2luZyBmb3IgY2xpZW50cyAod2hvIHRoaW5r IGFueSBhdHRyaWJ1dGUgaXMgc2luZ2xlLXZhbHVlZCkuICBBcyBmb3Igc2VydmVycywgaXQgc2Vl bXMgdG8gbWUgd2UgaGF2ZSBhIGNvbXBhdGliaWxpdHkgaXNzdWUgZHVlIHRvIHRoZSBzcGVjIGlu Y29uc2lzdGVuY3kgKHdoaWxlIGRlZmluaXRpb24gaXMgc2luZ2xlLXZhbHVlLCBleGFtcGxlcyBh cmUgbXVsdGktdmFsdWVkKS4gVGhhdCBtZWFucyByZWdhcmRsZXNzIG9mIG91ciBkZWNpc2lvbnMg c29tZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSB1cGRhdGVkLg0KDQpQaGlsDQoNCkBpbmRlcGVu ZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0K T24gTWF5IDUsIDIwMTUsIGF0IDI6MTQgUE0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgPG1v cmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4gd3JvdGU6DQoNClNw ZWFraW5nIGFzIGFuIGluZGl2aWR1YWwg4oCTIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJZE0gc3lz dGVtIHRoYXQgaGFzIG11bHRpdmFsdWVkIOKAnG1hbmFnZXLigJ0uIEluIGFkZGl0aW9uIGluIG1h bnkgY2FzZXMgYSBtdWx0aXZhbHVlZCBtYW5hZ2VyIGJyYWtlcyBtYW55IGFwcGxpY2F0aW9ucyBh cyB0aGUgcmVwb3J0aW5nIGhpZXJhcmNoeSBpcyBhc3N1bWVkIHRvIGJlIGEgdHJlZSBzdHJ1Y3R1 cmUgd2l0aCBhIG9uZSB0byBtYW55IHJlbGF0aW9uc2hpcCBub3QgbWFueSB0byBtYW55LiBVbmxl c3Mgc29tZW9uZSBoYXMgYSBzb2xpZCB1c2UgY2FzZSBmb3IgdHVybmluZyB0aGlzIGludG8gYSBt dWx0aXZhbHVlZCBhdHRyaWJ1dGUsIG15IHZvdGUgYXMgb25lIG9mIHRoZSBpbXBsZW1lbnRvcnMg aXMgdG8gZml4IHRoZSBleGFtcGxlIGFuZCBsZWF2ZSBpdCBhcyBzaW5nbGUgdmFsdWVkLg0KDQoN CkNoZWVycywNCk1vcnRlemENCg0KRnJvbTogUGF0cmljayBSYWR0a2UgPHBhdHJpY2sucmFkdGtl QGppdmVzb2Z0d2FyZS5jb208bWFpbHRvOnBhdHJpY2sucmFkdGtlQGppdmVzb2Z0d2FyZS5jb20+ Pg0KRGF0ZTogTW9uZGF5LCBNYXkgNCwgMjAxNSBhdCA0OjEwIFBNDQpUbzogUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiwgS2VsbHkg R3JpenpsZSA8a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxl QHNhaWxwb2ludC5jb20+Pg0KQ2M6ICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3Jn PiIgPHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+PiwgTWljaGFlbCBGcm9zdCA8 bWljaGFlbC5mcm9zdEBvcmFjbGUuY29tPG1haWx0bzptaWNoYWVsLmZyb3N0QG9yYWNsZS5jb20+ Pg0KU3ViamVjdDogUmU6IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rp b24NCg0KSXMgaXQgdG9vIGxhdGUgaW4gdGhlIHByb2Nlc3MgdG8gbWFrZSB0aGUgYXR0cmlidXRl IG5hbWUgcGx1cmFsICjigJxtYW5hZ2Vyc+KAnSk/IEFsbCB0aGUgb3RoZXIgbXVsdGlWYWx1ZWQg YXR0cmlidXRlcyBJIHNhdyBpbiBjb3JlLXNjaGVtYSB1c2UgdGhlIHBsdXJhbCBmb3JtIGZvciB0 aGUgYXR0cmlidXRlIG5hbWUuDQoNCkZyb206IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkRhdGU6IE1vbmRheSwgTWF5IDQsIDIw MTUgYXQgNDowNCBQTQ0KVG86IEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4NCkNjOiBNaWNoYWVsIEZy b3N0IDxtaWNoYWVsLmZyb3N0QG9yYWNsZS5jb208bWFpbHRvOm1pY2hhZWwuZnJvc3RAb3JhY2xl LmNvbT4+LCBKaXZlIElUIDxwYXRyaWNrLnJhZHRrZUBqaXZlc29mdHdhcmUuY29tPG1haWx0bzpw YXRyaWNrLnJhZHRrZUBqaXZlc29mdHdhcmUuY29tPj4sIFNDSU0gV0cgPHNjaW1AaWV0Zi5vcmc8 bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzY2ltXSBNYW5hZ2VyIGF0dHJp YnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb24NCg0KVGhlcmUgYXJlIGEgY291cGxlIG9mIGNoYW5nZXMg ZnJvbSB0aGUgSUVTRyByZXZpZXcgY29taW5nIHRvIGNvcmUtc2NoZW1hIChmb3Igb3RoZXIgcmVh c29ucyAtIGVtYWlscyB0byBmb2xsb3cpLg0KDQpXaXRoIHJlZ2FyZHMgdG8gdGhpcyBpc3N1ZSwg SSBwcm9wb3NlIHRoYXQgdGhlIG5leHQgdXBkYXRlIG1ha2Ug4oCcbWFuYWdlcuKAnSBhIG11bHRp LXZhbHVlZCBhdHRyaWJ1dGUgc28gdGhhdCBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGV4YW1w bGVzIGFuZCB0byBjb3JyZWN0IHRoZSBhcHBhcmVudCBpbmNvbnNpc3RlbmN5IGluIHRoZSBkcmFm dC4NCg0KSWYgdGhlcmUgYXJlIGFueSBzdHJvbmcgb2JqZWN0aW9ucywgcGxlYXNlIHJlc3BvbmQg YW5kIGRpc2N1c3MuDQoNClRoYW5rcywNCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3Lmlu ZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBBcHIgMzAsIDIw MTUsIGF0IDE6NTAgUE0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNv bTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQoNCkl0IGxvb2tz IGxpa2UgdGhpcyBnb3QgY2hhbmdlZCBiYWNrIGluIE9jdG9iZXIgaW4gcmV2aXNpb24gMTIgb2Yg dGhlIGNvcmUgc2NoZW1hIGRvYy4NCg0KICAgRHJhZnQgMTIgLSBQSCAtIE5pdHMgLyBDb3JyZWN0 aW9ucw0KDQogICAgICAuLi4NCg0KICAgICAgQ29ycmVjdGVkIGVudGVycHJpc2UgVXNlciBtYW5h Z2VyIGF0dHJpYnV0ZSB0byB1c2Ugc3ViLWF0dHJpYnV0ZQ0KICAgICAgdmFsdWUgYW5kIG1ha2Ug bXVsdGktdmFsdWVkDQoNCkkgaGFkbuKAmXQgcmVhbGl6ZWQgdGhhdCB0aGlzIGNoYW5nZSB3ZW50 IGluLiAgVXAgdW50aWwgdGhlbiBtYW5hZ2VyIGhhZCBiZWVuIHNpbmdsZS12YWx1ZWQgc2luY2Ug U0NJTSAxLjAuICBJZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCB0aGlzIGNoYW5nZSBzaG91bGQg c3RheSwgdGhlbiBpdCBzZWVtcyBsaWtlIHdlIG5lZWQgdG8gdXBkYXRlIHNlY3Rpb24gNC4zLg0K DQpSZWdhcmRpbmcgdGhlIGZhY3QgdGhhdCDigJxyZXF1aXJlZOKAnSBpcyBmYWxzZSBmb3IgdGhl IOKAnHZhbHVl4oCdIGFuZCDigJwkcmVm4oCdIHN1Yi1hdHRyaWJ1dGVzLCB0aGlzIGlzIGNvbnNp c3RlbnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgYXR0cmlidXRlIGRlZmluaXRpb25zIHRoYXQgYXJl IHJlZmVyZW5jZXMuICBJIGFncmVlIHdpdGggeW91LCBQYXRyaWNrLCB0aGF0IHRoZXNlIHNob3Vs ZCBiZSByZXF1aXJlZC4NCg0KLS1LZWxseQ0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAxNSAyOjIxIFBN DQpUbzogTWljaGFlbCBGcm9zdA0KQ2M6IEtlbGx5IEdyaXp6bGU7IFBhdHJpY2sgUmFkdGtlOyBT Q0lNIFdHDQpTdWJqZWN0OiBSZTogW3NjaW1dIE1hbmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3Vn Z2VzdGlvbg0KDQpBZ3JlZWQuDQoNCldpbGwgbmVlZCBjb25zZW5zdXMvZGlyZWN0aW9uIGZyb20g dGhlIGNoYWlycyBvbiB0aGlzIGFuZCBhbG9uZyB3aXRoIHRoZSBvdGhlciBpc3N1ZSAoNDAxLzQw My81MDEgc3RhdHVzIGNvZGUgY2xhcmlmaWNhdGlvbikuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50 aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24g QXByIDMwLCAyMDE1LCBhdCAxMTo0MiBBTSwgTWljaGFlbCBGcm9zdCA8bWljaGFlbC5mcm9zdEBv cmFjbGUuY29tPG1haWx0bzptaWNoYWVsLmZyb3N0QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSXQg aXMgbXVsdGktdmFsdWVkIGluIHRoZSBleGFtcGxlIGluIDguMyBhbmQgaW4gdGhlIHNjaGVtYSBv biBwYWdlIDYwLCBhbmQgaW4gb3VyIGltcGxlbWVudGF0aW9uLiAgSSB0aGluayBvbmx5IHRoZSB0 ZXh0IGluIHNlY3Rpb24gNC4zIHJlZmVycyB0byBtYW5hZ2VyIGFzIHNpbmd1bGFyLg0KDQotbXJm DQoNCkZyb206IEtlbGx5IEdyaXp6bGUgW21haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5j b21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMTUgMTA6MjggQU0NClRvOiBQaGlsIEh1 bnQNCkNjOiBQYXRyaWNrIFJhZHRrZTsgU0NJTSBXRw0KU3ViamVjdDogUmU6IFtzY2ltXSBNYW5h Z2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb24NCg0KRG9lcyBhbnlvbmUgaGF2ZSBhbnkg c3Ryb25nIG9waW5pb25zIGFib3V0IG1ha2luZyBtYW5hZ2VyIG11bHRpLXZhbHVlZCBvciBsZWF2 aW5nIGl0IGFzLWlzPw0KDQpFaXRoZXIgd2F5IHdlIHNob3VsZCBwcm9iYWJseSBjbGVhbiB1cCB0 aGUgdGV4dCBpbiBzZWN0aW9uIDQuMyBhbmQgdGhlIHNjaGVtYSBkZWZpbml0aW9uLg0KDQoNCkZy b206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVGh1cnNk YXksIEFwcmlsIDMwLCAyMDE1IDEwOjI4IEFNDQpUbzogS2VsbHkgR3JpenpsZQ0KQ2M6IFBhdHJp Y2sgUmFkdGtlOyBTQ0lNIFdHDQpTdWJqZWN0OiBSZTogTWFuYWdlciBhdHRyaWJ1dGUgd29yZGlu ZyBzdWdnZXN0aW9uDQoNCkkgcmVjYWxsIHlvdXIgY29tbWVudCBhbmQgZ2l2ZW4gbGFjayBvZiBp bnB1dCBhdCB0aGUgdGltZSwgaXQgd2FzIGNsZWFyIHRoZXJlIHdhcyBubyBjb25zZW5zdXMgZm9y IGNoYW5nZS4gSSBoYWQgdG8gbGVhdmUgaXQgYXMgaXMgZGVzcGl0ZSB0aGlua2luZyBpdCBuZWVk ZWQgdG8gYmUgbXVsdGktdmFsdWVkLg0KDQpQaGlsDQoNCk9uIEFwciAzMCwgMjAxNSwgYXQgMDY6 NDEsIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2Vs bHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQpJIGhhZCBmb3Jnb3R0ZW4gYWJvdXQg dGhhdC4gIFRoZSBtb3N0IGRpc2N1c3Npb24gdGhhdCBJIGZvdW5kIHdhcyBpbiB0aGlzIGVtYWls IC0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NjaW0vY3VycmVudC9tc2cw MjAwNy5odG1sLg0KDQogICBOb3RlLCB0aGUgc2NoZW1hIGFsc28gbmVlZHMgdG8gYmUgdXBkYXRl ZC4gSXQgbG9va3MgbGlrZSBpdCBzaG91bGQgYmUgbXVsdGktdmFsdWVkDQogIHNpbmNlIG1hbnkg b3JncyBoYXZlIHBlb3BsZSB3aXRoIG11bHRpcGxlIHJlcG9ydGluZyByZWxhdGlvbnNoaXBzLg0K DQpJIGRvbuKAmXQgcmVtZW1iZXIgZXZlciBkaXNjdXNzaW5nIHRoaXMgYW55IGZ1cnRoZXIgb3Ig aWYgd2UgYWNoaWV2ZWQgY29uc2Vuc3VzIG9uIGNoYW5naW5nIHRoaXMuICBUaGUgZW1haWwgdGhy ZWFkIGRvZXNu4oCZdCBoYXZlIGFueSBtb3JlIGRpc2N1c3Npb24uDQoNCknigJltIG5vdCBzdXJl IHRoYXQgSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIG11bHRpdmFsdWVkLiAgSWYgYW55dGhp bmcgZWxzZSwgSSB3b3VsZCBuZXZlciB3aXNoIG11bHRpcGxlIG1hbmFnZXJzIHVwb24gYW55b25l LiA7KSAgQmVpbmcgc2VyaW91cywgdGhvdWdoLCB0aGlzIG1pZ2h0IGZpdCBiZXR0ZXIgYXMgYSBz ZWNvbmQgYXR0cmlidXRlIHRoYXQgZGVzY3JpYmVzIG90aGVyIHJlcG9ydGluZyByZWxhdGlvbnNo aXBzLg0KDQpBbnlvbmUgZWxzZSByZW1lbWJlciB0aGlzPw0KDQpGcm9tOiBQaGlsIEh1bnQgW21h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIw MTUgNjo0MSBQTQ0KVG86IEtlbGx5IEdyaXp6bGUNCkNjOiBQYXRyaWNrIFJhZHRrZTsgU0NJTSBX Rw0KU3ViamVjdDogUmU6IE1hbmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbg0KDQpJ IGJlbGlldmUgSSByYWlzZWQgdGhpcyBpc3N1ZSBiZWZvcmUgYW5kIHRoZSBjb25zZW5zdXMgd2Fz IHRvIGxlYXZlIGl0LiAgTWF5YmUgSSBhbSBtaXN0YWtlbj8NCg0KUGhpbA0KDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20v Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpP biBBcHIgMjksIDIwMTUsIGF0IDQ6MDYgUE0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVA c2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6 DQoNClBhdHJpY2sg4oCmIHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLg0KDQpJIHRoaW5rIHRoYXQg dGhlIHNjaGVtYSBzZWN0aW9uIGlzIGluY29ycmVjdC4gIFRoZSAkcmVmIGFuZCB2YWx1ZSBhcmUg cmVxdWlyZWQgYW5kIG1hbmFnZXIgaXMgc3RpbGwgc2luZ2xlIHZhbHVlZC4gIEkgdGhpbmsgdGhl IHRleHQgaW4gNC4zIHNob3VsZCBzYXk6DQoNCm1hbmFnZXINCg0KICAgICAgVGhlIHVzZXIncyBt YW5hZ2VyLiAgQSBjb21wbGV4IHR5cGUgdGhhdCBvcHRpb25hbGx5IGFsbG93cyBzZXJ2aWNlDQoN CiAgICAgIHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5IGJ5 IHJlZmVyZW5jaW5nIHRoZQ0KDQogICAgICAiaWQiIGF0dHJpYnV0ZSBvZiBhbm90aGVyIFVzZXIu DQoNClBoaWwsIGRvIHlvdSBhZ3JlZT8NCg0KLS1LZWxseQ0KDQpGcm9tOiBzY2ltIFttYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF0cmljayBSYWR0a2UNClNlbnQ6 IEZyaWRheSwgQXByaWwgMjQsIDIwMTUgNTo0NyBQTQ0KVG86IFNDSU0gV0cNClN1YmplY3Q6IFtz Y2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb24NCg0KVGhlcmUgYXJlIGEg Y291cGxlIGFzcGVjdHMgb2YgdGhlIOKAnG1hbmFnZXLigJ0gYXR0cmlidXRlIHRoYXQgc2VlbSBp bmNvbnNpc3RlbnQuDQoNCkluIDQuMyBFbnRlcnByaXNlIFVzZXIgU2NoZW1hIGV4dGVuc2lvbiBp dCBzYXlzDQoibWFuYWdlcg0KDQogICAgICBUaGUgdXNlcidzIG1hbmFnZXIuICBBIGNvbXBsZXgg dHlwZSB0aGF0IG9wdGlvbmFsbHkgYWxsb3dzIHNlcnZpY2UNCg0KICAgICAgcHJvdmlkZXJzIHRv IHJlcHJlc2VudCBvcmdhbml6YXRpb25hbCBoaWVyYXJjaHkgYnkgcmVmZXJlbmNpbmcgdGhlDQoN CiAgICAgICJpZCIgYXR0cmlidXRlIG9mIGFub3RoZXIgVXNlci4NCg0KDQoNCiAgICAgIHZhbHVl ICBUaGUgImlkIiBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNlbnRpbmcgdGhlIHVzZXIncw0K DQogICAgICAgICBtYW5hZ2VyLiAgUkVDT01NRU5ERUQuDQoNCg0KDQogICAgICAkcmVmICBUaGUg VVJJIG9mIHRoZSBTQ0lNIHJlc291cmNlIHJlcHJlc2VudGluZyB0aGUgVXNlcidzDQoNCiAgICAg ICAgIG1hbmFnZXIuICBSRUNPTU1FTkRFRC4NCuKAnA0KVG8gbWUgdGhhdCBzYXlzIHRoYXQgYSB1 c2VyIG1heSBoYXZlIGEgc2luZ2xlIG1hbmFnZXIsIGFuZCDigJh2YWx1ZeKAmSBhbmQg4oCYJHJl ZuKAmSBhdHRyaWJ1dGVzIGFyZSBub3QgcmVxdWlyZWQuDQoNCkhvd2V2ZXIgaW4gdGhlIFNjaGVt YSBzZWN0aW9uLCBtYW5hZ2VyIGlzIGxpc3RlZCBhcyAibXVsdGlWYWx1ZWQ6IHRydWXigJ0gYW5k IHRob3VnaCBzdWJBdHRyaWJ1dGVzIG9mIOKAnCRyZWbigJ0gYW5kIOKAnHZhbHVl4oCdIGhhdmUg 4oCccmVxdWlyZWQ6ZmFsc2XigJ0gdGhlIGRlc2NyaXB0aW9uIGF0dHJpYnV0ZSBzYXlzIGVhY2gg aXMgcmVxdWlyZWQuDQoNCklmIOKAnHZhbHVl4oCdIGFuZCDigJwkcmVm4oCdIGFyZW7igJl0IHJl cXVpcmVkLCBjYW4gdGhlIE1hbmFnZXIgc2NoZW1hIGRlc2NyaXB0aW9uIGJlIGFkanVzdGVkPw0K U2luY2UgbWFuYWdlciBpcyBtdWx0aS12YWx1ZWQsIGNhbiBzZWN0aW9uIDQuMyBiZSB1cGRhdGVk IHRvIHNheS4gIlRoZSB1c2VyJ3MgbWFuYWdlcnMuICBBIG11bHRpLXZhbHVlZCBjb21wbGV4IHR5 cGUgdGhhdOKApuKAnSAgT3RoZXJ3aXNlLCBhdCBmaXJzdCByZWFkIChvciBmb3IgYW55b25lIGNv bWluZyBmcm9tIFNDSU0gMS4xKSBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IGl0IGhhcyBiZWNvbWUg bXVsdGktdmFsdWVkLg0KDQpUaGFua3MsDQoNClBhdHJpY2sNCg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QN CnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3Jn PG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zY2ltDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERpcmVjdG9yLCBJZGVudGl0 eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBt YWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg== --_000_BN1PR04MB3928DB41F838D3382B4A8B1E2D00BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIElhbi4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hpbGUgbXVsdGlwbGUgbWFuYWdlcnMg aXMgcG9zc2libGUsIEkgaGF2ZSBuZXZlciBzZWVuIGl0IGluIGFueSBzeXN0ZW0gdGhhdCBJIGhh dmUgZGVhbHQgd2l0aCDigKYgYW5kIEkgaGF2ZSBzZWVuIGEgbG90LiZuYnNwOyBJdCBmZWVscyBs aWtlIHdlIHdvdWxkIGJlIHBlbmFsaXppbmcgdGhlIG1ham9yaXR5DQogYnkgbWFraW5nIGNsaWVu dHMgaGF2ZSB0byBkZWFsIHdpdGggbXVsdGlwbGUgdmFsdWVzIHdoZW4gdGhleSB3aWxsIGFsbW9z dCBuZXZlciBiZSBtdWx0aS12YWx1ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgd2Ugc2hvdWxk IGtlZXAgbWFuYWdlciBzaW5nbGUtdmFsdWVkLCBhbmQgaWYgYSBzZXJ2ZXIgcmVxdWlyZXMgbXVs dGlwbGUgbWFuYWdlciByZWxhdGlvbnNoaXBzIHRoaXMgY291bGQgYmUgYWRkZWQgYXMgYW4gZXh0 ZW5zaW9uLiZuYnNwOyBUaGUgc2luZ2xlLXZhbHVlZA0KIG1hbmFnZXIgd291bGQgYmUgdGhlaXIg cHJpbWFyeSBhbmQgdGhlIGV4dGVuZGVkIGF0dHJpYnV0ZSB3b3VsZCBiZSBhbGwgb2YgdGhlIGRv dHRlZCBsaW5lIG1hbmFnZXJzLiZuYnNwOyBJbiBmYWN0LCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUg bWFuYWdlcnMgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBtYWtlIHRoaXMgYSBjb21wbGV4IGF0dHJp YnV0ZSB0aGF0IGNhbiBmdXJ0aGVyIGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gbWUgdGhpcyBmZWVscyBsaWtlIGl0IGlzIGxpbmUg d2l0aCB0aGUgODAvMjAgcnVsZSBvZiB0aHVtYiB0aGF0IHdlIGhhdmUgYmVlbiB1c2luZyB3aGVu IGNvbWluZw0KIHVwIHdpdGggdGhpcyBzcGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExlaWYgSm9o YW5zc29uIFttYWlsdG86bGVpZmpAbW50LnNlXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgTWF5IDA2LCAyMDE1IDEwOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBJYW4gR2xhemVyPGJyPg0K PGI+Q2M6PC9iPiBQaGlsIEh1bnQ7IFBhdHJpY2sgUmFkdGtlOyBTQ0lNIFdHOyBNb3J0ZXphIEFu c2FyaTsgTWljaGFlbCBGcm9zdDsgS2VsbHkgR3JpenpsZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NjaW1dIE1hbmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KNiBtYWogMjAxNSBrbC4gMTc6NDMgc2tyZXYgSWFuIEds YXplciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20iPmlnbGF6ZXJA c2FsZXNmb3JjZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYWdhaW5zdCBjaGFuZ2luZyBtYW5hZ2Vy IHRvIGJlIG11bHRpLXZhbHVlZC4gSSd2ZSBidWlsdCAzIHVzZXIgcHJvdmlzaW9uaW5nIGVuZ2lu ZXMgYW5kIGhhdmUgbmV2ZXIgc2VlbiBhIGNhc2Ugd2hlcmUgbWFuYWdlciBpcyBtdWx0aS12YWx1 ZWQuIElmIHlvdSBoYXZlIGEgbWF0cml4LWVkIG9yZ2FuaXphdGlvbiB3aGVyZSB0aGVyZSBhcmUg ZG90dGVkIGxpbmUgcmVsYXRpb25zaGlwcywgdGhlbiBJIHJlY29tbWVuZA0KIGFuIGV4dGVuc2lv bi4gQnV0IHdlIG91Z2h0IHRvIGtlZXAgU0NJTSBmb2N1c2VkIG9uIHRoZSBtYWluc3RyZWFtIHNj ZW5hcmlvIHdoZXJlIGEgcGVyc29uIGhhcyBhIHNpbmdsZSBtYW5hZ2VyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiYjNDM7MSAoYXMgaW5kaXZpZHVhbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDYsIDIwMTUgYXQgMTI6MjQgQU0sIFBoaWwg SHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7QXMgSW5kaXZpZHVhbCZndDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgd2UgZG8uJm5ic3A7IERvdHRlZCBsaW5lIGFuZCBtdWx0aS1yZXBvcnRpbmcgcmVsYXRp b25zaGlwcyBhcmUgYSByZWFsaXR5IGZvciBtYW55IGVudGVycHJpc2Ugb3JnYW5pemF0aW9ucy4m bmJzcDsgQXQgbGVhc3Qgb25lIChvciBtb3JlKSBvZiBvdXIgaW1wbGVtZW50YXRpb25zIGlzIG11 bHRpLXZhbHVlZC4gVGhpcyB3YXMgYWxzbyByYWlzZWQgdG8gbWUgYXMgYW4gaXNzdWUuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O0FzIEVk aXRvciZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgdGhlIHJlYWxpdHkgaXMgdGhhdCB3ZeKAmWxsIGFsbCBydW4gaW50byBlbnRl cnByaXNlcyB3YW50aW5nIG11bHRpLXZhbHVlZCBtYW5hZ2VycyBzb29uZXIgb3IgbGF0ZXIuJm5i c3A7IEhhdmluZyBpdCBtdWx0aS12YWx1ZWQgZG9lc27igJl0IG1lYW4geW91IGhhdmUgdG8gc3Vw cG9ydCBtdWx0aXBsZSB2YWx1ZXMuJm5ic3A7IEJ1dCB0aGUgaW1wb3J0YW50IHRoaW5nIGlzIHRo YXQgU0NJTSBwYXJzZXJzIHdpbGwgbmVlZA0KIHRvIGV4cGVjdCBhbiBhcnJheS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+TWF5YmUgd2Ug bmVlZCBhIGdlbmVyYWwgbm90ZSB0aGF0IHBhcnNlcnMgc2hvdWxkIGFjY2VwdCBhIHNpbmdsZSB2 YWx1ZSBKU09OIG9iamVjdCBldmVuIHdoZW4gYW4gYXR0cmlidXRlIGlzIG11bHRpLXZhbHVlZCAo Zm9yIGFueSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlKTwvYj4uJm5ic3A7IFRoaXMgd291bGQgbWFr ZSB0aGUgaXNzdWUgbm9uLWJyZWFraW5nIGZvciBjbGllbnRzICh3aG8gdGhpbmsgYW55IGF0dHJp YnV0ZQ0KIGlzIHNpbmdsZS12YWx1ZWQpLiZuYnNwOyBBcyBmb3Igc2VydmVycywgaXQgc2VlbXMg dG8gbWUgd2UgaGF2ZSBhIGNvbXBhdGliaWxpdHkgaXNzdWUgZHVlIHRvIHRoZSBzcGVjIGluY29u c2lzdGVuY3kgKHdoaWxlIGRlZmluaXRpb24gaXMgc2luZ2xlLXZhbHVlLCBleGFtcGxlcyBhcmUg bXVsdGktdmFsdWVkKS4gVGhhdCBtZWFucyByZWdhcmRsZXNzIG9mIG91ciBkZWNpc2lvbnMgc29t ZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0i X2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgNSwg MjAxNSwgYXQgMjoxNCBQTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmFuc2FyQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3BlYWtpbmcgYXMg YW4gaW5kaXZpZHVhbCDigJMgSSBhbSBub3QgYXdhcmUgb2YgYW55IElkTSBzeXN0ZW0gdGhhdCBo YXMgbXVsdGl2YWx1ZWQg4oCcbWFuYWdlcuKAnS4gSW4gYWRkaXRpb24gaW4gbWFueSBjYXNlcyBh IG11bHRpdmFsdWVkIG1hbmFnZXIgYnJha2VzIG1hbnkgYXBwbGljYXRpb25zIGFzIHRoZQ0KIHJl cG9ydGluZyBoaWVyYXJjaHkgaXMgYXNzdW1lZCB0byBiZSBhIHRyZWUgc3RydWN0dXJlIHdpdGgg YSBvbmUgdG8gbWFueSByZWxhdGlvbnNoaXAgbm90IG1hbnkgdG8gbWFueS4gVW5sZXNzIHNvbWVv bmUgaGFzIGEgc29saWQgdXNlIGNhc2UgZm9yIHR1cm5pbmcgdGhpcyBpbnRvIGEgbXVsdGl2YWx1 ZWQgYXR0cmlidXRlLCBteSB2b3RlIGFzIG9uZSBvZiB0aGUgaW1wbGVtZW50b3JzIGlzIHRvIGZp eCB0aGUgZXhhbXBsZSBhbmQgbGVhdmUgaXQNCiBhcyBzaW5nbGUgdmFsdWVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk1vcnRlemE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBh dHJpY2sgUmFkdGtlICZsdDs8YSBocmVmPSJtYWlsdG86cGF0cmljay5yYWR0a2VAaml2ZXNvZnR3 YXJlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhdHJpY2sucmFkdGtlQGppdmVzb2Z0d2FyZS5jb208 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1heSA0LCAyMDE1IGF0IDQ6MTAgUE08 YnI+DQo8Yj5UbzogPC9iPlBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Oywg S2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+Jmd0OywgTWlj aGFlbCBGcm9zdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuZnJvc3RAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1pY2hhZWwuZnJvc3RAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbc2NpbV0gTWFuYWdlciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0 aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXMgaXQgdG9vIGxhdGUgaW4gdGhlIHByb2Nl c3MgdG8gbWFrZSB0aGUgYXR0cmlidXRlIG5hbWUgcGx1cmFsICjigJxtYW5hZ2Vyc+KAnSk/IEFs bCB0aGUgb3RoZXIgbXVsdGlWYWx1ZWQgYXR0cmlidXRlcyBJIHNhdyBpbiBjb3JlLXNjaGVtYSB1 c2UgdGhlIHBsdXJhbCBmb3JtIGZvciB0aGUgYXR0cmlidXRlDQogbmFtZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIE1heSA0LCAyMDE1IGF0IDQ6MDQgUE08YnI+DQo8Yj5Ubzog PC9iPktlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxw b2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5rZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TWljaGFlbCBGcm9zdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1p Y2hhZWwuZnJvc3RAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhZWwuZnJvc3RAb3Jh Y2xlLmNvbTwvYT4mZ3Q7LCBKaXZlIElUICZsdDs8YSBocmVmPSJtYWlsdG86cGF0cmljay5yYWR0 a2VAaml2ZXNvZnR3YXJlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhdHJpY2sucmFkdGtlQGppdmVz b2Z0d2FyZS5jb208L2E+Jmd0OywgU0NJTSBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgYSBjb3VwbGUgb2YgY2hhbmdlcyBm cm9tIHRoZSBJRVNHIHJldmlldyBjb21pbmcgdG8gY29yZS1zY2hlbWEgKGZvciBvdGhlciByZWFz b25zIC0gZW1haWxzIHRvIGZvbGxvdykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldpdGggcmVnYXJkcyB0byB0aGlz IGlzc3VlLCBJIHByb3Bvc2UgdGhhdCB0aGUgbmV4dCB1cGRhdGUgbWFrZSDigJxtYW5hZ2Vy4oCd IGEgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZSBzbyB0aGF0IGl0IGlzIGNvbnNpc3RlbnQgd2l0aCB0 aGUgZXhhbXBsZXMgYW5kIHRvIGNvcnJlY3QgdGhlIGFwcGFyZW50DQogaW5jb25zaXN0ZW5jeSBp biB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHRoZXJlIGFyZSBhbnkgc3Ryb25nIG9iamVjdGlv bnMsIHBsZWFzZSByZXNwb25kIGFuZCBkaXNjdXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+T24gQXByIDMwLCAyMDE1LCBhdCAxOjUwIFBNLCBLZWxseSBHcml6emxlICZsdDs8 YSBocmVmPSJtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgbG9va3MgbGlrZSB0aGlzIGdvdCBjaGFuZ2VkIGJhY2sg aW4gT2N0b2JlciBpbiByZXZpc2lvbiAxMiBvZiB0aGUgY29yZSBzY2hlbWEgZG9jLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IERyYWZ0IDEyIC0gUEggLSBOaXRzIC8gQ29ycmVj dGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb3JyZWN0 ZWQgZW50ZXJwcmlzZSBVc2VyIG1hbmFnZXIgYXR0cmlidXRlIHRvIHVzZSBzdWItYXR0cmlidXRl PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSBhbmQgbWFrZSBtdWx0aS12YWx1ZWQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGFkbuKA mXQgcmVhbGl6ZWQgdGhhdCB0aGlzIGNoYW5nZSB3ZW50IGluLiZuYnNwOyBVcCB1bnRpbCB0aGVu IG1hbmFnZXIgaGFkIGJlZW4gc2luZ2xlLXZhbHVlZCBzaW5jZSBTQ0lNIDEuMC4mbmJzcDsgSWYg dGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgdGhpcyBjaGFuZ2Ugc2hvdWxkIHN0YXksDQogdGhlbiBp dCBzZWVtcyBsaWtlIHdlIG5lZWQgdG8gdXBkYXRlIHNlY3Rpb24gNC4zLiA8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZGluZyB0aGUg ZmFjdCB0aGF0IOKAnHJlcXVpcmVk4oCdIGlzIGZhbHNlIGZvciB0aGUg4oCcdmFsdWXigJ0gYW5k IOKAnCRyZWbigJ0gc3ViLWF0dHJpYnV0ZXMsIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBy ZXN0IG9mIHRoZSBhdHRyaWJ1dGUgZGVmaW5pdGlvbnMgdGhhdCBhcmUNCiByZWZlcmVuY2VzLiZu YnNwOyBJIGFncmVlIHdpdGggeW91LCBQYXRyaWNrLCB0aGF0IHRoZXNlIHNob3VsZCBiZSByZXF1 aXJlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi0tS2VsbHkNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMTUgMjoyMSBQ TTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBGcm9zdDxicj4NCjxiPkNjOjwvYj4gS2VsbHkgR3Jp enpsZTsgUGF0cmljayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtz Y2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFncmVlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldpbGwgbmVlZCBjb25zZW5zdXMvZGly ZWN0aW9uIGZyb20gdGhlIGNoYWlycyBvbiB0aGlzIGFuZCBhbG9uZyB3aXRoIHRoZSBvdGhlciBp c3N1ZSAoNDAxLzQwMy81MDEgc3RhdHVzIGNvZGUgY2xhcmlmaWNhdGlvbikuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29t LyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+T24gQXByIDMwLCAyMDE1LCBhdCAxMTo0MiBBTSwgTWljaGFlbCBGcm9zdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pY2hhZWwuZnJvc3RAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hh ZWwuZnJvc3RAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBpcyBtdWx0aS12YWx1ZWQgaW4gdGhlIGV4YW1w bGUgaW4gOC4zIGFuZCBpbiB0aGUgc2NoZW1hIG9uIHBhZ2UgNjAsIGFuZCBpbiBvdXIgaW1wbGVt ZW50YXRpb24uJm5ic3A7IEkgdGhpbmsgb25seSB0aGUgdGV4dCBpbiBzZWN0aW9uIDQuMyByZWZl cnMgdG8gbWFuYWdlciBhcw0KIHNpbmd1bGFyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LW1yZjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtlbGx5IEdyaXp6bGUgWzxh IGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMTUgMTA6MjggQU08YnI+DQo8Yj5Ubzo8L2I+IFBo aWwgSHVudDxicj4NCjxiPkNjOjwvYj4gUGF0cmljayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rp b248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG9lcyBhbnlvbmUgaGF2ZSBhbnkgc3Ryb25nIG9waW5p b25zIGFib3V0IG1ha2luZyBtYW5hZ2VyIG11bHRpLXZhbHVlZCBvciBsZWF2aW5nIGl0IGFzLWlz Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpFaXRoZXIgd2F5IHdlIHNob3VsZCBwcm9i YWJseSBjbGVhbiB1cCB0aGUgdGV4dCBpbiBzZWN0aW9uIDQuMyBhbmQgdGhlIHNjaGVtYSBkZWZp bml0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQg WzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEFwcmlsIDMwLCAyMDE1IDEwOjI4IEFNPGJyPg0KPGI+VG86PC9iPiBLZWxseSBHcml6emxl PGJyPg0KPGI+Q2M6PC9iPiBQYXRyaWNrIFJhZHRrZTsgU0NJTSBXRzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogTWFuYWdlciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0aW9uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SSByZWNhbGwgeW91ciBjb21tZW50IGFuZCBnaXZlbiBsYWNrIG9mIGlucHV0IGF0IHRoZSB0 aW1lLCBpdCB3YXMgY2xlYXIgdGhlcmUgd2FzIG5vIGNvbnNlbnN1cyBmb3IgY2hhbmdlLiBJIGhh ZCB0byBsZWF2ZSBpdCBhcyBpcyBkZXNwaXRlIHRoaW5raW5nIGl0IG5lZWRlZCB0byBiZSBtdWx0 aS12YWx1ZWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQpQaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEFwciAzMCwgMjAxNSwgYXQgMDY6NDEsIEtl bGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5j b20iIHRhcmdldD0iX2JsYW5rIj5rZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhh ZCBmb3Jnb3R0ZW4gYWJvdXQgdGhhdC4mbmJzcDsgVGhlIG1vc3QgZGlzY3Vzc2lvbiB0aGF0IEkg Zm91bmQgd2FzIGluIHRoaXMgZW1haWwgLQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NjaW0vY3VycmVudC9tc2cwMjAwNy5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2NpbS9jdXJyZW50L21z ZzAyMDA3Lmh0bWw8L2E+Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Ob3RlLCB0aGUgc2NoZW1hIGFsc28gbmVlZHMgdG8gYmUgdXBkYXRlZC4gSXQgbG9v a3MgbGlrZSBpdCBzaG91bGQgYmUgbXVsdGktdmFsdWVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgc2luY2Ug bWFueSBvcmdzIGhhdmUgcGVvcGxlIHdpdGggbXVsdGlwbGUgcmVwb3J0aW5nIHJlbGF0aW9uc2hp cHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGRvbuKAmXQgcmVtZW1iZXIgZXZlciBkaXNjdXNzaW5nIHRoaXMgYW55IGZ1cnRoZXIgb3Ig aWYgd2UgYWNoaWV2ZWQgY29uc2Vuc3VzIG9uIGNoYW5naW5nIHRoaXMuJm5ic3A7IFRoZSBlbWFp bCB0aHJlYWQgZG9lc27igJl0IGhhdmUgYW55IG1vcmUgZGlzY3Vzc2lvbi48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIG5vdCBzdXJl IHRoYXQgSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIG11bHRpdmFsdWVkLiZuYnNwOyBJZiBh bnl0aGluZyBlbHNlLCBJIHdvdWxkIG5ldmVyIHdpc2ggbXVsdGlwbGUgbWFuYWdlcnMgdXBvbiBh bnlvbmUuIDspJm5ic3A7IEJlaW5nIHNlcmlvdXMsIHRob3VnaCwgdGhpcw0KIG1pZ2h0IGZpdCBi ZXR0ZXIgYXMgYSBzZWNvbmQgYXR0cmlidXRlIHRoYXQgZGVzY3JpYmVzIG90aGVyIHJlcG9ydGlu ZyByZWxhdGlvbnNoaXBzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QW55b25lIGVsc2UgcmVtZW1iZXIgdGhpcz8NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwg SHVudCBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEFwcmlsIDI5LCAyMDE1IDY6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEtlbGx5IEdy aXp6bGU8YnI+DQo8Yj5DYzo8L2I+IFBhdHJpY2sgUmFkdGtlOyBTQ0lNIFdHPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkkgYmVsaWV2ZSBJIHJhaXNlZCB0aGlzIGlzc3VlIGJlZm9yZSBhbmQgdGhlIGNvbnNlbnN1cyB3 YXMgdG8gbGVhdmUgaXQuJm5ic3A7IE1heWJlIEkgYW0gbWlzdGFrZW4/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIg dGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ T24gQXByIDI5LCAyMDE1LCBhdCA0OjA2IFBNLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJt YWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VsbHku Z3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhdHJpY2sg4oCmIHRoYW5rcyBmb3IgdGhlIGZl ZWRiYWNrLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayB0aGF0IHRoZSBzY2hlbWEgc2VjdGlvbiBpcyBpbmNvcnJlY3QuJm5ic3A7 IFRoZSAkcmVmIGFuZCB2YWx1ZSBhcmUgcmVxdWlyZWQgYW5kIG1hbmFnZXIgaXMgc3RpbGwgc2lu Z2xlIHZhbHVlZC4mbmJzcDsgSSB0aGluayB0aGUgdGV4dCBpbiA0LjMgc2hvdWxkIHNheTo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5hZ2VyPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdXNlcidz IG1hbmFnZXIuJm5ic3A7IEEgY29tcGxleCB0eXBlIHRoYXQgb3B0aW9uYWxseSBhbGxvd3Mgc2Vy dmljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZXJzIHRvIHJlcHJlc2VudCBvcmdhbml6YXRpb25h bCBoaWVyYXJjaHkgYnkgcmVmZXJlbmNpbmcgPHM+dGhlPC9zPjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aWQmcXVvdDsgYXR0cmlidXRlIG9mPC9zcGFuPjwvcz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYW5vdGhl ciBVc2VyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGhpbCwgZG8geW91IGFncmVlPzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1LZWxseTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNj aW0gWzxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ UGF0cmljayBSYWR0a2U8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyNCwgMjAxNSA1 OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBTQ0lNIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzY2lt XSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVy ZSBhcmUgYSBjb3VwbGUgYXNwZWN0cyBvZiB0aGUg4oCcbWFuYWdlcuKAnSBhdHRyaWJ1dGUgdGhh dCBzZWVtIGluY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SW4gNC4zIEVudGVycHJpc2UgVXNlciBTY2hlbWEgZXh0ZW5zaW9uIGl0IHNheXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1hbmFnZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHVzZXIncyBt YW5hZ2VyLiZuYnNwOyBBIGNvbXBsZXggdHlwZSB0aGF0IG9wdGlvbmFsbHkgYWxsb3dzIHNlcnZp Y2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0aW9uYWwg aGllcmFyY2h5IGJ5IHJlZmVyZW5jaW5nIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWQmcXVv dDsgYXR0cmlidXRlIG9mIGFub3RoZXIgVXNlci48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSZuYnNwOyBUaGUgJnF1 b3Q7aWQmcXVvdDsgb2YgdGhlIFNDSU0gcmVzb3VyY2UgcmVwcmVzZW50aW5nIHRoZSB1c2VyJ3M8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFnZXIuJm5ic3A7IFJFQ09NTUVO REVELjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICRyZWYmbmJzcDsgVGhlIFVSSSBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXBy ZXNlbnRpbmcgdGhlIFVzZXInczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFu YWdlci4mbmJzcDsgUkVDT01NRU5ERUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ 4oCcPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBtZSB0 aGF0IHNheXMgdGhhdCBhIHVzZXIgbWF5IGhhdmUgYSBzaW5nbGUgbWFuYWdlciwgYW5kIOKAmHZh bHVl4oCZIGFuZCDigJgkcmVm4oCZIGF0dHJpYnV0ZXMgYXJlIG5vdCByZXF1aXJlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SG93ZXZlciBpbiB0aGUgU2NoZW1h IHNlY3Rpb24sIG1hbmFnZXIgaXMgbGlzdGVkIGFzICZxdW90O211bHRpVmFsdWVkOiB0cnVl4oCd IGFuZCB0aG91Z2ggc3ViQXR0cmlidXRlcyBvZiDigJwkcmVm4oCdIGFuZCDigJx2YWx1ZeKAnSBo YXZlIOKAnHJlcXVpcmVkOmZhbHNl4oCdIHRoZSBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUgc2F5cw0K IGVhY2ggaXMgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPklmIOKAnHZhbHVl4oCdIGFuZCDigJwkcmVm4oCdIGFyZW7igJl0IHJlcXVpcmVkLCBjYW4g dGhlIE1hbmFnZXIgc2NoZW1hIGRlc2NyaXB0aW9uIGJlIGFkanVzdGVkPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2luY2UgbWFuYWdlciBpcyBtdWx0aS12 YWx1ZWQsIGNhbiBzZWN0aW9uIDQuMyBiZSB1cGRhdGVkIHRvIHNheS4gJnF1b3Q7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHVzZXIncyBtYW5hZ2Vycy4mbmJzcDsgQSBt dWx0aS12YWx1ZWQNCiBjb21wbGV4IHR5cGUgdGhhdOKApuKAnSAmbmJzcDtPdGhlcndpc2UsIGF0 IGZpcnN0IHJlYWQgKG9yIGZvciBhbnlvbmUgY29taW5nIGZyb20gU0NJTSAxLjEpIGl0IGlzIG5v dCBvYnZpb3VzIHRoYXQgaXQgaGFzIGJlY29tZSBtdWx0aS12YWx1ZWQuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGF0cmljazwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z Y2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JYW4gR2xhemVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgMjAyIDI1NSAzMTY2PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXIiIHRhcmdldD0iX2JsYW5rIj5AaWdsYXplcjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB3928DB41F838D3382B4A8B1E2D00BN1PR04MB392namprd_-- From nobody Wed May 6 09:33:16 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AE11B2BF1 for ; Wed, 6 May 2015 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAafJtabQM26 for ; Wed, 6 May 2015 09:33:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CB81B2BDC for ; Wed, 6 May 2015 09:32:14 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t46GWCgB006778 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2015 16:32:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t46GWA86026541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2015 16:32:10 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t46GW9s8006096; Wed, 6 May 2015 16:32:09 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 May 2015 09:32:08 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-9C2C1668-248C-42EB-9FE4-F811CEEBE56F Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 6 May 2015 09:32:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> To: Kelly Grizzle X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Michael Frost , SCIM WG , Ian Glazer , Patrick Radtke , Leif Johansson , Morteza Ansari Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 16:33:12 -0000 --Apple-Mail-9C2C1668-248C-42EB-9FE4-F811CEEBE56F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20 We can use an extension (TBD) to support multiple relation types.=20 I just worry that others will have to support it.=20 Phil > On May 6, 2015, at 09:05, Kelly Grizzle wrot= e: >=20 > I agree with Ian. While multiple managers is possible, I have never seen i= t in any system that I have dealt with =E2=80=A6 and I have seen a lot. It f= eels like we would be penalizing the majority by making clients have to deal= with multiple values when they will almost never be multi-valued. > =20 > I agree that we should keep manager single-valued, and if a server require= s multiple manager relationships this could be added as an extension. The s= ingle-valued manager would be their primary and the extended attribute would= be all of the dotted line managers. In fact, if there are multiple manager= s it might make sense to make this a complex attribute that can further desc= ribe the relationship. > To me this feels like it is line with the 80/20 rule of thumb that we have= been using when coming up with this spec. > =20 > From: Leif Johansson [mailto:leifj@mnt.se]=20 > Sent: Wednesday, May 06, 2015 10:55 AM > To: Ian Glazer > Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; Kel= ly Grizzle > Subject: Re: [scim] Manager attribute wording suggestion > =20 > =20 >=20 > 6 maj 2015 kl. 17:43 skrev Ian Glazer : >=20 > I am against changing manager to be multi-valued. I've built 3 user provis= ioning engines and have never seen a case where manager is multi-valued. If y= ou have a matrix-ed organization where there are dotted line relationships, t= hen I recommend an extension. But we ought to keep SCIM focused on the mains= tream scenario where a person has a single manager. > =20 > +1 (as individual) >=20 >=20 > =20 > On Wed, May 6, 2015 at 12:24 AM, Phil Hunt wrote: > > My understanding is that we do. Dotted line and multi-reporting relations= hips are a reality for many enterprise organizations. At least one (or more= ) of our implementations is multi-valued. This was also raised to me as an i= ssue. > =20 > > I think the reality is that we=E2=80=99ll all run into enterprises wanting= multi-valued managers sooner or later. Having it multi-valued doesn=E2=80=99= t mean you have to support multiple values. But the important thing is that= SCIM parsers will need to expect an array. > =20 > Maybe we need a general note that parsers should accept a single value JSO= N object even when an attribute is multi-valued (for any multi-valued attrib= ute). This would make the issue non-breaking for clients (who think any att= ribute is single-valued). As for servers, it seems to me we have a compatib= ility issue due to the spec inconsistency (while definition is single-value,= examples are multi-valued). That means regardless of our decisions some ser= vers will have to be updated. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) = wrote: > =20 > Speaking as an individual =E2=80=93 I am not aware of any IdM system that h= as multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many cases a multiv= alued manager brakes many applications as the reporting hierarchy is assumed= to be a tree structure with a one to many relationship not many to many. Un= less someone has a solid use case for turning this into a multivalued attrib= ute, my vote as one of the implementors is to fix the example and leave it a= s single valued. > =20 > =20 > Cheers, > Morteza > =20 > From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM > To: Phil Hunt , Kelly Grizzle > Cc: "scim@ietf.org" , Michael Frost > Subject: Re: [scim] Manager attribute wording suggestion > =20 > Is it too late in the process to make the attribute name plural (=E2=80=9C= managers=E2=80=9D)? All the other multiValued attributes I saw in core-schem= a use the plural form for the attribute name. > =20 > From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM > To: Kelly Grizzle > Cc: Michael Frost , Jive IT , SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > =20 > There are a couple of changes from the IESG review coming to core-schema (= for other reasons - emails to follow). > =20 > With regards to this issue, I propose that the next update make =E2=80=9Cm= anager=E2=80=9D a multi-valued attribute so that it is consistent with the e= xamples and to correct the apparent inconsistency in the draft. > =20 > If there are any strong objections, please respond and discuss. > =20 > Thanks, > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Apr 30, 2015, at 1:50 PM, Kelly Grizzle w= rote: > =20 > It looks like this got changed back in October in revision 12 of the core s= chema doc. > =20 > Draft 12 - PH - Nits / Corrections > =20 > ... > =20 > Corrected enterprise User manager attribute to use sub-attribute > value and make multi-valued > =20 > I hadn=E2=80=99t realized that this change went in. Up until then manager= had been single-valued since SCIM 1.0. If there is consensus that this cha= nge should stay, then it seems like we need to update section 4.3. > =20 > Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for the =E2=80= =9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, this is consist= ent with the rest of the attribute definitions that are references. I agree= with you, Patrick, that these should be required. > =20 > --Kelly > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, April 30, 2015 2:21 PM > To: Michael Frost > Cc: Kelly Grizzle; Patrick Radtke; SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > =20 > Agreed. > =20 > Will need consensus/direction from the chairs on this and along with the o= ther issue (401/403/501 status code clarification). > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Apr 30, 2015, at 11:42 AM, Michael Frost wro= te: > =20 > It is multi-valued in the example in 8.3 and in the schema on page 60, and= in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. > =20 > -mrf > =20 > From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 > Sent: Thursday, April 30, 2015 10:28 AM > To: Phil Hunt > Cc: Patrick Radtke; SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion > =20 > Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? >=20 > Either way we should probably clean up the text in section 4.3 and the sch= ema definition. > =20 > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Thursday, April 30, 2015 10:28 AM > To: Kelly Grizzle > Cc: Patrick Radtke; SCIM WG > Subject: Re: Manager attribute wording suggestion > =20 > I recall your comment and given lack of input at the time, it was clear th= ere was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued.=20 >=20 > Phil >=20 > On Apr 30, 2015, at 06:41, Kelly Grizzle wro= te: >=20 > I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. > =20 > Note, the schema also needs to be updated. It looks like it should be m= ulti-valued > since many orgs have people with multiple reporting relationships. > =20 > I don=E2=80=99t remember ever discussing this any further or if we achieve= d consensus on changing this. The email thread doesn=E2=80=99t have any mor= e discussion. > =20 > I=E2=80=99m not sure that I agree that this should be multivalued. If any= thing else, I would never wish multiple managers upon anyone. ;) Being seri= ous, though, this might fit better as a second attribute that describes othe= r reporting relationships. > =20 > Anyone else remember this? > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Wednesday, April 29, 2015 6:41 PM > To: Kelly Grizzle > Cc: Patrick Radtke; SCIM WG > Subject: Re: Manager attribute wording suggestion > =20 > I believe I raised this issue before and the consensus was to leave it. M= aybe I am mistaken? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Apr 29, 2015, at 4:06 PM, Kelly Grizzle w= rote: > =20 > Patrick =E2=80=A6 thanks for the feedback. > =20 > I think that the schema section is incorrect. The $ref and value are requ= ired and manager is still single valued. I think the text in 4.3 should say= : > =20 > manager > The user's manager. A complex type that optionally allows service > providers to represent organizational hierarchy by referencing the > "id" attribute of another User. > =20 > Phil, do you agree? > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke > Sent: Friday, April 24, 2015 5:47 PM > To: SCIM WG > Subject: [scim] Manager attribute wording suggestion > =20 > There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D attribute that= seem inconsistent. > =20 > In 4.3 Enterprise User Schema extension it says > "manager > The user's manager. A complex type that optionally allows service > providers to represent organizational hierarchy by referencing the > "id" attribute of another User. > =20 > value The "id" of the SCIM resource representing the user's > manager. RECOMMENDED. > =20 > $ref The URI of the SCIM resource representing the User's > manager. RECOMMENDED. > =E2=80=9C > To me that says that a user may have a single manager, and =E2=80=98value=E2= =80=99 and =E2=80=98$ref=E2=80=99 attributes are not required. > =20 > However in the Schema section, manager is listed as "multiValued: true=E2=80= =9D and though subAttributes of =E2=80=9C$ref=E2=80=9D and =E2=80=9Cvalue=E2= =80=9D have =E2=80=9Crequired:false=E2=80=9D the description attribute says e= ach is required. > =20 > If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t requi= red, can the Manager schema description be adjusted? > Since manager is multi-valued, can section 4.3 be updated to say. "The use= r's managers. A multi-valued complex type that=E2=80=A6=E2=80=9D Otherwise= , at first read (or for anyone coming from SCIM 1.1) it is not obvious that i= t has become multi-valued. > =20 > Thanks, > =20 > Patrick > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 > =20 > =20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-9C2C1668-248C-42EB-9FE4-F811CEEBE56F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
 
We can use an extensi= on (TBD) to support multiple relation types. 

= I just worry that others will have to support it. 

Phil

On May 6, 2015, at 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.  While multiple managers is possible, I have= never seen it in any system that I have dealt with =E2=80=A6 and I have see= n a lot.  It feels like we would be penalizing the majority by making clients have to deal with multiple values when they will almost n= ever be multi-valued.

 

I agree that we should keep= manager single-valued, and if a server requires multiple manager relationsh= ips this could be added as an extension.  The single-valued manager would be their primary and the extended attribute would be all of t= he dotted line managers.  In fact, if there are multiple managers it mi= ght make sense to make this a complex attribute that can further describe th= e relationship.

To me this feels like it is line with the 8= 0/20 rule of thumb that we have been using when coming up with this spec.

 

From: Leif Johans= son [mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost= ; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion

 

 


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am against changing manager to be multi-valued. I'v= e built 3 user provisioning engines and have never seen a case where manager= is multi-valued. If you have a matrix-ed organization where there are dotte= d line relationships, then I recommend an extension. But we ought to keep SCIM focused on the mainstream scenario w= here a person has a single manager.

 

+1 (as individual)



 

On Wed, May 6, 2015 at 12:24 AM, Phil Hunt <phil.hunt@oracle.com= > wrote:

<As Individual>

My understanding is that we do.  Dotted line and= multi-reporting relationships are a reality for many enterprise organizatio= ns.  At least one (or more) of our implementations is multi-valued. Thi= s was also raised to me as an issue.

 

<As Editor>

I think the reality is that we=E2=80=99ll all run int= o enterprises wanting multi-valued managers sooner or later.  Having it= multi-valued doesn=E2=80=99t mean you have to support multiple values. = ; But the important thing is that SCIM parsers will need to expect an array.

 

Maybe we need a general note that parsers should a= ccept a single value JSON object even when an attribute is multi-valued (for= any multi-valued attribute).  This would make the issue non-breaki= ng for clients (who think any attribute is single-valued).  As for servers, it seems to me we have a compatibi= lity issue due to the spec inconsistency (while definition is single-value, e= xamples are multi-valued). That means regardless of our decisions some serve= rs will have to be updated.

 

 

On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar)= <moransar@cisco.= com> wrote:

 

Speaking as an individual =E2=80=93 I am n= ot aware of any IdM system that has multivalued =E2=80=9Cmanager=E2=80=9D. I= n addition in many cases a multivalued manager brakes many applications as t= he reporting hierarchy is assumed to be a tree structure with a one to many re= lationship not many to many. Unless someone has a solid use case for turning= this into a multivalued attribute, my vote as one of the implementors is to= fix the example and leave it as single valued.

 

 

Cheers,

Morteza

 

From: Patrick Radtke <patrick.radtke@jivesoftware.com> Date: Monday, May 4, 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com&= gt;
Cc: "scim@ietf.org= " <scim@ietf.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re: [scim] Manager attribute wording suggestion

 

Is it too late in the process to make the= attribute name plural (=E2=80=9Cmanagers=E2=80=9D)? All the other multiValu= ed attributes I saw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT <patrick.radtke@jivesof= tware.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribute wording suggestion

 

There are a couple of changes from the IE= SG review coming to core-schema (for other reasons - emails to follow).=

 

With regards to this issue, I propose tha= t the next update make =E2=80=9Cmanager=E2=80=9D a multi-valued attribute so= that it is consistent with the examples and to correct the apparent inconsistency in the draft.

 

If there are any strong objections, pleas= e respond and discuss.

 

Thanks,

 

 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzl= e <kelly= .grizzle@sailpoint.com> wrote:

 

It looks like this got chan= ged back in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 

      ...

 

      Corrected enterprise User man= ager attribute to use sub-attribute

=

      value and make multi-valued

 

I hadn=E2=80=99t realized t= hat this change went in.  Up until then manager had been single-valued s= ince SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3. <= /o:p>

 

Regarding the fact that =E2= =80=9Crequired=E2=80=9D is false for the =E2=80=9Cvalue=E2=80=9D and =E2=80=9C= $ref=E2=80=9D sub-attributes, this is consistent with the rest of the attrib= ute definitions that are references.  I agree with you, Patrick, that these should be required.=

 

--Kelly

 

From: Phil Hunt [= mailto:phil.hunt@o= racle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion

 

Agreed.

 

Will need consensus/direction from the ch= airs on this and along with the other issue (401/403/501 status code clarifi= cation).

 

Phil

 

@independentid

 

On Apr 30, 2015, at 11:42 AM, Michael Fros= t <michael.= frost@oracle.com> wrote:

 

It is multi-valued in the e= xample in 8.3 and in the schema on page 60, and in our implementation. = I think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizz= le [mailto:= kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion

 

Does anyone have any strong= opinions about making manager multi-valued or leaving it as-is?


Either way we should probably clean up the text in section 4.3 and the schem= a definition.

 

 

From: Phil Hunt [= mailto:phil.hunt@o= racle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion

 

I recall your comment and given lack of i= nput at the time, it was clear there was no consensus for change. I had to l= eave it as is despite thinking it needed to be multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:=

I had forgotten about that.=   The most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-se= rif"">

 

   Note, the schema also needs to be updated. It looks like i= t should be multi-valued

  since many orgs have people with m= ultiple reporting relationships.

 

I don=E2=80=99t remember ev= er discussing this any further or if we achieved consensus on changing this.=   The email thread doesn=E2=80=99t have any more discussion.

 

I=E2=80=99m not sure that I= agree that this should be multivalued.  If anything else, I would neve= r wish multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describes other reporting relat= ionships.

 

Anyone else remember this?

 

From: Phil Hunt [= mailto:phil.hunt@o= racle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion

 

I believe I raised this issue before and t= he consensus was to leave it.  Maybe I am mistaken?

 

Phil

 

@independentid

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzl= e <kelly= .grizzle@sailpoint.com> wrote:

 

Patrick =E2=80=A6 thanks fo= r the feedback.

 

I think that the schema sec= tion is incorrect.  The $ref and value are required and manager is stil= l single valued.  I think the text in 4.3 should say:

 

manager

=
      The user's manager.  A complex type that=
 optionally allows service
=
      providers to represent organizational hierarc=
hy by referencing the
      "id" attribute of another User.

 

Phil, do you agree?<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-se= rif"">

 

--Kelly

 

From: scim [mailto:scim-bounces@ie= tf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording suggestion

 

There are a couple aspects of the =E2=80=9C= manager=E2=80=9D attribute that seem inconsistent.

 

In 4.3 Enterprise User Schema extension i= t says

"manager

=
      The user's manager.  A complex type that=
 optionally allows service
=
      providers to represent organizational hierarc=
hy by referencing the
=
      "id" attribute of another User.
=
 
=
      value  The "id" of the SCIM resource rep=
resenting the user's
=
         manager.  RECOMMENDED.=

=
 
=
      $ref  The URI of the SCIM resource repre=
senting the User's
=
         manager.  RECOMMENDED.=

=E2=80=9C

To me that says that a user may have a si= ngle manager, and =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 attribu= tes are not required.

 

However in the Schema section, manager is= listed as "multiValued: true=E2=80=9D and though subAttributes of =E2=80=9C= $ref=E2=80=9D and =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80= =9D the description attribute says each is required.

 

If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$= ref=E2=80=9D aren=E2=80=99t required, can the Manager schema description be a= djusted?

Since manager is multi-valued, can sectio= n 4.3 be updated to say. "The user's managers.  A mu= lti-valued complex type that=E2=80=A6=E2=80=9D  Otherwise, at first read (or for a= nyone coming from SCIM 1.1) it is not obvious that it has become multi-value= d.

 

Thanks,

 

Patrick

 

 

 

 

 

_________________________________________= ______
scim mailing list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim

 

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

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

= --Apple-Mail-9C2C1668-248C-42EB-9FE4-F811CEEBE56F-- From nobody Wed May 6 10:41:33 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C251A1DBC for ; Wed, 6 May 2015 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdrsYJOCQfxw for ; Wed, 6 May 2015 10:41:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69EF1A1ACC for ; Wed, 6 May 2015 10:41:25 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t46HfMj1006165 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2015 17:41:22 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t46HfJq6002553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2015 17:41:20 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t46HfJCT008996; Wed, 6 May 2015 17:41:19 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 May 2015 10:41:17 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9B7113A0-1A1B-40C0-A6D3-A20E94A9D903" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Wed, 6 May 2015 10:41:15 -0700 Message-Id: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> To: Kelly Grizzle X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Michael Frost , Leif Johansson , Ian Glazer , Patrick Radtke , SCIM WG , Morteza Ansari Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 17:41:31 -0000 --Apple-Mail=_9B7113A0-1A1B-40C0-A6D3-A20E94A9D903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Do I have direction to correct the examples and align them with a = single-value definition? Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 6, 2015, at 9:32 AM, Phil Hunt wrote: >=20 > =20 > We can use an extension (TBD) to support multiple relation types.=20 >=20 > I just worry that others will have to support it.=20 >=20 > Phil >=20 > On May 6, 2015, at 09:05, Kelly Grizzle > wrote: >=20 >> I agree with Ian. While multiple managers is possible, I have never = seen it in any system that I have dealt with =E2=80=A6 and I have seen a = lot. It feels like we would be penalizing the majority by making = clients have to deal with multiple values when they will almost never be = multi-valued. >> =20 >> I agree that we should keep manager single-valued, and if a server = requires multiple manager relationships this could be added as an = extension. The single-valued manager would be their primary and the = extended attribute would be all of the dotted line managers. In fact, = if there are multiple managers it might make sense to make this a = complex attribute that can further describe the relationship. >> To me this feels like it is line with the 80/20 rule of thumb that we = have been using when coming up with this spec. >> =20 >> From: Leif Johansson [mailto:leifj@mnt.se ]=20 >> Sent: Wednesday, May 06, 2015 10:55 AM >> To: Ian Glazer >> Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael = Frost; Kelly Grizzle >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> =20 >>=20 >> 6 maj 2015 kl. 17:43 skrev Ian Glazer >: >>=20 >> I am against changing manager to be multi-valued. I've built 3 user = provisioning engines and have never seen a case where manager is = multi-valued. If you have a matrix-ed organization where there are = dotted line relationships, then I recommend an extension. But we ought = to keep SCIM focused on the mainstream scenario where a person has a = single manager. >> =20 >> +1 (as individual) >>=20 >>=20 >> =20 >> On Wed, May 6, 2015 at 12:24 AM, Phil Hunt > wrote: >> >> My understanding is that we do. Dotted line and multi-reporting = relationships are a reality for many enterprise organizations. At least = one (or more) of our implementations is multi-valued. This was also = raised to me as an issue. >> =20 >> >> I think the reality is that we=E2=80=99ll all run into enterprises = wanting multi-valued managers sooner or later. Having it multi-valued = doesn=E2=80=99t mean you have to support multiple values. But the = important thing is that SCIM parsers will need to expect an array. >> =20 >> Maybe we need a general note that parsers should accept a single = value JSON object even when an attribute is multi-valued (for any = multi-valued attribute). This would make the issue non-breaking for = clients (who think any attribute is single-valued). As for servers, it = seems to me we have a compatibility issue due to the spec inconsistency = (while definition is single-value, examples are multi-valued). That = means regardless of our decisions some servers will have to be updated. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) = > wrote: >> =20 >> Speaking as an individual =E2=80=93 I am not aware of any IdM system = that has multivalued =E2=80=9Cmanager=E2=80=9D. In addition in many = cases a multivalued manager brakes many applications as the reporting = hierarchy is assumed to be a tree structure with a one to many = relationship not many to many. Unless someone has a solid use case for = turning this into a multivalued attribute, my vote as one of the = implementors is to fix the example and leave it as single valued. >> =20 >> =20 >> Cheers, >> Morteza >> =20 >> From: Patrick Radtke > >> Date: Monday, May 4, 2015 at 4:10 PM >> To: Phil Hunt >, = Kelly Grizzle > >> Cc: "scim@ietf.org " >, Michael Frost > >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> Is it too late in the process to make the attribute name plural = (=E2=80=9Cmanagers=E2=80=9D)? All the other multiValued attributes I saw = in core-schema use the plural form for the attribute name. >> =20 >> From: Phil Hunt > >> Date: Monday, May 4, 2015 at 4:04 PM >> To: Kelly Grizzle > >> Cc: Michael Frost >, Jive IT = >, SCIM WG > >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> There are a couple of changes from the IESG review coming to = core-schema (for other reasons - emails to follow). >> =20 >> With regards to this issue, I propose that the next update make = =E2=80=9Cmanager=E2=80=9D a multi-valued attribute so that it is = consistent with the examples and to correct the apparent inconsistency = in the draft. >> =20 >> If there are any strong objections, please respond and discuss. >> =20 >> Thanks, >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> On Apr 30, 2015, at 1:50 PM, Kelly Grizzle = > = wrote: >> =20 >> It looks like this got changed back in October in revision 12 of the = core schema doc. >> =20 >> Draft 12 - PH - Nits / Corrections >> =20 >> ... >> =20 >> Corrected enterprise User manager attribute to use = sub-attribute >> value and make multi-valued >> =20 >> I hadn=E2=80=99t realized that this change went in. Up until then = manager had been single-valued since SCIM 1.0. If there is consensus = that this change should stay, then it seems like we need to update = section 4.3. >> =20 >> Regarding the fact that =E2=80=9Crequired=E2=80=9D is false for the = =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D sub-attributes, this = is consistent with the rest of the attribute definitions that are = references. I agree with you, Patrick, that these should be required. >> =20 >> --Kelly >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Thursday, April 30, 2015 2:21 PM >> To: Michael Frost >> Cc: Kelly Grizzle; Patrick Radtke; SCIM WG >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> Agreed. >> =20 >> Will need consensus/direction from the chairs on this and along with = the other issue (401/403/501 status code clarification). >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: >> =20 >> It is multi-valued in the example in 8.3 and in the schema on page = 60, and in our implementation. I think only the text in section 4.3 = refers to manager as singular. >> =20 >> -mrf >> =20 >> From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com = ]=20 >> Sent: Thursday, April 30, 2015 10:28 AM >> To: Phil Hunt >> Cc: Patrick Radtke; SCIM WG >> Subject: Re: [scim] Manager attribute wording suggestion >> =20 >> Does anyone have any strong opinions about making manager = multi-valued or leaving it as-is? >>=20 >> Either way we should probably clean up the text in section 4.3 and = the schema definition. >> =20 >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Thursday, April 30, 2015 10:28 AM >> To: Kelly Grizzle >> Cc: Patrick Radtke; SCIM WG >> Subject: Re: Manager attribute wording suggestion >> =20 >> I recall your comment and given lack of input at the time, it was = clear there was no consensus for change. I had to leave it as is despite = thinking it needed to be multi-valued.=20 >>=20 >> Phil >>=20 >> On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: >>=20 >> I had forgotten about that. The most discussion that I found was in = this email - = http://www.ietf.org/mail-archive/web/scim/current/msg02007.html = . >> =20 >> Note, the schema also needs to be updated. It looks like it should = be multi-valued >> since many orgs have people with multiple reporting relationships. >> =20 >> I don=E2=80=99t remember ever discussing this any further or if we = achieved consensus on changing this. The email thread doesn=E2=80=99t = have any more discussion. >> =20 >> I=E2=80=99m not sure that I agree that this should be multivalued. = If anything else, I would never wish multiple managers upon anyone. ;) = Being serious, though, this might fit better as a second attribute that = describes other reporting relationships. >> =20 >> Anyone else remember this? >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Wednesday, April 29, 2015 6:41 PM >> To: Kelly Grizzle >> Cc: Patrick Radtke; SCIM WG >> Subject: Re: Manager attribute wording suggestion >> =20 >> I believe I raised this issue before and the consensus was to leave = it. Maybe I am mistaken? >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> On Apr 29, 2015, at 4:06 PM, Kelly Grizzle = > = wrote: >> =20 >> Patrick =E2=80=A6 thanks for the feedback. >> =20 >> I think that the schema section is incorrect. The $ref and value are = required and manager is still single valued. I think the text in 4.3 = should say: >> =20 >> manager >> The user's manager. A complex type that optionally allows = service >> providers to represent organizational hierarchy by referencing = the >> "id" attribute of another User. >> =20 >> Phil, do you agree? >> =20 >> --Kelly >> =20 >> From: scim [mailto:scim-bounces@ietf.org = ] On Behalf Of Patrick Radtke >> Sent: Friday, April 24, 2015 5:47 PM >> To: SCIM WG >> Subject: [scim] Manager attribute wording suggestion >> =20 >> There are a couple aspects of the =E2=80=9Cmanager=E2=80=9D attribute = that seem inconsistent. >> =20 >> In 4.3 Enterprise User Schema extension it says >> "manager >> The user's manager. A complex type that optionally allows = service >> providers to represent organizational hierarchy by referencing = the >> "id" attribute of another User. >> =20 >> value The "id" of the SCIM resource representing the user's >> manager. RECOMMENDED. >> =20 >> $ref The URI of the SCIM resource representing the User's >> manager. RECOMMENDED. >> =E2=80=9C >> To me that says that a user may have a single manager, and = =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not = required. >> =20 >> However in the Schema section, manager is listed as "multiValued: = true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80=9D and = =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D the = description attribute says each is required. >> =20 >> If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t = required, can the Manager schema description be adjusted? >> Since manager is multi-valued, can section 4.3 be updated to say. = "The user's managers. A multi-valued complex type that=E2=80=A6=E2=80=9D = Otherwise, at first read (or for anyone coming from SCIM 1.1) it is not = obvious that it has become multi-valued. >> =20 >> Thanks, >> =20 >> Patrick >> =20 >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = >>=20 >>=20 >> =20 >> -- >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = ______________________________= _________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_9B7113A0-1A1B-40C0-A6D3-A20E94A9D903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <editor hat>

Do I have direction to correct the examples and align them = with a single-value definition?


On May 6, 2015, at 9:32 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 
We can use an extension (TBD) to support multiple relation = types. 

I = just worry that others will have to support it. 

Phil

On May 6, 2015, at = 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.  While multiple managers is possible, I = have never seen it in any system that I have dealt with =E2=80=A6 and I = have seen a lot.  It feels like we would be penalizing the majority by making clients have to deal with multiple values when they will = almost never be multi-valued.

 

I agree that we should keep manager = single-valued, and if a server requires multiple manager relationships = this could be added as an extension.  The single-valued manager would be their primary and the extended attribute would be all = of the dotted line managers.  In fact, if there are multiple = managers it might make sense to make this a complex attribute that can = further describe the relationship.

To me this feels like it is line with = the 80/20 rule of thumb that we have been using when coming up with this spec.

 

From: Leif Johansson [mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza = Ansari; Michael Frost; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording = suggestion

 

 


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am against changing manager to = be multi-valued. I've built 3 user provisioning engines and have never = seen a case where manager is multi-valued. If you have a matrix-ed = organization where there are dotted line relationships, then I recommend an extension. But we ought to keep SCIM focused on the mainstream = scenario where a person has a single manager.

 

+1 (as individual)



 

On Wed, May 6, 2015 at 12:24 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:

<As Individual>

My understanding is that we = do.  Dotted line and multi-reporting relationships are a reality = for many enterprise organizations.  At least one (or more) of our = implementations is multi-valued. This was also raised to me as an = issue.

 

<As Editor>

I think the reality is that = we=E2=80=99ll all run into enterprises wanting multi-valued managers = sooner or later.  Having it multi-valued doesn=E2=80=99t mean you = have to support multiple values.  But the important thing is that = SCIM parsers will need to expect an array.

 

Maybe we need a = general note that parsers should accept a single value JSON object even = when an attribute is multi-valued (for any multi-valued = attribute).  This would make the issue non-breaking for clients = (who think any attribute is single-valued).  As for servers, it seems to me we have a = compatibility issue due to the spec inconsistency (while definition is = single-value, examples are multi-valued). That means regardless of our = decisions some servers will have to be updated.

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On May 5, 2015, at 2:14 PM, = Morteza Ansari (moransar) <moransar@cisco.com> wrote:

 

Speaking as an individual =E2=80=93 I am not aware of = any IdM system that has multivalued =E2=80=9Cmanager=E2=80=9D. In = addition in many cases a multivalued manager brakes many applications as = the reporting hierarchy is assumed to be a tree structure with a one to = many relationship not many to many. Unless someone has a solid use case = for turning this into a multivalued attribute, my vote as one of the = implementors is to fix the example and leave it as single valued.

 

 

Cheers,

Morteza

 

From: Patrick Radtke <patrick.radtke@jivesoftware.com>
Date: Monday, May 4, 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re: [scim] Manager attribute wording = suggestion

 

Is it too late in the process to make the attribute = name plural (=E2=80=9Cmanagers=E2=80=9D)? All the other multiValued = attributes I saw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT <patrick.radtke@jivesoftware.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribute wording = suggestion

 

There are a couple of changes from the IESG review = coming to core-schema (for other reasons - emails to follow).

 

With regards to this issue, I propose that the next = update make =E2=80=9Cmanager=E2=80=9D a multi-valued attribute so that = it is consistent with the examples and to correct the apparent inconsistency in the draft.

 

If there are any strong objections, please respond = and discuss.

 

Thanks,

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

 

It looks like this got changed back in = October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 

      ...

 

      Corrected enterprise User = manager attribute to use sub-attribute

      value and make = multi-valued

 

I hadn=E2=80=99t realized that this = change went in.  Up until then manager had been single-valued since = SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that =E2=80=9Crequired= =E2=80=9D is false for the =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80= =9D sub-attributes, this is consistent with the rest of the attribute = definitions that are references.  I agree with you, Patrick, that these should be = required.

 

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion

 

Agreed.

 

Will need consensus/direction from the chairs on this = and along with the other issue (401/403/501 status code = clarification).

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 30, 2015, at 11:42 AM, Michael Frost <michael.frost@oracle.com> wrote:

 

It is multi-valued in the example in = 8.3 and in the schema on page 60, and in our implementation.  I = think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording = suggestion

 

Does anyone have any strong opinions = about making manager multi-valued or leaving it as-is?


Either way we should probably clean up the text in section 4.3 and the = schema definition.

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion

 

I recall your comment and given lack of input at the = time, it was clear there was no consensus for change. I had to leave it = as is despite thinking it needed to be multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I had forgotten about that.  The = most discussion that I found was in this email - = http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.

 

   Note, the schema also needs to be updated. It looks = like it should be multi-valued

  since many orgs have people with multiple = reporting relationships.

 

I don=E2=80=99t remember ever = discussing this any further or if we achieved consensus on changing = this.  The email thread doesn=E2=80=99t have any more = discussion.

 

I=E2=80=99m not sure that I agree that = this should be multivalued.  If anything else, I would never wish = multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describes other reporting = relationships.

 

Anyone else remember this?

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording = suggestion

 

I believe I raised this issue before and the = consensus was to leave it.  Maybe I am mistaken?

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

 

Patrick =E2=80=A6 thanks for the = feedback.

 

I think that the schema section is = incorrect.  The $ref and value are required and manager is still = single valued.  I think the text in 4.3 should say:

 

manager

      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute =
of another User.

 

Phil, do you agree?

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manager attribute wording = suggestion

 

There are a couple aspects of the =E2=80=9Cmanager=E2=80= =9D attribute that seem inconsistent.

 

In 4.3 Enterprise User Schema extension it says

"manager

      The user's manager.  A =
complex type that optionally allows service
      providers to represent =
organizational hierarchy by referencing the
      "id" attribute of another =
User.
 
      value  The "id" of the =
SCIM resource representing the user's
         =
manager.  RECOMMENDED.
 
      $ref  The URI of the SCIM =
resource representing the User's
         =
manager.  RECOMMENDED.

=E2=80=9C

To me that says that a user may have a single = manager, and =E2=80=98value=E2=80=99 and =E2=80=98$ref=E2=80=99 = attributes are not required.

 

However in the Schema section, manager is listed as = "multiValued: true=E2=80=9D and though subAttributes of =E2=80=9C$ref=E2=80= =9D and =E2=80=9Cvalue=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D = the description attribute says each is required.

 

If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D = aren=E2=80=99t required, can the Manager schema description be = adjusted?

Since manager is multi-valued, can section 4.3 be = updated to say. "The user's managers.  A multi-valued complex type that=E2=80=A6=E2=80=9D  Otherwise, at first read (or = for anyone coming from SCIM 1.1) it is not obvious that it has become = multi-valued.

 

Thanks,

 

Patrick

 

 

 

 

 

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

 

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

@iglazer

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

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

= --Apple-Mail=_9B7113A0-1A1B-40C0-A6D3-A20E94A9D903-- From nobody Wed May 6 10:49:43 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4170C1A6EED for ; Wed, 6 May 2015 10:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xskgk0s-m6uI for ; Wed, 6 May 2015 10:49:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF09A1A3BA1 for ; Wed, 6 May 2015 10:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78853; q=dns/txt; s=iport; t=1430934575; x=1432144175; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AdxkxdmwMxXPtJ9BKJ9qbCvtYUJvgq2Up5jZQAwO1UU=; b=gy8l0BSddMoS7VzIwaLoZiDYKsqCq3o2SzSAyn0CoyyC2SzAO1xJMoQ4 Mc51VhVmGcdHKr0lr2V3gb9UAFGcppwpkHR76PyV6edAIVC/QxwNjnImf kZOytA6lHFH7TkKkpMXriWG5kxHGYX9KYqBsyXe2SYXt0QVWtZl0Yd4Q4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBgA1U0pV/4UNJK1TBgOCRUdUXgbEe4IiGQEJhgUCgSZMAQEBAQEBgQuEIAEBAQQBAQEXExwlBAcQAgEIBwoDAQEBIQEGBycLFAkIAgQBDQUJiCMNxVABAQEBAQEBAQEBAQEBAQEBAQEBAQEXijeBAoFPglMHCQIBBScTAQwEBgEJCIQcBYsnhFCCMYQUhkSBJINWgniHCINsg1MjgWaCEG8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,380,1427760000"; d="scan'208,217";a="417565350" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 06 May 2015 17:49:33 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t46HnXis029246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 May 2015 17:49:33 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.175]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 6 May 2015 12:49:33 -0500 From: "Morteza Ansari (moransar)" To: Patrick Radtke , Phil Hunt , Michael Frost Thread-Topic: [scim] Manager attribute wording suggestion Thread-Index: AQHQg2sVZVjYkzoIEUeRKQK3UrtUk51mN7IAgAAKwQCAABkoAIAGbqcAgAABqwCAAPzAAIAAiN4AgAEiQYCAAANMgIAAAsAAgAAHhACAABNSgP//jPgA Date: Wed, 6 May 2015 17:49:32 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.129] Content-Type: multipart/alternative; boundary="_000_D16FA16812430Cmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG , Ian Glazer , Leif Johansson , Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 17:49:40 -0000 --_000_D16FA16812430Cmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I definitely think we should make the examples & definition consistent. But= before making the change, I would like to give Michael & Patrick a chance = to chime in with the discussion. Michael & Patrick, thoughts? Cheers, Morteza From: Phil Hunt > Date: Wednesday, May 6, 2015 at 10:41 AM To: Kelly Grizzle > Cc: Michael Frost >, "scim@ietf.org" >, Ian Glazer >, P= atrick Radtke >, Leif Johansson >, Morteza A= nsari > Subject: Re: [scim] Manager attribute wording suggestion Do I have direction to correct the examples and align them with a single-va= lue definition? Phil @independentid www.independentid.com phil.hunt@oracle.com On May 6, 2015, at 9:32 AM, Phil Hunt > wrote: We can use an extension (TBD) to support multiple relation types. I just worry that others will have to support it. Phil On May 6, 2015, at 09:05, Kelly Grizzle > wrote: I agree with Ian. While multiple managers is possible, I have never seen i= t in any system that I have dealt with =85 and I have seen a lot. It feels= like we would be penalizing the majority by making clients have to deal wi= th multiple values when they will almost never be multi-valued. I agree that we should keep manager single-valued, and if a server requires= multiple manager relationships this could be added as an extension. The s= ingle-valued manager would be their primary and the extended attribute woul= d be all of the dotted line managers. In fact, if there are multiple manag= ers it might make sense to make this a complex attribute that can further d= escribe the relationship. To me this feels like it is line with the 80/20 rule of thumb that we have = been using when coming up with this spec. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Wednesday, May 06, 2015 10:55 AM To: Ian Glazer Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; Kell= y Grizzle Subject: Re: [scim] Manager attribute wording suggestion 6 maj 2015 kl. 17:43 skrev Ian Glazer >: I am against changing manager to be multi-valued. I've built 3 user provisi= oning engines and have never seen a case where manager is multi-valued. If = you have a matrix-ed organization where there are dotted line relationships= , then I recommend an extension. But we ought to keep SCIM focused on the m= ainstream scenario where a person has a single manager. +1 (as individual) On Wed, May 6, 2015 at 12:24 AM, Phil Hunt > wrote: My understanding is that we do. Dotted line and multi-reporting relationsh= ips are a reality for many enterprise organizations. At least one (or more= ) of our implementations is multi-valued. This was also raised to me as an = issue. I think the reality is that we=92ll all run into enterprises wanting multi-= valued managers sooner or later. Having it multi-valued doesn=92t mean you= have to support multiple values. But the important thing is that SCIM par= sers will need to expect an array. Maybe we need a general note that parsers should accept a single value JSON= object even when an attribute is multi-valued (for any multi-valued attrib= ute). This would make the issue non-breaking for clients (who think any at= tribute is single-valued). As for servers, it seems to me we have a compat= ibility issue due to the spec inconsistency (while definition is single-val= ue, examples are multi-valued). That means regardless of our decisions some= servers will have to be updated. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) > wrote: Speaking as an individual =96 I am not aware of any IdM system that has mul= tivalued =93manager=94. In addition in many cases a multivalued manager bra= kes many applications as the reporting hierarchy is assumed to be a tree st= ructure with a one to many relationship not many to many. Unless someone ha= s a solid use case for turning this into a multivalued attribute, my vote a= s one of the implementors is to fix the example and leave it as single valu= ed. Cheers, Morteza From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM To: Phil Hunt >, Kelly Gr= izzle > Cc: "scim@ietf.org" >, Michael Frost > Subject: Re: [scim] Manager attribute wording suggestion Is it too late in the process to make the attribute name plural (=93manager= s=94)? All the other multiValued attributes I saw in core-schema use the pl= ural form for the attribute name. From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle > Cc: Michael Frost >, Jive IT >, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). With regards to this issue, I propose that the next update make =93manager= =94 a multi-valued attribute so that it is consistent with the examples and= to correct the apparent inconsistency in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: It looks like this got changed back in October in revision 12 of the core s= chema doc. Draft 12 - PH - Nits / Corrections ... Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued I hadn=92t realized that this change went in. Up until then manager had be= en single-valued since SCIM 1.0. If there is consensus that this change sh= ould stay, then it seems like we need to update section 4.3. Regarding the fact that =93required=94 is false for the =93value=94 and =93= $ref=94 sub-attributes, this is consistent with the rest of the attribute d= efinitions that are references. I agree with you, Patrick, that these shou= ld be required. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Agreed. Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. -mrf From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued. Phil On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. I don=92t remember ever discussing this any further or if we achieved conse= nsus on changing this. The email thread doesn=92t have any more discussion= . I=92m not sure that I agree that this should be multivalued. If anything e= lse, I would never wish multiple managers upon anyone. ;) Being serious, t= hough, this might fit better as a second attribute that describes other rep= orting relationships. Anyone else remember this? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: Patrick =85 thanks for the feedback. I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. Phil, do you agree? --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion There are a couple aspects of the =93manager=94 attribute that seem inconsi= stent. In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. =93 To me that says that a user may have a single manager, and =91value=92 and = =91$ref=92 attributes are not required. However in the Schema section, manager is listed as "multiValued: true=94 a= nd though subAttributes of =93$ref=94 and =93value=94 have =93required:fals= e=94 the description attribute says each is required. If =93value=94 and =93$ref=94 aren=92t required, can the Manager schema des= cription be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that=85=94 Otherwise, at first r= ead (or for anyone coming from SCIM 1.1) it is not obvious that it has beco= me multi-valued. Thanks, Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16FA16812430Cmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I definitely think we should make the examples & definition consis= tent. But before making the change, I would like to give Michael & Patr= ick a chance to chime in with the discussion. 

Michael & Patrick, thoughts?


Cheers,
Morteza

From: Phil Hunt <phil.hunt@oracle.com>
Date: Wednesday, May 6, 2015 at 10:= 41 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, "scim@ietf.org" <scim@ietf.org>, Ian Glazer <iglazer@salesforce.com>, Patrick Radtke <patr= ick.radtke@jivesoftware.com>, Leif Johansson <leifj@mnt.se>, Morteza Ansari <moransar@cisco.com>
Subject: Re: [scim] Manager attribu= te wording suggestion

<editor hat>

Do I have direction to correct the examples and align them = with a single-value definition?

Phil

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

On May 6, 2015, at 9:32 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 
We can use an extension (TBD) to support multiple relation = types. 

I just worry that others will have to support it. 

Phil

On May 6, 2015, at 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.  While multiple managers is possible, I h= ave never seen it in any system that I have dealt with =85 and I have seen = a lot.  It feels like we would be penalizing the majority by making clients have to deal with multiple values when they= will almost never be multi-valued.

 

I agree that we should k= eep manager single-valued, and if a server requires multiple manager relati= onships this could be added as an extension.  The single-valued manager would be their primary and the extended attribut= e would be all of the dotted line managers.  In fact, if there are mul= tiple managers it might make sense to make this a complex attribute that ca= n further describe the relationship.

To me this feels like it is line with = the 80/20 rule of thumb that we have been using when coming up with this spec.

 

From: Leif Johansson [<= a href=3D"mailto:leifj@mnt.se" class=3D"">mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; M= ichael Frost; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion<= o:p class=3D"">

 

 


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am against changing manager to be multi-valued. I'= ve built 3 user provisioning engines and have never seen a case where manag= er is multi-valued. If you have a matrix-ed organization where there are do= tted line relationships, then I recommend an extension. But we ought to keep SCIM focused on the mainstream scenario= where a person has a single manager.

 

+1 (as individual)



 

On Wed, May 6, 2015 at 12:24 AM, Phil Hunt <phil.hunt@o= racle.com> wrote:

<As Individual>

My understanding is that we do.  Dotted line an= d multi-reporting relationships are a reality for many enterprise organizat= ions.  At least one (or more) of our implementations is multi-valued. = This was also raised to me as an issue.

 

<As Editor>

I think the reality is that we=92ll all run into ent= erprises wanting multi-valued managers sooner or later.  Having it mul= ti-valued doesn=92t mean you have to support multiple values.  But the= important thing is that SCIM parsers will need to expect an array.

 

Maybe we need a general note that pars= ers should accept a single value JSON object even when an attribute is mult= i-valued (for any multi-valued attribute).  This would make the is= sue non-breaking for clients (who think any attribute is single-valued).  As for servers, it seems to me we have = a compatibility issue due to the spec inconsistency (while definition is si= ngle-value, examples are multi-valued). That means regardless of our decisi= ons some servers will have to be updated.

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar= ) <mo= ransar@cisco.com> wrote:

 

Speaking as an individual =96 I am not aware of= any IdM system that has multivalued =93manager=94. In addition in many cas= es a multivalued manager brakes many applications as the reporting hierarchy is assumed to be a tree structure with a one to= many relationship not many to many. Unless someone has a solid use case fo= r turning this into a multivalued attribute, my vote as one of the implemen= tors is to fix the example and leave it as single valued.

 

 

Cheers,

Morteza

 

From: Patrick Radtke <patrick.radtke@jivesoftware.com&g= t;
Date: Monday, May 4, 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle &= lt;kelly.grizzle@sailpoint.com>
Cc: "scim@ietf.org" <scim@ietf.org>, Michael Frost <michae= l.frost@oracle.com>
Subject: Re: [scim] Manager attribute wording suggestion<= o:p class=3D"">

 

Is it too late in the process to make the attri= bute name plural (=93managers=94)? All the other multiValued attributes I s= aw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>= ;
Cc: Michael Frost <michael.frost@oracle.com>, Jiv= e IT <patrick.radtke@jivesoftware.com>, SCIM WG <scim@= ietf.org>
Subject: Re: [scim] Manager attribute wording suggestion<= o:p class=3D"">

 

There are a couple of changes from the IESG rev= iew coming to core-schema (for other reasons - emails to follow).

 

With regards to this issue, I propose that the = next update make =93manager=94 a multi-valued attribute so that it is consi= stent with the examples and to correct the apparent inconsistency in the draft.

 

If there are any strong objections, please resp= ond and discuss.

 

Thanks,

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle <= kelly.grizzle@sailpoint.com> wrote:

 

It looks like this got c= hanged back in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif;" class= =3D"">

 

      ...

 

      Corrected enterprise Use= r manager attribute to use sub-attribute<= /span>

      value and make multi-val= ued

 

I hadn=92t realized that= this change went in.  Up until then manager had been single-valued si= nce SCIM 1.0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that = =93required=94 is false for the =93value=94 and =93$ref=94 sub-attributes, = this is consistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that the= se should be required.

 

--Kelly

 

From: Phil Hunt [mailto:phil.= hunt@oracle.com]
Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

Agreed.

 

Will need consensus/direction from the chairs o= n this and along with the other issue (401/403/501 status code clarificatio= n).

 

Phil

 <= /p>

@independentid=

www.independentid.com

phil.hunt@oracle.com

 

On Apr 30, 2015, at 11:42 AM, Michael Frost <= ;m= ichael.frost@oracle.com> wrote:

 

It is multi-valued in th= e example in 8.3 and in the schema on page 60, and in our implementation.&n= bsp; I think only the text in section 4.3 refers to manager as singular.

 

-mrf

 

From: Kelly Grizzle [m= ailto:kelly.grizzle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

Does anyone have any str= ong opinions about making manager multi-valued or leaving it as-is?<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif;" class= =3D"">


Either way we should probably clean up the text in section 4.3 and the sche= ma definition.

 

 

From: Phil Hunt [mailto:phil.= hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif;" class= =3D"">

 

I recall your comment and given lack of input a= t the time, it was clear there was no consensus for change. I had to leave = it as is despite thinking it needed to be multi-valued. 


Phil


On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I had forgotten about th= at.  The most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=

 

   Note, the schema also needs to be updated. It looks like it sho= uld be multi-valued

  since many orgs have people with multipl= e reporting relationships.

 

I don=92t remember ever = discussing this any further or if we achieved consensus on changing this.&n= bsp; The email thread doesn=92t have any more discussion.

 

I=92m not sure that I ag= ree that this should be multivalued.  If anything else, I would never = wish multiple managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describe= s other reporting relationships.

 

Anyone else remember thi= s?

 

From: Phil Hunt [mailto:phil.= hunt@oracle.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribute wording suggestion<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif;" class= =3D"">

 

I believe I raised this issue before and the co= nsensus was to leave it.  Maybe I am mistaken?

 

Phil

 <= /p>

@independentid=

www.independentid.com

phil.hunt@oracle.com

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <= kelly.grizzle@sailpoint.com> wrote:

 

Patrick =85 thanks for t= he feedback.

 

I think that the schema = section is incorrect.  The $ref and value are required and manager is = still single valued.  I think the text in 4.3 should say:

 

manager<= /p> 

      The user's manager.  A complex type t=
hat optionally allows service
      providers to represent organizational hier=
archy by referencing the

      "id" attribute of<=
/span> ano=
ther User.




 






Phil, do you agree?






 






--Kelly






 










From: scim [mailto:scim-boun=
ces@ietf.org]
On Behalf Of Patrick Radtke

Sent: Friday, April 24, 2015 5:47 PM

To: SCIM WG

Subject: [scim] Manager attribute wording suggestion










 








There are a couple aspects of the =93manager=94=
 attribute that seem inconsistent.










 










In 4.3 Enterprise User Schema extension it says=











"manager






      The user's manager.  A complex type t=
hat optionally allows service


      providers to represent organizational hier=
archy by referencing the


      "id" attribute of another User.<=
/span>


 


      value  The "id" of the SCIM=
 resource representing the user's


         manager.  RECOMMEND=
ED.


 


      $ref  The URI of the SCIM resource re=
presenting the User's


         manager.  RECOMMEND=
ED.






=93










To me that says that a user may have a single m=
anager, and =91value=92 and =91$ref=92 attributes are not required.










 










However in the Schema section, manager is liste=
d as "multiValued: true=94 and though subAttributes of =93$ref=94 and =
=93value=94 have =93required:false=94 the description attribute
 says each is required.










 










If =93value=94 and =93$ref=94 aren=92t required=
, can the Manager schema description be adjusted?










Since manager is multi-valued, can section 4.3 =
be updated to say. "The user's managers. 
 A multi-valued complex type that=85=94  Otherwise, at first read (or =
for anyone coming from SCIM 1.1) it is not obvious that it has become multi=
-valued.










 










Thanks,<=
/p>









 










Patrick<=
/p>









 










 










 










 

 

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

 

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

@iglazer

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

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

 --_000_D16FA16812430Cmoransarciscocom_-- From nobody Wed May 6 11:12:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E391A87CE for ; Wed, 6 May 2015 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5mk2CXmNf7e for ; Wed, 6 May 2015 11:12:26 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38C71A87F0 for ; Wed, 6 May 2015 11:12:25 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t46ICNXH022426 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2015 18:12:24 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t46ICMq7003379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2015 18:12:23 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t46ICMlH025229; Wed, 6 May 2015 18:12:22 GMT MIME-Version: 1.0 Message-ID: Date: Wed, 6 May 2015 11:12:18 -0700 (PDT) From: Michael Frost Sender: Michael Frost To: "Morteza Ansari (moransar)" , Patrick Radtke , Phil Hunt References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: multipart/alternative; boundary="__1430935941767168934abhmp0018.oracle.com" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: SCIM WG , Ian Glazer , Kelly Grizzle , Leif Johansson Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:12:35 -0000 --__1430935941767168934abhmp0018.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Our current implementation is multi-valued. But it is no big deal to dial = it back to single valued. We implemented multi-valued purely to be spec co= mpliant, there is no other internal requirement driving the feature for us.= So I am OK with a single value definition. =20 -mrf =20 From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]=20 Sent: Wednesday, May 06, 2015 10:50 AM To: Patrick Radtke; Phil Hunt; Michael Frost Cc: SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion =20 I definitely think we should make the examples & definition consistent. But= before making the change, I would like to give Michael & Patrick a chance = to chime in with the discussion.=20 =20 Michael & Patrick, thoughts? =20 =20 Cheers, Morteza =20 From: Phil Hunt Date: Wednesday, May 6, 2015 at 10:41 AM To: Kelly Grizzle Cc: Michael Frost , "HYPERLINK "mailto:scim@ietf.org"scim@ietf.org" , Ian Glazer , Patrick Radtke , Leif Johans= son , Morteza Ansari Subject: Re: [scim] Manager attribute wording suggestion =20 =20 =20 Do I have direction to correct the examples and align them with a single-va= lue definition? =20 Phil =20 @independentid HYPERLINK "http://www.independentid.com"www.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com"phil.hunt@oracle.com =20 On May 6, 2015, at 9:32 AM, Phil Hunt wrote: =20 =20 We can use an extension (TBD) to support multiple relation types.=20 =20 I just worry that others will have to support it.=20 Phil On May 6, 2015, at 09:05, Kelly Grizzle wrote: I agree with Ian. While multiple managers is possible, I have never seen i= t in any system that I have dealt with . and I have seen a lot. It feels l= ike we would be penalizing the majority by making clients have to deal with= multiple values when they will almost never be multi-valued. =20 I agree that we should keep manager single-valued, and if a server requires= multiple manager relationships this could be added as an extension. The s= ingle-valued manager would be their primary and the extended attribute woul= d be all of the dotted line managers. In fact, if there are multiple manag= ers it might make sense to make this a complex attribute that can further d= escribe the relationship. To me this feels like it is line with the 80/20 rule of thumb that we have = been using when coming up with this spec. =20 From: Leif Johansson [mailto:leifj@mnt.se]=20 Sent: Wednesday, May 06, 2015 10:55 AM To: Ian Glazer Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; Kell= y Grizzle Subject: Re: [scim] Manager attribute wording suggestion =20 =20 6 maj 2015 kl. 17:43 skrev Ian Glazer : I am against changing manager to be multi-valued. I've built 3 user provisi= oning engines and have never seen a case where manager is multi-valued. If = you have a matrix-ed organization where there are dotted line relationships= , then I recommend an extension. But we ought to keep SCIM focused on the m= ainstream scenario where a person has a single manager. =20 +1 (as individual) =20 On Wed, May 6, 2015 at 12:24 AM, Phil Hunt wrote: My understanding is that we do. Dotted line and multi-reporting relationsh= ips are a reality for many enterprise organizations. At least one (or more= ) of our implementations is multi-valued. This was also raised to me as an = issue. =20 I think the reality is that we'll all run into enterprises wanting multi-va= lued managers sooner or later. Having it multi-valued doesn't mean you hav= e to support multiple values. But the important thing is that SCIM parsers= will need to expect an array. =20 Maybe we need a general note that parsers should accept a single value JSON= object even when an attribute is multi-valued (for any multi-valued attrib= ute). This would make the issue non-breaking for clients (who think any at= tribute is single-valued). As for servers, it seems to me we have a compat= ibility issue due to the spec inconsistency (while definition is single-val= ue, examples are multi-valued). That means regardless of our decisions some= servers will have to be updated. =20 Phil =20 @independentid HYPERLINK "http://www.independentid.com/" \nwww.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com" \nphil.hunt@oracle.com =20 On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) wrote: =20 Speaking as an individual - I am not aware of any IdM system that has multi= valued "manager". In addition in many cases a multivalued manager brakes ma= ny applications as the reporting hierarchy is assumed to be a tree structur= e with a one to many relationship not many to many. Unless someone has a so= lid use case for turning this into a multivalued attribute, my vote as one = of the implementors is to fix the example and leave it as single valued. =20 =20 Cheers, Morteza =20 From: Patrick Radtke Date: Monday, May 4, 2015 at 4:10 PM To: Phil Hunt , Kelly Grizzle Cc: "HYPERLINK "mailto:scim@ietf.org" \nscim@ietf.org" , Michael Frost Subject: Re: [scim] Manager attribute wording suggestion =20 Is it too late in the process to make the attribute name plural ("managers"= )? All the other multiValued attributes I saw in core-schema use the plural= form for the attribute name. =20 From: Phil Hunt Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle Cc: Michael Frost , Jive IT Subject: Re: [scim] Manager attribute wording suggestion =20 There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). =20 With regards to this issue, I propose that the next update make "manager" a= multi-valued attribute so that it is consistent with the examples and to c= orrect the apparent inconsistency in the draft. =20 If there are any strong objections, please respond and discuss. =20 Thanks, =20 Phil =20 @independentid HYPERLINK "http://www.independentid.com/" \nwww.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com" \nphil.hunt@oracle.com =20 On Apr 30, 2015, at 1:50 PM, Kelly Grizzle wrote: =20 It looks like this got changed back in October in revision 12 of the core s= chema doc. =20 Draft 12 - PH - Nits / Corrections =20 ... =20 Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued =20 I hadn't realized that this change went in. Up until then manager had been= single-valued since SCIM 1.0. If there is consensus that this change shou= ld stay, then it seems like we need to update section 4.3.=20 =20 Regarding the fact that "required" is false for the "value" and "$ref" sub-= attributes, this is consistent with the rest of the attribute definitions t= hat are references. I agree with you, Patrick, that these should be requir= ed. =20 --Kelly=20 =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion =20 Agreed. =20 Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). =20 Phil =20 @independentid HYPERLINK "http://www.independentid.com/" \nwww.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com" \nphil.hunt@oracle.com =20 On Apr 30, 2015, at 11:42 AM, Michael Frost wrote: =20 It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. =20 -mrf =20 From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com]=20 Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion =20 Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. =20 =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion =20 I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued.=20 Phil On Apr 30, 2015, at 06:41, Kelly Grizzle wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. =20 Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. =20 I don't remember ever discussing this any further or if we achieved consens= us on changing this. The email thread doesn't have any more discussion. =20 I'm not sure that I agree that this should be multivalued. If anything els= e, I would never wish multiple managers upon anyone. ;) Being serious, tho= ugh, this might fit better as a second attribute that describes other repor= ting relationships. =20 Anyone else remember this?=20 =20 From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion =20 I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? =20 Phil =20 @independentid HYPERLINK "http://www.independentid.com/" \nwww.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com" \nphil.hunt@oracle.com =20 On Apr 29, 2015, at 4:06 PM, Kelly Grizzle wrote: =20 Patrick . thanks for the feedback. =20 I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : =20 manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. =20 Phil, do you agree? =20 --Kelly =20 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion =20 There are a couple aspects of the "manager" attribute that seem inconsisten= t. =20 In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. =20 value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. =20 $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. " To me that says that a user may have a single manager, and 'value' and '$re= f' attributes are not required. =20 However in the Schema section, manager is listed as "multiValued: true" and= though subAttributes of "$ref" and "value" have "required:false" the descr= iption attribute says each is required. =20 If "value" and "$ref" aren't required, can the Manager schema description b= e adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that." Otherwise, at first read = (or for anyone coming from SCIM 1.1) it is not obvious that it has become m= ulti-valued. =20 Thanks, =20 Patrick =20 =20 =20 =20 =20 _______________________________________________ scim mailing list HYPERLINK "mailto:scim@ietf.org" \nscim@ietf.org https://www.ietf.org/mailman/listinfo/scim =20 =20 =20 _______________________________________________ scim mailing list HYPERLINK "mailto:scim@ietf.org"scim@ietf.org https://www.ietf.org/mailman/listinfo/scim =20 --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 HYPERLINK "https://twitter.com/iglazer" \n@iglazer _______________________________________________ scim mailing list HYPERLINK "mailto:scim@ietf.org"scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list HYPERLINK "mailto:scim@ietf.org"scim@ietf.org https://www.ietf.org/mailman/listinfo/scim =20 --__1430935941767168934abhmp0018.oracle.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Our curre= nt implementation is multi-valued.  But it is no big deal to dial it b= ack to single valued.  We implemented multi-valued purely to be spec c= ompliant, there is no other internal requirement driving the feature for us= .  So I am OK with a single value definition.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>-mrf

 

From: Morteza Ansari (moransa= r) [mailto:moransar@cisco.com]
Sent: Wednesday, May 06, 2015 10:= 50 AM
To: Patrick Radtke; Phil Hunt; Michael Frost
Cc: = SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle
Subject: Re: [= scim] Manager attribute wording suggestion

 

I= definitely think we should make the examples & definition consistent. = But before making the change, I would like to give Michael & Patrick a = chance to chime in with the discussion. 

 

Michael & Patrick, thoughts?

 

<= p class=3DMsoNormal> 

Cheers,

Morteza

 

From: = Phil Hunt <phil.= hunt@oracle.com>
Date: Wednesday, May 6, 2015 at 10:41 AM<= br>To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, = "scim@ietf.org" <scim@ietf.org>, Ian Glazer <iglazer@salesforce.com>, Patrick Radt= ke <patrick.radtke@ji= vesoftware.com>, Leif Johansson <= leifj@mnt.se>, Morteza Ansari <moransar@cisco.com>
Subject: Re: [scim] Manager attrib= ute wording suggestion

 

<editor hat>

 

Do I have di= rection to correct the examples and align them with a single-value definiti= on?

 

=  

On May 6, 2015, at 9:32 AM, Phil= Hunt <phil.hunt@oracle.com&= gt; wrote:

 =

 =

We can use an extension (TB= D) to support multiple relation types. 

 

I just worry that others will have to support it. 
Phil


On May 6, 2015, at 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.&= nbsp; While multiple managers is possible, I have never seen it in any syst= em that I have dealt with … and I have seen a lot.  It feels lik= e we would be penalizing the majority by making clients have to deal with m= ultiple values when they will almost never be multi-valued.

&nbs= p;

I agree that we should keep manager single-valued, and if a ser= ver requires multiple manager relationships this could be added as an exten= sion.  The single-valued manager would be their primary and the extend= ed attribute would be all of the dotted line managers.  In fact, if th= ere are multiple managers it might make sense to make this a complex attrib= ute that can further describe the relationship.

To me this feels like it is line= with the 80/20 rule of thumb that we have been using when coming up with t= his spec.

 

From: Leif= Johansson [mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
= Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; = Kelly Grizzle
Subject: Re: [scim] Manager attribute wording sugge= stion

<= p class=3DMsoNormal> 

 


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am agains= t changing manager to be multi-valued. I've built 3 user provisioning engin= es and have never seen a case where manager is multi-valued. If you have a = matrix-ed organization where there are dotted line relationships, then I re= commend an extension. But we ought to keep SCIM focused on the mainstream s= cenario where a person has a single manager.

 = ;

+1 (as individual)

=


 

<= div>

On Wed, May 6, 2015 at= 12:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

<As Individual>

My unders= tanding is that we do.  Dotted line and multi-reporting relationships = are a reality for many enterprise organizations.  At least one (or mor= e) of our implementations is multi-valued. This was also raised to me as an= issue.

 

<As Editor>

I think the reality is th= at we’ll all run into enterprises wanting multi-valued managers soone= r or later.  Having it multi-valued doesn’t mean you have to sup= port multiple values.  But the important thing is that SCIM parsers wi= ll need to expect an array.

 

Maybe we need a general n= ote that parsers should accept a single value JSON object even when an attr= ibute is multi-valued (for any multi-valued attribute).  This would make the issue non-breaking for client= s (who think any attribute is single-valued).  As for servers, it seem= s to me we have a compatibility issue due to the spec inconsistency (while = definition is single-value, examples are multi-valued). That means regardle= ss of our decisions some servers will have to be updated.=

 =

Phil<= /span>

 

@= independentid

phil.hunt@oracle.com

=

 

On= May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:=

&nb= sp;

Speaking = as an individual – I am not aware of any IdM system that has multival= ued “manager”. In addition in many cases a multivalued manager = brakes many applications as the reporting hierarchy is assumed to be a tree= structure with a one to many relationship not many to many. Unless someone= has a solid use case for turning this into a multivalued attribute, my vot= e as one of the implementors is to fix the example and leave it as single v= alued.

<= p class=3DMsoNormal> 

 

Cheers,

Morteza<= /o:p>

 

From: Patrick Radtke <patrick.radtke@jivesoftware.co= m>
Date: Monday, May 4, 2015 at 4:10 PM
To: Phil= Hunt <phil.hu= nt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc= : "scim@ietf.or= g" <scim@iet= f.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re:= [scim] Manager attribute wording suggestion

 

Is it too late in the process to make the attribute = name plural (“managers”)? All the other multiValued attributes = I saw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <= ;phil.hunt@oracle= .com>
Date: Monday, May 4, 2015 at 4:04 PM
To: K= elly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <= michael.frost= @oracle.com>, Jive IT <patrick.radtke@jivesoftware.com>, SCIM WG= <scim@ietf.org&g= t;
Subject: Re: [scim] Manager attribute wording suggestion

 

There are a couple of chang= es from the IESG review coming to core-schema (for other reasons - emails t= o follow).

 =

With regards to this = issue, I propose that the next update make “manager” a multi-va= lued attribute so that it is consistent with the examples and to correct th= e apparent inconsistency in the draft.

 

If there are any strong objections, please respond and discuss.

 

Thanks,

 

Phil

 

@independentid

<= a href=3D"http://www.independentid.com/" target=3D"_blank">www.independenti= d.com

phil.hunt@oracle.com

<= p class=3DMsoNormal> 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle= <kelly= .grizzle@sailpoint.com> wrote:

 

It looks like this got changed back in October in revision 12 o= f the core schema doc.=

 

   Dr= aft 12 - PH - Nits / Corrections

 

  &nb= sp;   ...

 =

     = Corrected enterprise User manager attribute to use sub-attribute

=       value and make multi-valued

 

I hadn’t realized that this change wen= t in.  Up until then manager had been single-valued since SCIM 1.0.&nb= sp; If there is consensus that this change should stay, then it seems like = we need to update section 4.3.

 

Regarding the fact that “required” is false for the “= value” and “$ref” sub-attributes, this is consistent with= the rest of the attribute definitions that are references.  I agree w= ith you, Patrick, that these should be required.

&nbs= p;

--Kelly

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
= Sent: Thursday, April 30, 2015 2:21 PM
To: Michael Frost
<= b>Cc: Kelly Grizzle; Patrick Radtke; SCIM WG
Subject: Re: [sc= im] Manager attribute wording suggestion=

&nbs= p;

Agreed.<= /span>

 

Will need consensus/direction from the chairs on this and alon= g with the other issue (401/403/501 status code clarification).

 

=

 =

On Apr 30, 2015, at 11= :42 AM, Michael Frost <michael.frost@oracle.com> wrote:

 

It is multi-valued in the example in= 8.3 and in the schema on page 60, and in our implementation.  I think= only the text in section 4.3 refers to manager as singular.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

=

-mrf

 

From: Kelly Grizzle [mailto:kelly.grizzle@sail= point.com]
Sent: Thursday, April 30, 2015 10:28 AM
To:= Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re:= [scim] Manager attribute wording suggestion

=  

<= p class=3DMsoNormal>Does anyone have any strong opinions about makin= g manager multi-valued or leaving it as-is?


Either = way we should probably clean up the text in section 4.3 and the schema defi= nition.

=

 <= /o:p>

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Kelly GrizzleCc: Patrick Radtke; SCIM WG
Subject: Re: Manager attribut= e wording suggestion

 

I recall your comment and given lack of input at the time, it was cle= ar there was no consensus for change. I had to leave it as is despite think= ing it needed to be multi-valued. <= o:p>


Ph= il


On Apr 30, 2015, at 06:41, Kelly Grizzle = <kelly.= grizzle@sailpoint.com> wrote:

I had forgotten about that.  The most discussion that I fou= nd was in this email - http://www.ietf.org/mail-archive/= web/scim/current/msg02007.html.=

 

   Note, the schema also needs to be updated.= It looks like it should be multi-valued=

  since man= y orgs have people with multiple reporting relationships.

 

I don’t remember ever discussing this a= ny further or if we achieved consensus on changing this.  The email th= read doesn’t have any more discussion.

 

I’m not sure that I agree that this should be multiv= alued.  If anything else, I would never wish multiple managers upon an= yone. ;)  Being serious, though, this might fit better as a second att= ribute that describes other reporting relationships.

&n= bsp;

Anyone else remember this?

&n= bsp;

From: Phil Hunt [mailto:phil.hunt@orac= le.com]
Sent: Wednesday, April 29, 2015 6:41 PM
To: Kelly Grizzle
Cc: Patrick Radtke; SCIM WG
Subject: Re= : Manager attribute wording suggestion

 =

I believe I raised this issue before and the consensus w= as to leave it.  Maybe I am mistaken?

 

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle = <kelly.= grizzle@sailpoint.com> wrote:

 <= span style=3D'color:black'>

Patrick … thanks for the feedback.

 

I think that the schema section is inco= rrect.  The $ref and value are required and manager is still single va= lued.  I think the text in 4.3 should say:

 <= /span>

manager

      The user's manager.  A complex ty=
pe that optionally allows service
      providers to represent organizatio=
nal hierarchy by referencing the<=
o:p>
      "id" attribute =
of another User.
<= div>

 

Phil, do you agr= ee?

 

--Kelly

 

From: scim [mailto:scim-bounces= @ietf.org] On Behalf Of Patrick Radtke
Sent: Friday, A= pril 24, 2015 5:47 PM
To: SCIM WG
Subject: [scim] Manag= er attribute wording suggestion

 =

There are a couple aspects of the “manager” a= ttribute that seem inconsistent.

 =

In 4.3 Enterprise User Schema extension it says

<= p class=3DMsoNormal>"manager

      The use=
r's manager.  A complex type that optionally allows service
      pro=
viders to represent organizational hierarchy by referencing the
      &quo=
t;id" attribute of another User.
 
&nb=
sp;     value  The "id" of the SCIM reso=
urce representing the user's<=
/span>
         manager.  RECOMM=
ENDED.
 
      $re=
f  The URI of the SCIM resource representing the User's
      &n=
bsp;  manager.  RECOMMENDED.
“
To me that says that a user may have a single manager, =
and ‘value’ and ‘$ref’ attributes are not required.=

<=
div>
 

However i= n the Schema section, manager is listed as "multiValued: true” a= nd though subAttributes of “$ref” and “value” have = “required:false” the description attribute says each is require= d.

 

If = 220;value” and “$ref” aren’t required, can the Mana= ger schema description be adjusted?=

Since mana= ger is multi-valued, can section 4.3 be updated to say. "T= he user's managers.  A multi-valued complex type that…” &n= bsp;Otherwise, at first read (or for anyone coming from SCIM 1.1) it is not= obvious that it has become multi-valued.

&nbs= p;

Thanks,<= o:p>

 =

<= div>

Patrick

 =

<= div>

 

 

 

 

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

 

&nb= sp;

 


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



 

= --

Ian Glazer

Senior Director, Identity<= /p>

+1 202 255 3= 166

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

___________________________________= ____________
scim mailing list
scim@= ietf.org
http= s://www.ietf.org/mailman/listinfo/scim

 

<= /div> --__1430935941767168934abhmp0018.oracle.com-- From nobody Wed May 6 13:08:14 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96AA1ACD8F for ; Wed, 6 May 2015 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aryXrZgSF_zX for ; Wed, 6 May 2015 13:08:11 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9B91ACD4D for ; Wed, 6 May 2015 13:08:09 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 6 May 2015 22:08:06 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Wed, 6 May 2015 22:08:06 +0200 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Phil Hunt Thread-Topic: [scim] A short review of the password mgmt draft - Management requests Thread-Index: AQHQh1PRPSYh0sJINEKvaj6LtPxGhJ1tfVkAgAHDMAA= Date: Wed, 6 May 2015 20:08:06 +0000 Message-ID: References: <9AE2B59D-E418-4DF4-BBF9-E838EDC69127@oracle.com> In-Reply-To: <9AE2B59D-E418-4DF4-BBF9-E838EDC69127@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [94.234.170.7] Content-Type: text/plain; charset="utf-8" Content-ID: <8C176311BA59A146A3E3EC5100F2E3F5@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SCIM WG Subject: Re: [scim] A short review of the password mgmt draft - Management requests X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 20:08:12 -0000 DQo+IE9uIDA1IE1heSAyMDE1LCBhdCAxOToxMywgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl LmNvbT4gd3JvdGU6DQo+IEkgdGhpbmsgc29tZSBtb3JlIGdyb3VwIGRpc2N1c3Npb24gKHN1Y2gg YXMgb3RoZXIgZmFjdG9ycy9tZXRob2RvbG9naWVzKSB3b3VsZCByZWFsbHkgaGVscCBoZXJlLiAg DQoNCg0KQ29tbW9uIG1ldGhvZHMsIG9mIHRoZSB0b3Agb2YgbXkgaGVhZCwgdGhhdCB3ZSBzZWUg YXNrZWQgZm9yIGJ5IDJGQSBjdXN0b21lcnMuDQoNCjEuIEkgZ3Vlc3MgbXkgcGVyc29uYWwgZmF2 b3VyaXRlIGlzIGhhdmluZyBhIHN1cGVyLWFkbWluIHRoYXQgY2FuIHJlc2V0IGEgcGFzc3dvcmQg Zm9yIGEgdXNlciBpbiBhbiBhZG1pbiBzeXN0ZW0uIEJ1dCB0aGF04oCZcyBvbmx5IGEgbHV4dXJ5 IHRoYXQgY29ycG9yYXRpb24gd2l0aCBhIE1hbiBoYXZlIGFuZCBpdOKAmXMgYW4gaGFyZCBtZXRo b2QgZm9yIGNsb3VkIHByb3ZpZGVycyB0byB1c2UuDQogDQoyLiBBbm90aGVyIG1ldGhvZCB3ZSBn ZXQgYSBsb3Qgb2YgcXVlc3Rpb25zIGFib3V0IGlzIHNvbWVvbmUgaGVscGluZyBvdXQgYW5kIHJl c2V0dGluZyB0aGUgcGFzc3dvcmQuIFNvIGl04oCZcyBkb25lIGJ5IGEgdHJ1c3RlZCB0aGlyZCBw YXJ0eSBpbiB0aGUgZm9ybSBvZiBhIGJvc3MsIElULWRlcHQsIGNvbGxlYWd1ZSBvciB3aGF0ZXZl ciB0aGUgcmVzZXQgcG9saWNpZXMgZGVmaW5lcy4gVGhlcmUgT1RQcyBhcmUgc2VudCB0byB0aGUg Ym9zcyBhbmQgaXTigJlzIGdpdmVuIHRvIHRoZSB1c2VyIG92ZXIgc29tZSBhbHRlcm5hdGl2ZSBj aGFubmVsICh2aXN1YWwgb3IgYnkgcGhvbmUpLg0KDQozLiBUaGVuIHdlIGhhdmUgcmVzZXQgZnVu Y3Rpb25zIHRoYXQncyB1c2luZyBhIHNlY29uZCBjaGFubmVsIGxpa2UgYSBwaG9uZSBvciAyRkEg dG9rZW4gc29tZWhvdy4gSWYgaXTigJlzIGEgcGhvbmUgdGhlbiBpdCBjb3VsZCBwb3RlbnRpYWxs eSBsb3dlciBhIHR3byBmYWN0b3IgYmFzZWQgYXV0aGVudGljYXRpb24gdG8gYSBvbmUgZmFjdG9y IGlmIGl04oCZcyBub3QgaGFuZGxlZCBjb3JyZWN0bHkuIA0KDQo0LiBUaGVuIHdlIGhhdmUsIG15 IHBlcnNvbmFsIGxlYXN0IGZhdm91cml0ZSwgY2hhbGxlbmdlL3Jlc3BvbnNlIGJhc2VkIG1ldGhv ZHMuIEkgc2VlIHJlcXVpcmVtZW50cyBmb3IgdGhhdCBsZXNzIGFuZCBsZXNzIGFyb3VuZCBFdXJv cGUuIA0KDQovIEVyaWsNCg0K From nobody Wed May 6 13:55:06 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6D11B2F31 for ; Wed, 6 May 2015 13:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1TNiWrOoRQj for ; Wed, 6 May 2015 13:54:58 -0700 (PDT) Received: from jesse.jivesoftware.com (jesse.jivesoftware.com [204.93.66.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5951B2EFE for ; Wed, 6 May 2015 13:54:58 -0700 (PDT) X-ASG-Debug-ID: 1430945696-059d6b651f16db0001-bGWiwh Received: from mail.jiveland.com (phxcas02.jiveland.com [10.81.2.12]) by jesse.jivesoftware.com with ESMTP id wZwZDwyhyHzoLMLN; Wed, 06 May 2015 13:54:56 -0700 (PDT) X-Barracuda-Envelope-From: patrick.radtke@jivesoftware.com Received: from MBX01.jiveland.com ([fe80::9982:7054:baaa:ab73]) by PHXCAS02.jiveland.com ([10.81.2.12]) with mapi id 14.03.0158.001; Wed, 6 May 2015 13:54:55 -0700 From: Patrick Radtke To: Michael Frost , "Morteza Ansari (moransar)" , Phil Hunt Thread-Topic: [scim] Manager attribute wording suggestion X-ASG-Orig-Subj: Re: [scim] Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAB/ooCAAOrKAIAAHcCAgAAhm4CAABSbAIAACsEAgAAZKACABm6nAP//jFGAgAHndQCAABODAIABIkGAgAADTICAAALAAIAAB4QAgAATUoCAAAJRAIAABlwA//+4EwA= Date: Wed, 6 May 2015 20:54:53 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.32.204] Content-Type: multipart/alternative; boundary="_000_D16FCB3917D3patrickradtkejivesoftwarecom_" MIME-Version: 1.0 X-Barracuda-Connect: phxcas02.jiveland.com[10.81.2.12] X-Barracuda-Start-Time: 1430945696 X-Barracuda-URL: https://spamfirewall4.jiveland.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at jivesoftware.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -0.36 X-Barracuda-Spam-Status: No, SCORE=-0.36 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=HTML_MESSAGE, SARE_STILLSINGLE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18676 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.66 SARE_STILLSINGLE BODY: Contains phrasing used by spammers 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: SCIM WG , Ian Glazer , Kelly Grizzle , Leif Johansson Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 20:55:03 -0000 --_000_D16FCB3917D3patrickradtkejivesoftwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We also only implemented multi-valued to be spec compliant. We ignore every= thing after the first/primary manager. I=92m good with it becoming single valued again. -Patrick From: Michael Frost > Date: Wednesday, May 6, 2015 at 11:12 AM To: "Morteza Ansari (moransar)" >, Jive IT >, Phil Hunt > Cc: SCIM WG >, Ian Glazer >, Leif Johansson >, Kelly Grizzle > Subject: RE: [scim] Manager attribute wording suggestion Our current implementation is multi-valued. But it is no big deal to dial = it back to single valued. We implemented multi-valued purely to be spec co= mpliant, there is no other internal requirement driving the feature for us.= So I am OK with a single value definition. -mrf From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Wednesday, May 06, 2015 10:50 AM To: Patrick Radtke; Phil Hunt; Michael Frost Cc: SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion I definitely think we should make the examples & definition consistent. But= before making the change, I would like to give Michael & Patrick a chance = to chime in with the discussion. Michael & Patrick, thoughts? Cheers, Morteza From: Phil Hunt > Date: Wednesday, May 6, 2015 at 10:41 AM To: Kelly Grizzle > Cc: Michael Frost >, "scim@ietf.org" >, Ian Glazer >, P= atrick Radtke >, Leif Johansson >, Morteza A= nsari > Subject: Re: [scim] Manager attribute wording suggestion Do I have direction to correct the examples and align them with a single-va= lue definition? Phil @independentid www.independentid.com phil.hunt@oracle.com On May 6, 2015, at 9:32 AM, Phil Hunt > wrote: We can use an extension (TBD) to support multiple relation types. I just worry that others will have to support it. Phil On May 6, 2015, at 09:05, Kelly Grizzle > wrote: I agree with Ian. While multiple managers is possible, I have never seen i= t in any system that I have dealt with =85 and I have seen a lot. It feels= like we would be penalizing the majority by making clients have to deal wi= th multiple values when they will almost never be multi-valued. I agree that we should keep manager single-valued, and if a server requires= multiple manager relationships this could be added as an extension. The s= ingle-valued manager would be their primary and the extended attribute woul= d be all of the dotted line managers. In fact, if there are multiple manag= ers it might make sense to make this a complex attribute that can further d= escribe the relationship. To me this feels like it is line with the 80/20 rule of thumb that we have = been using when coming up with this spec. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Wednesday, May 06, 2015 10:55 AM To: Ian Glazer Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; Kell= y Grizzle Subject: Re: [scim] Manager attribute wording suggestion 6 maj 2015 kl. 17:43 skrev Ian Glazer >: I am against changing manager to be multi-valued. I've built 3 user provisi= oning engines and have never seen a case where manager is multi-valued. If = you have a matrix-ed organization where there are dotted line relationships= , then I recommend an extension. But we ought to keep SCIM focused on the m= ainstream scenario where a person has a single manager. +1 (as individual) On Wed, May 6, 2015 at 12:24 AM, Phil Hunt > wrote: My understanding is that we do. Dotted line and multi-reporting relationsh= ips are a reality for many enterprise organizations. At least one (or more= ) of our implementations is multi-valued. This was also raised to me as an = issue. I think the reality is that we=92ll all run into enterprises wanting multi-= valued managers sooner or later. Having it multi-valued doesn=92t mean you= have to support multiple values. But the important thing is that SCIM par= sers will need to expect an array. Maybe we need a general note that parsers should accept a single value JSON= object even when an attribute is multi-valued (for any multi-valued attrib= ute). This would make the issue non-breaking for clients (who think any at= tribute is single-valued). As for servers, it seems to me we have a compat= ibility issue due to the spec inconsistency (while definition is single-val= ue, examples are multi-valued). That means regardless of our decisions some= servers will have to be updated. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) > wrote: Speaking as an individual =96 I am not aware of any IdM system that has mul= tivalued =93manager=94. In addition in many cases a multivalued manager bra= kes many applications as the reporting hierarchy is assumed to be a tree st= ructure with a one to many relationship not many to many. Unless someone ha= s a solid use case for turning this into a multivalued attribute, my vote a= s one of the implementors is to fix the example and leave it as single valu= ed. Cheers, Morteza From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM To: Phil Hunt >, Kelly Gr= izzle > Cc: "scim@ietf.org" >, Michael Frost > Subject: Re: [scim] Manager attribute wording suggestion Is it too late in the process to make the attribute name plural (=93manager= s=94)? All the other multiValued attributes I saw in core-schema use the pl= ural form for the attribute name. From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle > Cc: Michael Frost >, Jive IT >, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). With regards to this issue, I propose that the next update make =93manager= =94 a multi-valued attribute so that it is consistent with the examples and= to correct the apparent inconsistency in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: It looks like this got changed back in October in revision 12 of the core s= chema doc. Draft 12 - PH - Nits / Corrections ... Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued I hadn=92t realized that this change went in. Up until then manager had be= en single-valued since SCIM 1.0. If there is consensus that this change sh= ould stay, then it seems like we need to update section 4.3. Regarding the fact that =93required=94 is false for the =93value=94 and =93= $ref=94 sub-attributes, this is consistent with the rest of the attribute d= efinitions that are references. I agree with you, Patrick, that these shou= ld be required. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Agreed. Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. -mrf From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued. Phil On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. I don=92t remember ever discussing this any further or if we achieved conse= nsus on changing this. The email thread doesn=92t have any more discussion= . I=92m not sure that I agree that this should be multivalued. If anything e= lse, I would never wish multiple managers upon anyone. ;) Being serious, t= hough, this might fit better as a second attribute that describes other rep= orting relationships. Anyone else remember this? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: Patrick =85 thanks for the feedback. I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. Phil, do you agree? --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion There are a couple aspects of the =93manager=94 attribute that seem inconsi= stent. In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. =93 To me that says that a user may have a single manager, and =91value=92 and = =91$ref=92 attributes are not required. However in the Schema section, manager is listed as "multiValued: true=94 a= nd though subAttributes of =93$ref=94 and =93value=94 have =93required:fals= e=94 the description attribute says each is required. If =93value=94 and =93$ref=94 aren=92t required, can the Manager schema des= cription be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that=85=94 Otherwise, at first r= ead (or for anyone coming from SCIM 1.1) it is not obvious that it has beco= me multi-valued. Thanks, Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16FCB3917D3patrickradtkejivesoftwarecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3C4490972B1F0349B8044CDC8FF07365@jivesoftware.com> Content-Transfer-Encoding: quoted-printable
We also only implemented multi-valued to be spec compliant. We ignore = everything after the first/primary manager.
I=92m good with it becoming single valued again.

-Patrick

From: Michael Frost <michael.frost@oracle.com>
Date: Wednesday, May 6, 2015 at 11:= 12 AM
To: "Morteza Ansari (moransar)= " <moransar@cisco.com>= , Jive IT <patrick.ra= dtke@jivesoftware.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: SCIM WG <scim@ietf.org>, Ian Glazer <iglazer@salesforce.com>, Leif Johansson <leifj@mnt.se>, Kelly Grizzle <kelly.grizzle@sailpoint= .com>
Subject: RE: [scim] Manager attribu= te wording suggestion

Our current implementation is multi= -valued.  But it is no big deal to dial it back to single valued. = ; We implemented multi-valued purely to be spec compliant, there is no other internal requirement driving the feature for = us.  So I am OK with a single value definition.

 

-mrf

 

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Wednesday, May 06, 2015 10:50 AM
To: Patrick Radtke; Phil Hunt; Michael Frost
Cc: SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

I definitely think we should make the exampl= es & definition consistent. But before making the change, I would like = to give Michael & Patrick a chance to chime in with the discussion. 

 

Michael & Patrick, thoughts?<= /span>

 

 

Cheers,

Morteza

 

From: Phil Hunt <phil= .hunt@oracle.com>
Date: Wednesday, May 6, 2015 at 10:41 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <mi= chael.frost@oracle.com>, "scim= @ietf.org" <scim@ietf.org&= gt;, Ian Glazer <iglazer@sales= force.com>, Patrick Radtke <patr= ick.radtke@jivesoftware.com>, Leif Johansson <leifj@mnt.se>, Morteza Ansari <moransar@cisco.com>
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

<editor hat>

 

Do I have direction to correct the examples = and align them with a single-value definition?

 

 

On May 6, 2015, at 9:32 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

 

We can use an extension (TBD) to support mul= tiple relation types. 

 

I just worry that others will have to suppor= t it. 

Phil


On May 6, 2015, at 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.  While multi= ple managers is possible, I have never seen it in any system that I have de= alt with =85 and I have seen a lot.  It feels like we would be penalizing the majority by making clients have to deal wi= th multiple values when they will almost never be multi-valued.

 

I agree that we should keep manager= single-valued, and if a server requires multiple manager relationships thi= s could be added as an extension.  The single-valued manager would be their primary and the extended attribute wo= uld be all of the dotted line managers.  In fact, if there are multipl= e managers it might make sense to make this a complex attribute that can fu= rther describe the relationship.

To me this feels like it is line with the 80/20 r= ule of thumb that we have been using when coming up with this spec.

 

From: Leif Johansson [mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Fros= t; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion

 =

 =


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am against changing ma= nager to be multi-valued. I've built 3 user provisioning engines and have n= ever seen a case where manager is multi-valued. If you have a matrix-ed org= anization where there are dotted line relationships, then I recommend an extension. But we ought to keep SCIM fo= cused on the mainstream scenario where a person has a single manager.<= /o:p>

 =

+1 (as individual)




 =

On Wed, May 6, 2015 at 1= 2:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

<As Individual>

My understanding is that= we do.  Dotted line and multi-reporting relationships are a reality f= or many enterprise organizations.  At least one (or more) of our imple= mentations is multi-valued. This was also raised to me as an issue.

 =

<As Editor>

I think the reality is t= hat we=92ll all run into enterprises wanting multi-valued managers sooner o= r later.  Having it multi-valued doesn=92t mean you have to support mu= ltiple values.  But the important thing is that SCIM parsers will need to expect an array.

 =

Maybe we need a gener= al note that parsers should accept a single value JSON object even when an = attribute is multi-valued (for any multi-valued attribute).  This would make the issue non-breaking for clients (who think any attribute is single-valu= ed).  As for servers, it seems to me we have a compatibility issue due= to the spec inconsistency (while definition is single-value, examples are = multi-valued). That means regardless of our decisions some servers will have to be updated.

 =

Phil<= /o:p>

 

@independentid

phi= l.hunt@oracle.com<= /p>

 =

On May 5, 2015, at 2:14 = PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

 =

Speaking as an individual =96 I am not aware= of any IdM system that has multivalued =93manager=94. In addition in many = cases a multivalued manager brakes many applications as the reporting hierarchy is assumed to be a tree structure with a one to= many relationship not many to many. Unless someone has a solid use case fo= r turning this into a multivalued attribute, my vote as one of the implemen= tors is to fix the example and leave it as single valued.<= /p>

 

 

Cheers,

Morteza

 

From: Patrick Radtke <patrick.radtke@jivesoftware.com>
Date: Monday, May 4, 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ie= tf.org" <sci= m@ietf.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re: [scim] Manager attribute wording suggestion

 

Is it too late in the process to make the at= tribute name plural (=93managers=94)? All the other multiValued attributes = I saw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT <patrick.radtke@jive= software.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribute wording suggestion

 

There are a couple of changes from the IESG = review coming to core-schema (for other reasons - emails to follow).=

 

With regards to this issue, I propose that t= he next update make =93manager=94 a multi-valued attribute so that it is co= nsistent with the examples and to correct the apparent inconsistency in the draft.

 

If there are any strong objections, please r= espond and discuss.

 

Thanks,

 

Phil<= /o:p>

 

@independentid

phil.hunt@oracle.com=

 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle &= lt;kelly.g= rizzle@sailpoint.com> wrote:=

 

It looks like this got changed back= in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 =

      ...

 =

      Corrected enterprise = User manager attribute to use sub-attribute

      value and make multi-= valued

 

I hadn=92t realized that this chang= e went in.  Up until then manager had been single-valued since SCIM 1.= 0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that =93required= =94 is false for the =93value=94 and =93$ref=94 sub-attributes, this is con= sistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that these should be= required.

 

--Kelly

 

 

Agreed.

 

Will need consensus/direction from the chair= s on this and along with the other issue (401/403/501 status code clarifica= tion).

 

 

On Apr 30, 2015, at 11:42 AM, Michael Frost = <michael.f= rost@oracle.com> wrote:

 

It is multi-valued in the example i= n 8.3 and in the schema on page 60, and in our implementation.  I thin= k only the text in section 4.3 refers to manager as singular.<= /p>

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.griz= zle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion

 

Does anyone have any strong opinion= s about making manager multi-valued or leaving it as-is?


Either way we should probably clean up the text in section 4.3 and the sche= ma definition.

 

 

 

I recall your comment and given lack of inpu= t at the time, it was clear there was no consensus for change. I had to lea= ve it as is despite thinking it needed to be multi-valued. 


Phil

I had forgotten about that.  T= he most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=

 

   Note, the schema also needs to be updated. It looks like it = should be multi-valued=

  since many orgs have people with mult= iple reporting relationships.=

 

I don=92t remember ever discussing = this any further or if we achieved consensus on changing this.  The em= ail thread doesn=92t have any more discussion.

 

I=92m not sure that I agree that th= is should be multivalued.  If anything else, I would never wish multip= le managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describes other r= eporting relationships.

 

Anyone else remember this?

 

 

I believe I raised this issue before and the= consensus was to leave it.  Maybe I am mistaken?

 

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle &= lt;kelly.g= rizzle@sailpoint.com> wrote:=

 

Patrick =85 thanks for the feedback= .

 

I think that the schema section is = incorrect.  The $ref and value are required and manager is still singl= e valued.  I think the text in 4.3 should say:

 

manager

 =
     The user's manager.  A complex type that opti=
onally allows service<=
/pre>

 =
     providers to represent organizational hierarchy by=
 referencing the


&nb=
sp;     "id" attribute of another User.




 






Phil, do you agree?






 






--Kelly






 










From: scim [mailto:scim-bounces@ietf.org=
]
On Behalf Of Patrick Radtke

Sent: Friday, April 24, 2015 5:47 PM

To: SCIM WG

Subject: [scim] Manager attribute wording suggestion










 








There are a couple aspects of the =93manager=
=94 attribute that seem inconsistent.










 










In 4.3 Enterprise User Schema extension it s=
ays










"manager






 =
     The user's manager.  A complex type that opti=
onally allows service<=
/pre>

 =
     providers to represent organizational hierarchy by=
 referencing the


 =
     "id" attribute of another User.


 =



 =
     value  The "id" of the SCIM resourc=
e representing the user's


 =
        manager.  RECOMMENDED.


 =



 =
     $ref  The URI of the SCIM resource representi=
ng the User's


 =
        manager.  RECOMMENDED.






=93<=
/o:p>










To me that says that a user may have a singl=
e manager, and =91value=92 and =91$ref=92 attributes are not required.










 










However in the Schema section, manager is li=
sted as "multiValued: true=94 and though subAttributes of =93$ref=94 a=
nd =93value=94 have =93required:false=94 the description
 attribute says each is required.










 










If =93value=94 and =93$ref=94 aren=92t requi=
red, can the Manager schema description be adjusted?










Since manager is multi-valued, can section 4=
.3 be updated to say. "The
 user's managers.  A multi-valued complex type that=85=94  Otherw=
ise, at first read (or for anyone coming from SCIM 1.1) it is not obvious t=
hat it has become multi-valued.










 










Thanks,










 










Patrick










 










 










 










 

 

____________________________________________= ___
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



 =

--

Ian Glazer

Senior Director, Identit= y

+1 202 255 3166=

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

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

 

 --_000_D16FCB3917D3patrickradtkejivesoftwarecom_-- From nobody Wed May 6 15:21:33 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01FC1B2F81 for ; Wed, 6 May 2015 15:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U10rDYYBbPj for ; Wed, 6 May 2015 15:21:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BD31B2FCC for ; Wed, 6 May 2015 15:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=80272; q=dns/txt; s=iport; t=1430950888; x=1432160488; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RiuiId/T0o+21jGh1lI6rxz4qtI1xHZjuoYQ/KJlH5I=; b=IPOQ1qvu+IySeaaydSE21eqH1+Q5DGmcyYCnieKnJZDgzmGQfz6CaofM ZqBZO8FcL6lZFDGnjt+72ZDjmXFEQycrtP0g/074w1sM7jgrhuEld8RCO sC9ZW49jzUhISb55qdyoZSkG4uhvW5Rj/FDIRURAKWXplpvxwxCqG4NEx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBgC6kkpV/4oNJK1TBgOCRUdUXgbEfIIiGQEJhgUCgSpMAQEBAQEBgQuEIAEBAQQBAQEXExwlBAcQAgEIBwoDAQEBIQEGBycLFAkIAgQBDQUJiCMNxSYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXijeBAoFPglMHCQIBBScTAQwEBgEJCIQcBYsnhFCCMYQUhkSBJINWgniHCINsg1MjgWaCEG8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,381,1427760000"; d="scan'208,217";a="417651098" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 06 May 2015 22:21:26 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t46MLOKV010710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 May 2015 22:21:24 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.175]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 6 May 2015 17:21:24 -0500 From: "Morteza Ansari (moransar)" To: Patrick Radtke , Michael Frost , Phil Hunt Thread-Topic: [scim] Manager attribute wording suggestion Thread-Index: AQHQg2sVZVjYkzoIEUeRKQK3UrtUk51mN7IAgAAKwQCAABkoAIAGbqcAgAABqwCAAPzAAIAAiN4AgAEiQYCAAANMgIAAAsAAgAAHhACAABNSgP//jPgAgAB7tQCAAC1tgP//otCA Date: Wed, 6 May 2015 22:21:23 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> <2266FE7F-D933-4C36-8412-067627D766DA@oracle.com> <74EBE321-05C4-4DBD-BB14-9B562893249C@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.129] Content-Type: multipart/alternative; boundary="_000_D16FE197124524moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG , Ian Glazer , Kelly Grizzle , Leif Johansson Subject: Re: [scim] Manager attribute wording suggestion X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 22:21:32 -0000 --_000_D16FE197124524moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Patrick & Michael. I think we are good to go now. Phil, please fix the examples to match the specification. Cheers, Morteza From: Patrick Radtke > Date: Wednesday, May 6, 2015 at 1:54 PM To: Michael Frost >, Morteza Ansari >, Phil Hu= nt > Cc: "scim@ietf.org" >, Ian Glazer >, L= eif Johansson >, Kelly Grizzle > Subject: Re: [scim] Manager attribute wording suggestion We also only implemented multi-valued to be spec compliant. We ignore every= thing after the first/primary manager. I=92m good with it becoming single valued again. -Patrick From: Michael Frost > Date: Wednesday, May 6, 2015 at 11:12 AM To: "Morteza Ansari (moransar)" >, Jive IT >, Phil Hunt > Cc: SCIM WG >, Ian Glazer >, Leif Johansson >, Kelly Grizzle > Subject: RE: [scim] Manager attribute wording suggestion Our current implementation is multi-valued. But it is no big deal to dial = it back to single valued. We implemented multi-valued purely to be spec co= mpliant, there is no other internal requirement driving the feature for us.= So I am OK with a single value definition. -mrf From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Wednesday, May 06, 2015 10:50 AM To: Patrick Radtke; Phil Hunt; Michael Frost Cc: SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle Subject: Re: [scim] Manager attribute wording suggestion I definitely think we should make the examples & definition consistent. But= before making the change, I would like to give Michael & Patrick a chance = to chime in with the discussion. Michael & Patrick, thoughts? Cheers, Morteza From: Phil Hunt > Date: Wednesday, May 6, 2015 at 10:41 AM To: Kelly Grizzle > Cc: Michael Frost >, "scim@ietf.org" >, Ian Glazer >, P= atrick Radtke >, Leif Johansson >, Morteza A= nsari > Subject: Re: [scim] Manager attribute wording suggestion Do I have direction to correct the examples and align them with a single-va= lue definition? Phil @independentid www.independentid.com phil.hunt@oracle.com On May 6, 2015, at 9:32 AM, Phil Hunt > wrote: We can use an extension (TBD) to support multiple relation types. I just worry that others will have to support it. Phil On May 6, 2015, at 09:05, Kelly Grizzle > wrote: I agree with Ian. While multiple managers is possible, I have never seen i= t in any system that I have dealt with =85 and I have seen a lot. It feels= like we would be penalizing the majority by making clients have to deal wi= th multiple values when they will almost never be multi-valued. I agree that we should keep manager single-valued, and if a server requires= multiple manager relationships this could be added as an extension. The s= ingle-valued manager would be their primary and the extended attribute woul= d be all of the dotted line managers. In fact, if there are multiple manag= ers it might make sense to make this a complex attribute that can further d= escribe the relationship. To me this feels like it is line with the 80/20 rule of thumb that we have = been using when coming up with this spec. From: Leif Johansson [mailto:leifj@mnt.se] Sent: Wednesday, May 06, 2015 10:55 AM To: Ian Glazer Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Frost; Kell= y Grizzle Subject: Re: [scim] Manager attribute wording suggestion 6 maj 2015 kl. 17:43 skrev Ian Glazer >: I am against changing manager to be multi-valued. I've built 3 user provisi= oning engines and have never seen a case where manager is multi-valued. If = you have a matrix-ed organization where there are dotted line relationships= , then I recommend an extension. But we ought to keep SCIM focused on the m= ainstream scenario where a person has a single manager. +1 (as individual) On Wed, May 6, 2015 at 12:24 AM, Phil Hunt > wrote: My understanding is that we do. Dotted line and multi-reporting relationsh= ips are a reality for many enterprise organizations. At least one (or more= ) of our implementations is multi-valued. This was also raised to me as an = issue. I think the reality is that we=92ll all run into enterprises wanting multi-= valued managers sooner or later. Having it multi-valued doesn=92t mean you= have to support multiple values. But the important thing is that SCIM par= sers will need to expect an array. Maybe we need a general note that parsers should accept a single value JSON= object even when an attribute is multi-valued (for any multi-valued attrib= ute). This would make the issue non-breaking for clients (who think any at= tribute is single-valued). As for servers, it seems to me we have a compat= ibility issue due to the spec inconsistency (while definition is single-val= ue, examples are multi-valued). That means regardless of our decisions some= servers will have to be updated. Phil @independentid www.independentid.com phil.hunt@oracle.com On May 5, 2015, at 2:14 PM, Morteza Ansari (moransar) > wrote: Speaking as an individual =96 I am not aware of any IdM system that has mul= tivalued =93manager=94. In addition in many cases a multivalued manager bra= kes many applications as the reporting hierarchy is assumed to be a tree st= ructure with a one to many relationship not many to many. Unless someone ha= s a solid use case for turning this into a multivalued attribute, my vote a= s one of the implementors is to fix the example and leave it as single valu= ed. Cheers, Morteza From: Patrick Radtke > Date: Monday, May 4, 2015 at 4:10 PM To: Phil Hunt >, Kelly Gr= izzle > Cc: "scim@ietf.org" >, Michael Frost > Subject: Re: [scim] Manager attribute wording suggestion Is it too late in the process to make the attribute name plural (=93manager= s=94)? All the other multiValued attributes I saw in core-schema use the pl= ural form for the attribute name. From: Phil Hunt > Date: Monday, May 4, 2015 at 4:04 PM To: Kelly Grizzle > Cc: Michael Frost >, Jive IT >, SCIM WG > Subject: Re: [scim] Manager attribute wording suggestion There are a couple of changes from the IESG review coming to core-schema (f= or other reasons - emails to follow). With regards to this issue, I propose that the next update make =93manager= =94 a multi-valued attribute so that it is consistent with the examples and= to correct the apparent inconsistency in the draft. If there are any strong objections, please respond and discuss. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 1:50 PM, Kelly Grizzle > wrote: It looks like this got changed back in October in revision 12 of the core s= chema doc. Draft 12 - PH - Nits / Corrections ... Corrected enterprise User manager attribute to use sub-attribute value and make multi-valued I hadn=92t realized that this change went in. Up until then manager had be= en single-valued since SCIM 1.0. If there is consensus that this change sh= ould stay, then it seems like we need to update section 4.3. Regarding the fact that =93required=94 is false for the =93value=94 and =93= $ref=94 sub-attributes, this is consistent with the rest of the attribute d= efinitions that are references. I agree with you, Patrick, that these shou= ld be required. --Kelly From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 2:21 PM To: Michael Frost Cc: Kelly Grizzle; Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Agreed. Will need consensus/direction from the chairs on this and along with the ot= her issue (401/403/501 status code clarification). Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 30, 2015, at 11:42 AM, Michael Frost > wrote: It is multi-valued in the example in 8.3 and in the schema on page 60, and = in our implementation. I think only the text in section 4.3 refers to mana= ger as singular. -mrf From: Kelly Grizzle [mailto:kelly.grizzle@sailpoint.com] Sent: Thursday, April 30, 2015 10:28 AM To: Phil Hunt Cc: Patrick Radtke; SCIM WG Subject: Re: [scim] Manager attribute wording suggestion Does anyone have any strong opinions about making manager multi-valued or l= eaving it as-is? Either way we should probably clean up the text in section 4.3 and the sche= ma definition. From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Thursday, April 30, 2015 10:28 AM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I recall your comment and given lack of input at the time, it was clear the= re was no consensus for change. I had to leave it as is despite thinking it= needed to be multi-valued. Phil On Apr 30, 2015, at 06:41, Kelly Grizzle > wrote: I had forgotten about that. The most discussion that I found was in this e= mail - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html. Note, the schema also needs to be updated. It looks like it should be mu= lti-valued since many orgs have people with multiple reporting relationships. I don=92t remember ever discussing this any further or if we achieved conse= nsus on changing this. The email thread doesn=92t have any more discussion= . I=92m not sure that I agree that this should be multivalued. If anything e= lse, I would never wish multiple managers upon anyone. ;) Being serious, t= hough, this might fit better as a second attribute that describes other rep= orting relationships. Anyone else remember this? From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, April 29, 2015 6:41 PM To: Kelly Grizzle Cc: Patrick Radtke; SCIM WG Subject: Re: Manager attribute wording suggestion I believe I raised this issue before and the consensus was to leave it. Ma= ybe I am mistaken? Phil @independentid www.independentid.com phil.hunt@oracle.com On Apr 29, 2015, at 4:06 PM, Kelly Grizzle > wrote: Patrick =85 thanks for the feedback. I think that the schema section is incorrect. The $ref and value are requi= red and manager is still single valued. I think the text in 4.3 should say= : manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. Phil, do you agree? --Kelly From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtke Sent: Friday, April 24, 2015 5:47 PM To: SCIM WG Subject: [scim] Manager attribute wording suggestion There are a couple aspects of the =93manager=94 attribute that seem inconsi= stent. In 4.3 Enterprise User Schema extension it says "manager The user's manager. A complex type that optionally allows service providers to represent organizational hierarchy by referencing the "id" attribute of another User. value The "id" of the SCIM resource representing the user's manager. RECOMMENDED. $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED. =93 To me that says that a user may have a single manager, and =91value=92 and = =91$ref=92 attributes are not required. However in the Schema section, manager is listed as "multiValued: true=94 a= nd though subAttributes of =93$ref=94 and =93value=94 have =93required:fals= e=94 the description attribute says each is required. If =93value=94 and =93$ref=94 aren=92t required, can the Manager schema des= cription be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. A multi-valued complex type that=85=94 Otherwise, at first r= ead (or for anyone coming from SCIM 1.1) it is not obvious that it has beco= me multi-valued. Thanks, Patrick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16FE197124524moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94E65158215FA541907A7408F5B9B0F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Patrick & Michael. I think we are good to go now.

Phil, please fix the examples to match the specification.


Cheers,
Morteza

From: Patrick Radtke <patrick.radtke@jivesoftware.com>
Date: Wednesday, May 6, 2015 at 1:5= 4 PM
To: Michael Frost <michael.frost@oracle.com>, Morteza An= sari <moransar@cisco.com>, = Phil Hunt <phil.hunt@oracle.com<= /a>>
Cc: "scim@ietf.org" <scim@i= etf.org>, Ian Glazer <i= glazer@salesforce.com>, Leif Johansson <leifj@mnt.se>, Kelly Grizzle <kelly.gri= zzle@sailpoint.com>
Subject: Re: [scim] Manager attribu= te wording suggestion

We also only implemented multi-valued to be spec compliant. We ignore = everything after the first/primary manager.
I=92m good with it becoming single valued again.

-Patrick

From: Michael Frost <michael.frost@oracle.com>
Date: Wednesday, May 6, 2015 at 11:= 12 AM
To: "Morteza Ansari (moransar)= " <moransar@cisco.com>= , Jive IT <patrick.ra= dtke@jivesoftware.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: SCIM WG <scim@ietf.org>, Ian Glazer <iglazer@salesforce.com>, Leif Johansson <leifj@mnt.se>, Kelly Grizzle <kelly.grizzle@sailpoint= .com>
Subject: RE: [scim] Manager attribu= te wording suggestion

Our current implementation is multi= -valued.  But it is no big deal to dial it back to single valued. = ; We implemented multi-valued purely to be spec compliant, there is no other internal requirement driving the feature for = us.  So I am OK with a single value definition.

 

-mrf

 

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Wednesday, May 06, 2015 10:50 AM
To: Patrick Radtke; Phil Hunt; Michael Frost
Cc: SCIM WG; Ian Glazer; Leif Johansson; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

I definitely think we should make the exampl= es & definition consistent. But before making the change, I would like = to give Michael & Patrick a chance to chime in with the discussion. 

 

Michael & Patrick, thoughts?<= /span>

 

 

Cheers,

Morteza

 

From: Phil Hunt <phil= .hunt@oracle.com>
Date: Wednesday, May 6, 2015 at 10:41 AM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <mi= chael.frost@oracle.com>, "scim= @ietf.org" <scim@ietf.org&= gt;, Ian Glazer <iglazer@sales= force.com>, Patrick Radtke <patr= ick.radtke@jivesoftware.com>, Leif Johansson <leifj@mnt.se>, Morteza Ansari <moransar@cisco.com>
Subject: Re: [scim] Manager attribute wording suggestion<= /span>

 

<editor hat>

 

Do I have direction to correct the examples = and align them with a single-value definition?

 

 

On May 6, 2015, at 9:32 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

 

We can use an extension (TBD) to support mul= tiple relation types. 

 

I just worry that others will have to suppor= t it. 

Phil


On May 6, 2015, at 09:05, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I agree with Ian.  While multi= ple managers is possible, I have never seen it in any system that I have de= alt with =85 and I have seen a lot.  It feels like we would be penalizing the majority by making clients have to deal wi= th multiple values when they will almost never be multi-valued.

 

I agree that we should keep manager= single-valued, and if a server requires multiple manager relationships thi= s could be added as an extension.  The single-valued manager would be their primary and the extended attribute wo= uld be all of the dotted line managers.  In fact, if there are multipl= e managers it might make sense to make this a complex attribute that can fu= rther describe the relationship.

To me this feels like it is line with the 80/20 r= ule of thumb that we have been using when coming up with this spec.

 

From: Leif Johansson [mailto:leifj@mnt.se]
Sent: Wednesday, May 06, 2015 10:55 AM
To: Ian Glazer
Cc: Phil Hunt; Patrick Radtke; SCIM WG; Morteza Ansari; Michael Fros= t; Kelly Grizzle
Subject: Re: [scim] Manager attribute wording suggestion

 =

 =


6 maj 2015 kl. 17:43 skrev Ian Glazer <iglazer@salesforce.com>:

I am against changing ma= nager to be multi-valued. I've built 3 user provisioning engines and have n= ever seen a case where manager is multi-valued. If you have a matrix-ed org= anization where there are dotted line relationships, then I recommend an extension. But we ought to keep SCIM fo= cused on the mainstream scenario where a person has a single manager.<= /o:p>

 =

+1 (as individual)




 =

On Wed, May 6, 2015 at 1= 2:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

<As Individual>

My understanding is that= we do.  Dotted line and multi-reporting relationships are a reality f= or many enterprise organizations.  At least one (or more) of our imple= mentations is multi-valued. This was also raised to me as an issue.

 =

<As Editor>

I think the reality is t= hat we=92ll all run into enterprises wanting multi-valued managers sooner o= r later.  Having it multi-valued doesn=92t mean you have to support mu= ltiple values.  But the important thing is that SCIM parsers will need to expect an array.

 =

Maybe we need a gener= al note that parsers should accept a single value JSON object even when an = attribute is multi-valued (for any multi-valued attribute).  This would make the issue non-breaking for clients (who think any attribute is single-valu= ed).  As for servers, it seems to me we have a compatibility issue due= to the spec inconsistency (while definition is single-value, examples are = multi-valued). That means regardless of our decisions some servers will have to be updated.

 =

Phil<= /o:p>

 

@independentid

phi= l.hunt@oracle.com<= /p>

 =

On May 5, 2015, at 2:14 = PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

 =

Speaking as an individual =96 I am not aware= of any IdM system that has multivalued =93manager=94. In addition in many = cases a multivalued manager brakes many applications as the reporting hierarchy is assumed to be a tree structure with a one to= many relationship not many to many. Unless someone has a solid use case fo= r turning this into a multivalued attribute, my vote as one of the implemen= tors is to fix the example and leave it as single valued.<= /p>

 

 

Cheers,

Morteza

 

From: Patrick Radtke <patrick.radtke@jivesoftware.com>
Date: Monday, May 4, 2015 at 4:10 PM
To: Phil Hunt <phil.hunt@oracle.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: "scim@ie= tf.org" <sci= m@ietf.org>, Michael Frost <michael.frost@oracle.com>
Subject: Re: [scim] Manager attribute wording suggestion

 

Is it too late in the process to make the at= tribute name plural (=93managers=94)? All the other multiValued attributes = I saw in core-schema use the plural form for the attribute name.

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, May 4, 2015 at 4:04 PM
To: Kelly Grizzle <kelly.grizzle@sailpoint.com>
Cc: Michael Frost <michael.frost@oracle.com>, Jive IT <patrick.radtke@jive= software.com>, SCIM WG <scim@ietf.org>
Subject: Re: [scim] Manager attribute wording suggestion

 

There are a couple of changes from the IESG = review coming to core-schema (for other reasons - emails to follow).=

 

With regards to this issue, I propose that t= he next update make =93manager=94 a multi-valued attribute so that it is co= nsistent with the examples and to correct the apparent inconsistency in the draft.

 

If there are any strong objections, please r= espond and discuss.

 

Thanks,

 

Phil<= /o:p>

 

@independentid

phil.hunt@oracle.com=

 

On Apr 30, 2015, at 1:50 PM, Kelly Grizzle &= lt;kelly.g= rizzle@sailpoint.com> wrote:=

 

It looks like this got changed back= in October in revision 12 of the core schema doc.

 

   Draft 12 - PH - Nits / Corrections

 =

      ...

 =

      Corrected enterprise = User manager attribute to use sub-attribute

      value and make multi-= valued

 

I hadn=92t realized that this chang= e went in.  Up until then manager had been single-valued since SCIM 1.= 0.  If there is consensus that this change should stay, then it seems like we need to update section 4.3.

 

Regarding the fact that =93required= =94 is false for the =93value=94 and =93$ref=94 sub-attributes, this is con= sistent with the rest of the attribute definitions that are references.  I agree with you, Patrick, that these should be= required.

 

--Kelly

 

 

Agreed.

 

Will need consensus/direction from the chair= s on this and along with the other issue (401/403/501 status code clarifica= tion).

 

 

On Apr 30, 2015, at 11:42 AM, Michael Frost = <michael.f= rost@oracle.com> wrote:

 

It is multi-valued in the example i= n 8.3 and in the schema on page 60, and in our implementation.  I thin= k only the text in section 4.3 refers to manager as singular.<= /p>

 

-mrf

 

From: Kelly Grizzle [mailto:kelly.griz= zle@sailpoint.com]
Sent: Thursday, April 30, 2015 10:28 AM
To: Phil Hunt
Cc: Patrick Radtke; SCIM WG
Subject: Re: [scim] Manager attribute wording suggestion

 

Does anyone have any strong opinion= s about making manager multi-valued or leaving it as-is?


Either way we should probably clean up the text in section 4.3 and the sche= ma definition.

 

 

 

I recall your comment and given lack of inpu= t at the time, it was clear there was no consensus for change. I had to lea= ve it as is despite thinking it needed to be multi-valued. 


Phil

I had forgotten about that.  T= he most discussion that I found was in this email - http://www.ietf.org/mail-archive/web/scim/current/msg02007.html.=

 

   Note, the schema also needs to be updated. It looks like it = should be multi-valued=

  since many orgs have people with mult= iple reporting relationships.=

 

I don=92t remember ever discussing = this any further or if we achieved consensus on changing this.  The em= ail thread doesn=92t have any more discussion.

 

I=92m not sure that I agree that th= is should be multivalued.  If anything else, I would never wish multip= le managers upon anyone. ;)  Being serious, though, this might fit better as a second attribute that describes other r= eporting relationships.

 

Anyone else remember this?

 

 

I believe I raised this issue before and the= consensus was to leave it.  Maybe I am mistaken?

 

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle &= lt;kelly.g= rizzle@sailpoint.com> wrote:=

 

Patrick =85 thanks for the feedback= .

 

I think that the schema section is = incorrect.  The $ref and value are required and manager is still singl= e valued.  I think the text in 4.3 should say:

 

manager

 =
     The user's manager.  A complex type that opti=
onally allows service<=
/pre>

 =
     providers to represent organizational hierarchy by=
 referencing the


&nb=
sp;     "id" attribute of another User.




 






Phil, do you agree?






 






--Kelly






 










From: scim [mailto:scim-bounces@ietf.org=
]
On Behalf Of Patrick Radtke

Sent: Friday, April 24, 2015 5:47 PM

To: SCIM WG

Subject: [scim] Manager attribute wording suggestion










 








There are a couple aspects of the =93manager=
=94 attribute that seem inconsistent.










 










In 4.3 Enterprise User Schema extension it s=
ays










"manager






 =
     The user's manager.  A complex type that opti=
onally allows service<=
/pre>

 =
     providers to represent organizational hierarchy by=
 referencing the


 =
     "id" attribute of another User.


 =



 =
     value  The "id" of the SCIM resourc=
e representing the user's


 =
        manager.  RECOMMENDED.


 =



 =
     $ref  The URI of the SCIM resource representi=
ng the User's


 =
        manager.  RECOMMENDED.






=93<=
/o:p>










To me that says that a user may have a singl=
e manager, and =91value=92 and =91$ref=92 attributes are not required.










 










However in the Schema section, manager is li=
sted as "multiValued: true=94 and though subAttributes of =93$ref=94 a=
nd =93value=94 have =93required:false=94 the description
 attribute says each is required.










 










If =93value=94 and =93$ref=94 aren=92t requi=
red, can the Manager schema description be adjusted?










Since manager is multi-valued, can section 4=
.3 be updated to say. "The
 user's managers.  A multi-valued complex type that=85=94  Otherw=
ise, at first read (or for anyone coming from SCIM 1.1) it is not obvious t=
hat it has become multi-valued.










 










Thanks,










 










Patrick










 










 










 










 

 

____________________________________________= ___
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



 =

--

Ian Glazer

Senior Director, Identit= y

+1 202 255 3166=

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

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

 

 --_000_D16FE197124524moransarciscocom_-- From nobody Wed May 6 16:02:22 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75D1B2A15; Wed, 6 May 2015 16:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTbbL1c49DDh; Wed, 6 May 2015 16:02:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC91C1B2A06; Wed, 6 May 2015 16:02:12 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t46N291F010198 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 May 2015 23:02:10 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t46N29Od005440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2015 23:02:09 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t46N28LR011470; Wed, 6 May 2015 23:02:08 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 May 2015 16:02:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5DB35F4C-3D74-4A85-AB66-C7A7DEEDB81D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> Date: Wed, 6 May 2015 16:02:05 -0700 Message-Id: <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 23:02:20 -0000 --Apple-Mail=_5DB35F4C-3D74-4A85-AB66-C7A7DEEDB81D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, Apologies for pasting a lot of text in here, but after considering = comments from you and Brian, I wanted to re-think a number of things and = try and boil things down a bit (I probably can do some more). I=E2=80=99ve= essentially re-written the authentication and security sections with = care not to change consensus, but to address the issues you mentioned. = I hope we are close. Please take a look at the pasted sections below. = If you are in agreement, I can post them in the next document update. Thanks for your help! Phil @independentid www.independentid.com phil.hunt@oracle.com ------------------------------ Section 2 Proposed: 2. Authentication and Authorization SCIM Protocol is based upon HTTP and does not itself define a SCIM specific scheme for authentication and authorization. SCIM depends on the use of TLS and/or standard HTTP authentication and authorization schemes as per [RFC7235]. For example, the following methodologies could be used among others: TLS Client Authentication The SCIM service provider MAY request TLS client authentication (also known as mutual authentication). See Section 7.3 [RFC5246]. HTTP Origin-Bound Authentication (HOBA) is a variation on TLS client authentication and uses a digital-signature-based design for an HTTP authentication method (see [RFC7486]). The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. Bearer Tokens Bearer tokens [RFC6750] MAY be used when combined with TLS and a token framework such as OAuth2 [RFC6749]. See Section 7.3 for security considerations regarding the use of bearer tokens in SCIM. While bearer tokens most often represent an authorization, it is assumed that the authorization was based upon a successful authentication of the SCIM client. Accordingly the SCIM service provider must have a method for validating, parsing, and or introspecting the bearer token for the relevant authentication and authorization information. The method for this is assumed to be defined by the token issuing system and is beyond the scope of this specification. POP Tokens A proof-of-possession token demonstrates the presenter of the token possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is sometimes also described as the presenter being a holder-of-key. See OAuth [I-D.ietf-oauth-pop-architecture] for an example of such a token and its use. Cookies Javascript clients MAY assert HTTP cookies over TLS that contain an authentication state that is understood by the SCIM service provider (see [RFC6265]). An example of this is scenarios where web-form authentication has taken place with the user and HTTP cookies were set representing the authentication state. For the purposes of SCIM, the security considerations in Section 7.3 apply. As per Section 4.1 of [RFC7235], a SCIM service provider SHALL indicate supported HTTP authentication schemes via the "WWW- Authenticate" header. For all of the above methodologies, the SCIM service provider MUST be able to map the authenticated client to an access control policy in order to determine the client's authorization to retrieve and update SCIM resources. For example, while a browser session may have been established via HTTP cookie or TLS client authentication, the unique client MUST be mapped to a security subject (e.g., User). The authorization model and the process by which this is done is beyond the scope of this specification. Because SCIM is a protocol for provisioning resources cross domains (e.g., user accounts and access control information such as groups), weaker authentication mechanisms based on static symmetric secrets such as passwords SHOULD NOT be used. In particular, the authentication schemes (e.g., Basic Authentication) described in [RFC2617] SHOULD NOT be used. When processing requests, the service provider SHOULD consider the subject performing the request and whether the action is appropriate given the subject and the resource affected by the request. The subject performing the request is usually determined directly or indirectly from the "Authorization" header present in the request. For example, a subject MAY be permitted to retrieve and update their own "User" resource, but will normally have restricted ability to access resources associated with other Users. In other cases, the SCIM service provider might only grant access to a subject's own associated "User" resource (e.g., for the purpose of updating personal contact attributes). For illustrative purposes only, examples show an OAuth2 bearer token value [RFC6750] in the authorization header; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 This is not intended to imply that bearer tokens are preferred. However, the use of bearer tokens in the specification does reflect common implementation practice. 2.1. Anonymous Requests In some SCIM deployments it MAY be acceptable to permit unauthenticated (anonymous) requests. For example, a user self- registration request where the service provider chooses to accept a SCIM Create request (see Section 3.3) from an anonymous client. See Section 7.5, for security considerations regarding anonymous requests. ------------------------------ Section 7 Proposed (note the example in 7.4 needs correction still): 7. Security Considerations 7.1. HTTP Considerations SCIM Protocol layers on top of Hypertext Transfer Protocol and thus subject to the security considerations of HTTP Section 9 [RFC7230] and its related specifications. As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate the userinfo (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message as they are now disallowed in HTTP. 7.2. TLS Support Considerations SCIM resources (e.g., Users and Groups) can contain sensitive information including passwords. Therefore, SCIM clients and service providers MUST require the use of a transport-layer security mechanism when communicating with SCIM service providers. The SCIM service provider MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per [RFC6125]. Implementation security considerations for TLS can be found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. 7.3. Bearer and Cookie Considerations Since the posession of a bearer token or cookie MAY authorize the holder to potentially read, modify, or delete resources, tokens and cookies MUST contain sufficient entropy to prevent a random guessing attack, such as described in Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819]. As with all SCIM communications, Bearer tokens and HTTP cookies MUST be exchanged using TLS. Bearer tokens MUST have a limited lifetime that can be determined directly or indirectly (e.g., by checking with a validation service) by the service provider. By expiring tokens, clients are forced to obtain a new token (which usually involves re-authentication) for continued authorized access. For example, in OAuth2, a client MAY use OAuth token refresh to obtain a new bearer token after authenticating to an authorization server. See Section 6 of [RFC6749]. As with Bearer tokens, an HTTP cookie SHOULD last no longer than the lifetime of a browser session. An expiry time should be set that limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. 7.4. Privacy Considerations 7.4.1. Personal Information The SCIM Core Schema specifications defines attributes that MAY contain personally identifying information as well as other sensitive personal data. The privacy considerations in the Security Considerations Section of [I-D.ietf-scim-core-schema] MUST be considered. 7.4.2. Disclosure of Sensitive Information in URIs As mentioned in Section 9.4 [RFC7231], SCIM clients requesting information using query filters using HTTP GET SHOULD give consideration to the information content of the filters and whether their exposure in a URI would represent a breach of security or confidentiality through leakage in a web browsers or server logs. This is particularly true for information that is legally considered "personally identifiable information" or is otherwise restricted by privacy laws. In these situations to ensure maximum security and confidentiality, clients SHOULD query using HTTP POST (see Section 3.4.3 ). Servers that receive HTTP GET requests using filters that contain restricted or confidential information SHOULD respond with HTTP status 403 indicating the operation is FORBIDDEN. A detailed error, "confidential_restricted" may be returned indicating the request must be submitted using POST. A non-normative example: HTTP/1.1 403 FORBIDDEN { "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "Errors":[ { "description": "Query filter involving 'name' is restricted or confidential", "error":"confidential_restricted" } ] } 7.5. Anonymous Requests If a SCIM service provider accepts anonymous requests such as SCIM resource creation requests (via HTTP POST), appropriate security measures should be put in place to prevent or limit exposure to attacks. The following counter-measures MAY be used: o Try to authenticate web UI components that forumulate the SCIM creation request. While the end-user MAY be anonymous, the web user interface component often has its own way to authenticate to the SCIM service provider (e.g., has an OAuth client credential [RFC6749]) and the web user interface component may implement its own measures (e.g., such as CAPTCHA) to ensure a ligitimate request is being made. o Limit the number of requests any particular client MAY make in a period of time. o For User resources, default newly created resource with an "active" setting of "false" and use a secondary confirmation process (e.g., email confirmation) to ensure the resource created is real. 7.6. Secure Storage and Handling of Sensitive Data An attacker may obtain valid username/password combinations from the SCIM service provider's underlying database by gaining access to the database and/or launching injection attacks. This could lead to unintended disclosure of username/password combinations. The impact may extend beyond the domain of the SCIM service provider if the data was provisioned from other domains. Administrators should undertake industry best practices to protect the storage of credentials and in particular SHOULD follow recommendations outlines in Section 5.1.4.1 [RFC6819]. These recommendations include but are not limited to: o Provide injection attack counter measures (e.g., by validating all inputs and parameters), o No cleartext storage of credentials, o Store credentials using an encrypted protection mechanism, and o Avoid passwords and consider use of asymmetric cryptography based credentials. As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take counter measures to prevent online attacks on secrets such as: o Utilize secure password policy in order to increase user password entrophy to hinder online attacks and password guessing, o Mitigate attacks on passwords by locking respective accounts have a number of failed attempts, o Use "tar pit" techniques by temporarily locking a respective account and delaying responses for a certain duration. The duration may increase with the number of failed attempts, and o Use authentication system that use CAPTCHA's and other factors for authenticating users further reducing the possibility of automated attacks. 7.7. Case Insensitive Comparison & International Languages When comparing unicode strings such as in query filters or testing for uniqueness of usernames and passwords, strings MUST be appropriately prepared before comparison. See Section 5. > On Apr 29, 2015, at 1:31 PM, Phil Hunt wrote: >=20 > Thanks. I think we have a plan! >=20 > Phil >=20 > On Apr 29, 2015, at 13:27, Kathleen Moriarty = > wrote: >=20 >> Hi Phil, >>=20 >> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt > wrote: >> Am I correct in assuming authentication is specifically excluded per = the charter. The assumption was/is SCIM uses typical http authen/authz = schemes and does not provide or mandate a method. >>=20 >> That said we have reservations about using 2617 mechanisms and prefer = stronger options. >>=20 >> Good. This needs to be stated explicitly because of existing = standards. My concerns are because of this text in your draft: >>=20 >> 2. Authentication and Authorization >>=20 >> Because SCIM builds on the HTTP protocol, it does not itself = define a >> scheme for authentication and authorization. SCIM depends on >> standard HTTP authentication schemes. Implementers SHOULD support >> existing authentication/authorization schemes. In particular, = OAuth2=20 >> (see [RFC6749], [RFC6750]) is RECOMMENDED.=20 >>=20 >> Because it says OAuth2 is recommended for authentication and you are = using this for bearer tokens, I am going to assume that the 3 options = established for that purpose are being used, with the default being HTTP = Basic. In my original discuss, I provided a link to the updated version = of Basic (in the RFC editor queue). When you recommend against it's = use, you should refer to the security considerations section of that = draft, it updates 2617 for Basic. Digest is in a separate update. >>=20 >> Since bearer tokens are used, I have to assume all of the security = issues with those as well. First is the IETF registered and supported = authentication methods, then the lack of security in the token itself. = Holder-of-key tokens require proof of possession (there is some crypto = to do this). The only thing you can do to protect a bearer token is to = use TLS and there needs to be a reference to the security section I = mentioned in my original post so users know where to look to understand = issues with bearer tokens. >>=20 >> I hope that helps. >>=20 >> Is this is the approach we are looking for? >> Yes, being explicit would be very helpful as I'll assume defaults and = limitations like registered/supported methods.=20 >>=20 >> Thank you, >> Kathleen >>=20 >>=20 >> Thanks, >>=20 >> Phil >>=20 >> > On Apr 29, 2015, at 13:08, Kathleen Moriarty = > wrote: >> > >> > Phil and I chatted a bit and he is working up some text with = specific >> > authentication options. I said I would look up some more = references and am >> > providing them inline here. >> > >> > On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < >> > kathleen.moriarty.ietf@gmail.com = > wrote: >> > >> >> Hi Phil, >> >> >> >> Just a quick response for now and more later. I'll find the = specific >> >> references and registry for authentication used with OAuth. I'm = the AD and >> >> have been reading their drafts carefully. >> >> >> >> Thanks, >> >> Kathleen >> >> >> >> Sent from my iPhone >> >> >> >>> On Apr 29, 2015, at 1:13 PM, Phil Hunt > wrote: >> >>> >> >>> Kathleen, >> >>> >> >>> Thanks for your comments. My comments in line=E2=80=A6 >> >>> >> >>> General comment. At the end of the day, SCIM is just an HTTP = protocol >> >> (an application) and as such can use any of the normal HTTP = mechanisms. In >> >> OAuth terms it is just a resource server. I wonder what we can = point to as >> >> a general best practice for authentication and authorization. >> > >> > Yes, the issue I hit was that the text of this draft said that = OAuth is the >> > authentication protocol, when it's only an authorization protocol. = As >> > such, a reader might jump to a conclusion that HTTP Basic is the = way to go >> > since it's the first method (and default) for OAuth in the OAuth = 2.0 >> > framework. Recent drafts that mention the same registry where the >> > supported authentication protocols from the client to the AS have = not >> > updated that short list. If you could rewrite the text to specify >> > recommended authentication types, that would be good. >> > >> > See section 2.3 of https://tools.ietf.org/html/rfc6749 = >> > and the 3 methods defined are stated again in the dyn registry = draft( >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg = ), basically >> > saying to authenticate to use a token, these methods are available: >> > >> > token_endpoint_auth_method >> > String indicator of the requested authentication method for = the >> > token endpoint. Values defined by this specification are: >> > >> > * "none": The client is a public client as defined in OAuth = 2.0 >> > and does not have a client secret. >> > * "client_secret_post": The client uses the HTTP POST = parameters >> > defined in OAuth 2.0 section 2.3.1. >> > * "client_secret_basic": the client uses HTTP Basic defined = in >> > OAuth 2.0 section 2.3.1 >> > >> > Additional values can be defined via the IANA OAuth Token = Endpoint >> > Authentication Methods Registry established in Section 4.2. >> > Absolute URIs can also be used as values for this parameter >> > without being registered. If unspecified or omitted, the = default >> > is "client_secret_basic", denoting HTTP Basic Authentication >> > Scheme as specified in Section 2.3.1 of OAuth 2.0. >> > >> > >> > >> > >> >> >> >>> The use of OAuth was in part, a reflection of the growing = popularity of >> >> OAuth at the time of writing, and I believe a conscious attempt by = the >> >> original authors to discourage the use of simple password = authentication >> >> such as RFC2617=E2=80=99s basic authentication. For this reason = we did not want to >> >> use Basic in the examples. >> > >> > It's specified as the default in OAuth 2.0 when using a token. see = above. >> > >> > Phil and I already chatted and he's planning to specify = recommendations >> > that are more secure since SCIM can use other authentication = methods. >> > >> > Please take a look at the reference I gave that spells out the = security >> > considerations for bearer tokens. They are not secure in of = themselves and >> > require the use of TLS 1.2 to prevent attacks. This needs to be = clearly >> > stated as well with a reference included to the draft I provided = that >> > already details the risks with bearer tokens. >> > >> > Thanks, >> > Kathleen >> > >> > >> >>> >> >>> Phil >> >>> >> >>> phil.hunt@yahoo.com >> >>> >> >>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty < >> >> Kathleen.Moriarty.ietf@gmail.com = > wrote: >> >>>> >> >>>> Kathleen Moriarty has entered the following ballot position for >> >>>> draft-ietf-scim-api-17: Discuss >> >>>> >> >>>> When responding, please keep the subject line intact and reply = to all >> >>>> email addresses included in the To and CC lines. (Feel free to = cut this >> >>>> introductory paragraph, however.) >> >>>> >> >>>> >> >>>> Please refer to >> >> https://www.ietf.org/iesg/statement/discuss-criteria.html = >> >>>> for more information about IESG DISCUSS and COMMENT positions. >> >>>> >> >>>> >> >>>> The document, along with other ballot positions, can be found = here: >> >>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ = >> >>>> >> >>>> >> >>>> >> >>>> = ---------------------------------------------------------------------- >> >>>> DISCUSS: >> >>>> = ---------------------------------------------------------------------- >> >>>> >> >>>> Thanks for your work on this draft. I have a few items I'd like = to >> >>>> discuss and have provided suggestions to help the discussion. I = think >> >>>> this should be fairly easy to get through. >> >>>> >> >>>> 1. OAuth is used for authorization and is limited to insecure = methods of >> >>>> authentication via HTTP supported methods and of those, OAuth = only has a >> >>>> few registered. HTTP Basic authentication is the default, which = is >> >>>> horrible. Later in this draft, SCIM encourages the use of = asymmetric >> >>>> crypto. Can this be the preferred option and there be more = details >> >>>> listed on how to do with (references)? >> >>>> >> >>>> What is specified now is really an authorization protocol, so = you'll >> >> need >> >>>> to say if HTTP Basic is what's used for authentication with = OAuth >> >>>> (default) or something else and then the security considerations = for >> >>>> OAuth bearer tokens and HHTP Basic. Here are some links to = help: >> >>>> >> >>>> A reference to security considerations from this draft will be = needed: >> >>>> see: = https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions = >> >>>> Reference to the HTTP Basic draft will be needed to show the = security >> >>>> issues with this option: >> >>>> = https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ = >> >>>> >> >>>> OAuth can't use something like HOBA in RFC7486, which was = designed to >> >>>> avoid the need for passwords when using HTTP Authentication. = Can SCIM >> >>>> work directly with other HTTP Auth methods like HOBA? The OAuth = folks >> >> are >> >>>> thinking about this problem, but aren't there yet (non-password = auth >> >>>> methods to then use Oauth authorization tokens). >> >>> [PH] >> >>> >> >>> The text suggests OAuth is recommended but not required reflects = what >> >> current implementers have been doing. I am opening to reducing = this from >> >> =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use other = equally secure mechanisms >> >> and to point out that the text based examples use bearer tokens to >> >> illustrate the use of the authorization header and are not = normative. >> >>> >> >>> Regarding OAuth. I don=E2=80=99t see why OAuth can=E2=80=99t use = HOBA. OAuth doesn=E2=80=99t >> >> care how authentication happens only that the parties are = authenticated >> >> before authorizing. OAuth and for that matter OIDC both depend on = using >> >> traditional (and emerging) authentication schemes to authenticate = users. >> >>> >> >>> That said, I see no reason why SCIM could not work directly with = HOBA. >> >> SCIM does not care, it merely assumes clients are authenticated = (presumably >> >> via session cookie or the authorization header). >> >>> >> >>> Regarding asymmetric crypto, I believe you are referring to = section 7.5=3D >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_5DB35F4C-3D74-4A85-AB66-C7A7DEEDB81D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

Apologies for pasting a lot of text in here, but after = considering comments from you and Brian, I wanted to re-think a number = of things and try and boil things down a bit (I probably can do some = more). I=E2=80=99ve essentially re-written the authentication and = security sections with care not to change consensus, but to address the = issues you mentioned.  I hope we are close.  Please take a = look at the pasted sections below. If you are in agreement, I can post = them in the next document update.

Thanks for your help!

Phil

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

------------------------------
<= /div>
Section 2 = Proposed:
2.  Authentication and Authorization

   SCIM Protocol is based upon HTTP and does not itself define a SCIM
   specific scheme for authentication and authorization.  SCIM depends
   on the use of TLS and/or standard HTTP authentication and
   authorization schemes as per [RFC7235].  For example, the following
   methodologies could be used among others:

   TLS Client Authentication
      The SCIM service provider MAY request TLS client authentication
      (also known as mutual authentication).  See Section 7.3 [RFC5246].

      HTTP Origin-Bound Authentication (HOBA) is a variation on TLS
      client authentication and uses a digital-signature-based design
      for an HTTP authentication method (see [RFC7486]).  The design can
      also be used in JavaScript-based authentication embedded in HTML.
      HOBA is an alternative to HTTP authentication schemes that require
      passwords and therefore avoids all problems related to passwords,
      such as leakage of server-side password databases.

   Bearer Tokens
      Bearer tokens [RFC6750] MAY be used when combined with TLS and a
      token framework such as OAuth2 [RFC6749].  See Section 7.3 for
      security considerations regarding the use of bearer tokens in
      SCIM.  While bearer tokens most often represent an authorization,
      it is assumed that the authorization was based upon a successful
      authentication of the SCIM client.  Accordingly the SCIM service
      provider must have a method for validating, parsing, and or
      introspecting the bearer token for the relevant authentication and
      authorization information.  The method for this is assumed to be
      defined by the token issuing system and is beyond the scope of
      this specification.

   POP Tokens
      A proof-of-possession token demonstrates the presenter of the
      token possesses a particular key and that the recipient can
      cryptographically confirm proof-of-possession of the key by the
      presenter.  This property is sometimes also described as the
      presenter being a holder-of-key.  See OAuth
      [I-D.ietf-oauth-pop-architecture] for an example of such a token
      and its use.

   Cookies
      Javascript clients MAY assert HTTP cookies over TLS that contain
      an authentication state that is understood by the SCIM service
      provider (see [RFC6265]).  An example of this is scenarios where
      web-form authentication has taken place with the user and HTTP
      cookies were set representing the authentication state.  For the
      purposes of SCIM, the security considerations in Section 7.3
      apply.

   As per Section 4.1 of [RFC7235], a SCIM service provider SHALL
   indicate supported HTTP authentication schemes via the "WWW-
   Authenticate" header.

   For all of the above methodologies, the SCIM service provider MUST be
   able to map the authenticated client to an access control policy in
   order to determine the client's authorization to retrieve and update
   SCIM resources.  For example, while a browser session may have been
   established via HTTP cookie or TLS client authentication, the unique
   client MUST be mapped to a security subject (e.g., User).  The
   authorization model and the process by which this is done is beyond
   the scope of this specification.

   Because SCIM is a protocol for provisioning resources cross domains
   (e.g., user accounts and access control information such as groups),
   weaker authentication mechanisms based on static symmetric secrets
   such as passwords SHOULD NOT be used.  In particular, the
   authentication schemes (e.g., Basic Authentication) described in
   [RFC2617] SHOULD NOT be used.

   When processing requests, the service provider SHOULD consider the
   subject performing the request and whether the action is appropriate
   given the subject and the resource affected by the request.  The
   subject performing the request is usually determined directly or
   indirectly from the "Authorization" header present in the request.
   For example, a subject MAY be permitted to retrieve and update their
   own "User" resource, but will normally have restricted ability to
   access resources associated with other Users.  In other cases, the
   SCIM service provider might only grant access to a subject's own
   associated "User" resource (e.g., for the purpose of updating
   personal contact attributes).

   For illustrative purposes only, examples show an OAuth2 bearer token
   value [RFC6750] in the authorization header; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   This is not intended to imply that bearer tokens are preferred.
   However, the use of bearer tokens in the specification does reflect
   common implementation practice.


2.1.  Anonymous Requests

   In some SCIM deployments it MAY be acceptable to permit
   unauthenticated (anonymous) requests.  For example, a user self-
   registration request where the service provider chooses to accept a
   SCIM Create request (see Section 3.3) from an anonymous client.  See
   Section 7.5, for security considerations regarding anonymous
   requests.

------------------------------
<= /div>
Section 7 Proposed (note the example in 7.4 needs correction = still):

7.  =
Security Considerations

7.1.  HTTP Considerations

   SCIM Protocol layers on top of Hypertext Transfer Protocol and thus
   subject to the security considerations of HTTP Section 9 [RFC7230]
   and its related specifications.

   As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
   the userinfo (i.e., username and password) component (and its "@"
   delimiter) when an "http" URI reference is generated with a message
   as they are now disallowed in HTTP.

7.2.  TLS Support Considerations

   SCIM resources (e.g., Users and Groups) can contain sensitive
   information including passwords.  Therefore, SCIM clients and service
   providers MUST require the use of a transport-layer security
   mechanism when communicating with SCIM service providers.  The SCIM
   service provider MUST support TLS 1.2 [RFC5246] and MAY support
   additional transport-layer mechanisms meeting its security
   requirements.  When using TLS, the client MUST perform a TLS/SSL
   server certificate check, per [RFC6125].  Implementation security
   considerations for TLS can be found in "Recommendations for Secure
   Use of TLS and DTLS" [RFC7525].

7.3.  Bearer and Cookie Considerations

   Since the posession of a bearer token or cookie MAY authorize the
   holder to potentially read, modify, or delete resources, tokens and
   cookies MUST contain sufficient entropy to prevent a random guessing
   attack, such as described in Section 5.2 of [RFC6750] and
   Section 5.1.4.2.2 of [RFC6819].

   As with all SCIM communications, Bearer tokens and HTTP cookies MUST
   be exchanged using TLS.

   Bearer tokens MUST have a limited lifetime that can be determined
   directly or indirectly (e.g., by checking with a validation service)
   by the service provider.  By expiring tokens, clients are forced to
   obtain a new token (which usually involves re-authentication) for
   continued authorized access.  For example, in OAuth2, a client MAY
   use OAuth token refresh to obtain a new bearer token after
   authenticating to an authorization server.  See Section 6 of
   [RFC6749].

   As with Bearer tokens, an HTTP cookie SHOULD last no longer than the
   lifetime of a browser session.  An expiry time should be set that
   limits session cookie lifetime as per Section 5.2.1 of [RFC6265].

7.4.  Privacy Considerations

7.4.1.  Personal Information

   The SCIM Core Schema specifications defines attributes that MAY
   contain personally identifying information as well as other sensitive
   personal data.  The privacy considerations in the Security
   Considerations Section of [I-D.ietf-scim-core-schema] MUST be
   considered.

7.4.2.  Disclosure of Sensitive Information in URIs

   As mentioned in Section 9.4 [RFC7231], SCIM clients requesting
   information using query filters using HTTP GET SHOULD give
   consideration to the information content of the filters and whether
   their exposure in a URI would represent a breach of security or
   confidentiality through leakage in a web browsers or server logs.
   This is particularly true for information that is legally considered
   "personally identifiable information" or is otherwise restricted by
   privacy laws.  In these situations to ensure maximum security and
   confidentiality, clients SHOULD query using HTTP POST (see
   Section 3.4.3 ).

   Servers that receive HTTP GET requests using filters that contain
   restricted or confidential information SHOULD respond with HTTP
   status 403 indicating the operation is FORBIDDEN.  A detailed error,
   "confidential_restricted" may be returned indicating the request must
   be submitted using POST.  A non-normative example:


  HTTP/1.1 403 FORBIDDEN

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "Errors":[
      {
        "description":
          "Query filter involving 'name' is restricted or confidential",
        "error":"confidential_restricted"
      }
    ]
  }

7.5.  Anonymous Requests

   If a SCIM service provider accepts anonymous requests such as SCIM
   resource creation requests (via HTTP POST), appropriate security
   measures should be put in place to prevent or limit exposure to
   attacks.  The following counter-measures MAY be used:

   o  Try to authenticate web UI components that forumulate the SCIM
      creation request.  While the end-user MAY be anonymous, the web
      user interface component often has its own way to authenticate to
      the SCIM service provider (e.g., has an OAuth client credential
      [RFC6749]) and the web user interface component may implement its
      own measures (e.g., such as CAPTCHA) to ensure a ligitimate
      request is being made.

   o  Limit the number of requests any particular client MAY make in a
      period of time.

   o  For User resources, default newly created resource with an
      "active" setting of "false" and use a secondary confirmation
      process (e.g., email confirmation) to ensure the resource created
      is real.

7.6.  Secure Storage and Handling of Sensitive Data

   An attacker may obtain valid username/password combinations from the
   SCIM service provider's underlying database by gaining access to the
   database and/or launching injection attacks.  This could lead to
   unintended disclosure of username/password combinations.  The impact
   may extend beyond the domain of the SCIM service provider if the data
   was provisioned from other domains.

   Administrators should undertake industry best practices to protect
   the storage of credentials and in particular SHOULD follow
   recommendations outlines in Section 5.1.4.1 [RFC6819].  These
   recommendations include but are not limited to:

   o  Provide injection attack counter measures (e.g., by validating all
      inputs and parameters),

   o  No cleartext storage of credentials,

   o  Store credentials using an encrypted protection mechanism, and

   o  Avoid passwords and consider use of asymmetric cryptography based
      credentials.

   As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take
   counter measures to prevent online attacks on secrets such as:

   o  Utilize secure password policy in order to increase user password
      entrophy to hinder online attacks and password guessing,

   o  Mitigate attacks on passwords by locking respective accounts have
      a number of failed attempts,

   o  Use "tar pit" techniques by temporarily locking a respective
      account and delaying responses for a certain duration.  The
      duration may increase with the number of failed attempts, and

   o  Use authentication system that use CAPTCHA's and other factors for
      authenticating users further reducing the possibility of automated
      attacks.

7.7.  Case Insensitive Comparison & International Languages

   When comparing unicode strings such as in query filters or testing
   for uniqueness of usernames and passwords, strings MUST be
   appropriately prepared before comparison.  See Section 5.

On Apr 29, 2015, at 1:31 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks. I think = we have a plan!

Phil
On Apr 29, 2015, at 13:27, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi Phil,

On Wed, = Apr 29, 2015 at 4:15 PM, Phil Hunt <phil.hunt@yahoo.com> wrote:
Am I correct in assuming  = authentication is specifically excluded per the charter. The assumption = was/is SCIM uses typical http authen/authz schemes and does not provide = or mandate a method.

That said we have reservations about using 2617 mechanisms and prefer = stronger options.

Good.  This needs to be stated = explicitly because of existing standards.  My concerns are because = of this text in your draft:

2. Authentication and Authorization Because SCIM builds on the HTTP protocol, it does not itself define a scheme for authentication and authorization. SCIM depends on standard HTTP authentication schemes. Implementers SHOULD support existing authentication/authorization schemes. In particular, = OAuth2 
   (see = [RFC6749], [RFC6750]) is RECOMMENDED. 

Because it says OAuth2 = is recommended for authentication and you are using this for bearer = tokens, I am going to assume that the 3 options established for that = purpose are being used, with the default being HTTP Basic.  In my = original discuss, I provided a link to the updated version of Basic (in = the RFC editor queue).  When you recommend against it's use, you = should refer to the security considerations section of that draft, it = updates 2617 for Basic.  Digest is in a separate update.

Since bearer tokens are = used, I have to assume all of the security issues with those as = well.  First is the IETF registered and supported authentication = methods, then the lack of security in the token itself.  = Holder-of-key tokens require proof of possession (there is some crypto = to do this).  The only thing you can do to protect a bearer token = is to use TLS and there needs to be a reference to the security section = I mentioned in my original post so users know where to look to = understand issues with bearer tokens.

I hope that helps.

Is this is the approach we are looking for?
Yes, being explicit would be = very helpful as I'll assume defaults and limitations like = registered/supported methods. 

Thank you,
Kathleen


Thanks,

Phil

> On Apr 29, 2015, at 13:08, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>
> Phil and I chatted a bit and he is working up some text with = specific
> authentication options.  I said I would look up some more = references and am
> providing them inline here.
>
> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>> Hi Phil,
>>
>> Just a quick response for now and more later.  I'll find = the specific
>> references and registry for authentication used with = OAuth.  I'm the AD and
>> have been reading their drafts carefully.
>>
>> Thanks,
>> Kathleen
>>
>> Sent from my iPhone
>>
>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt <phil.hunt@yahoo.com>= wrote:
>>>
>>> Kathleen,
>>>
>>> Thanks for your comments. My comments in line=E2=80=A6
>>>
>>> General comment.  At the end of the day, SCIM is just = an HTTP protocol
>> (an application) and as such can use any of the normal HTTP = mechanisms. In
>> OAuth terms it is just a resource server.  I wonder what = we can point to as
>> a general best practice for authentication and = authorization.
>
> Yes, the issue I hit was that the text of this draft said that = OAuth is the
> authentication protocol, when it's only an authorization = protocol.  As
> such, a reader might jump to a conclusion that HTTP Basic is the = way to go
> since it's the first method (and default) for OAuth in the OAuth = 2.0
> framework.  Recent drafts that mention the same registry where = the
> supported authentication protocols from the client to the AS have = not
> updated that short list.  If you could rewrite the text to = specify
> recommended authentication types, that would be good.
>
> See section 2.3 of https://tools.ietf.org/html/rfc6749
> and the 3 methods defined are stated again in the dyn registry = draft(
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg),= basically
> saying to authenticate to use a token, these methods are = available:
>
> token_endpoint_auth_method
>      String indicator of the requested = authentication method for the
>      token endpoint.  Values defined by this = specification are:
>
>      *  "none": The client is a public client = as defined in OAuth 2.0
>         and does not have a client = secret.
>      *  "client_secret_post": The client uses = the HTTP POST parameters
>         defined in OAuth 2.0 section = 2.3.1.
>      *  "client_secret_basic": the client uses = HTTP Basic defined in
>         OAuth 2.0 section 2.3.1
>
>      Additional values can be defined via the IANA = OAuth Token Endpoint
>      Authentication Methods Registry established in = Section 4.2.
>      Absolute URIs can also be used as values for = this parameter
>      without being registered.  If unspecified = or omitted, the default
>      is "client_secret_basic", denoting HTTP Basic = Authentication
>      Scheme as specified in Section 2.3.1 of OAuth = 2.0.
>
>
>
>
>>
>>> The use of OAuth was in part, a reflection of the growing = popularity of
>> OAuth at the time of writing, and I believe a conscious attempt = by the
>> original authors to discourage the use of simple password = authentication
>> such as RFC2617=E2=80=99s basic authentication.  For this = reason we did not want to
>> use Basic in the examples.
>
> It's specified as the default in OAuth 2.0 when using a = token.  see above.
>
> Phil and I already chatted and he's planning to specify = recommendations
> that are more secure since SCIM can use other authentication = methods.
>
> Please take a look at the reference I gave that spells out the = security
> considerations for bearer tokens.  They are not secure in of = themselves and
> require the use of TLS 1.2 to prevent attacks.  This needs to = be clearly
> stated as well with a reference included to the draft I provided = that
> already details the risks with bearer tokens.
>
> Thanks,
> Kathleen
>
>
>>>
>>> Phil
>>>
>>> phil.hunt@yahoo.com
>>>
>>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <
>> Kathleen.Moriarty.ietf@gmail.com> wrote:
>>>>
>>>> Kathleen Moriarty has entered the following ballot = position for
>>>> draft-ietf-scim-api-17: Discuss
>>>>
>>>> When responding, please keep the subject line intact = and reply to all
>>>> email addresses included in the To and CC lines. (Feel = free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT = positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be = found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/
>>>>
>>>>
>>>>
>>>> = ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> = ----------------------------------------------------------------------
>>>>
>>>> Thanks for your work on this draft.  I have a few = items I'd like to
>>>> discuss and have provided suggestions to help the = discussion.  I think
>>>> this should be fairly easy to get through.
= >>>>
>>>> 1. OAuth is used for authorization and is limited to = insecure methods of
>>>> authentication via HTTP supported methods and of those, = OAuth only has a
>>>> few registered.  HTTP Basic authentication is the = default, which is
>>>> horrible.  Later in this draft, SCIM encourages = the use of asymmetric
>>>> crypto.  Can this be the preferred option and = there be more details
>>>> listed on how to do with (references)?
>>>>
>>>> What is specified now is really an authorization = protocol, so you'll
>> need
>>>> to say if HTTP Basic is what's used for authentication = with OAuth
>>>> (default) or something else and then the security = considerations for
>>>> OAuth bearer tokens and HHTP Basic.  Here are some = links to help:
>>>>
>>>> A reference to security considerations from this draft = will be needed:
>>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
>>>> Reference to the HTTP Basic draft will be needed to = show the security
>>>> issues with this option:
>>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-= update/
>>>>
>>>> OAuth can't use something like HOBA in RFC7486, which = was designed to
>>>> avoid the need for passwords when using HTTP = Authentication.  Can SCIM
>>>> work directly with other HTTP Auth methods like HOBA? = The OAuth folks
>> are
>>>> thinking about this problem, but aren't there yet = (non-password auth
>>>> methods to then use Oauth authorization tokens).
>>> [PH]
>>>
>>> The text suggests OAuth is recommended but not required = reflects what
>> current implementers have been doing. I am opening to reducing = this from
>> =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use = other equally secure mechanisms
>> and to point out that the text based examples use bearer tokens = to
>> illustrate the use of the authorization header and are not = normative.
>>>
>>> Regarding OAuth.  I don=E2=80=99t see why OAuth = can=E2=80=99t use HOBA.  OAuth doesn=E2=80=99t
>> care how authentication happens only that the parties are = authenticated
>> before authorizing.  OAuth and for that matter OIDC both = depend on using
>> traditional (and emerging) authentication schemes to = authenticate users.
>>>
>>> That said, I see no reason why SCIM could not work directly = with HOBA.
>> SCIM does not care, it merely assumes clients are authenticated = (presumably
>> via session cookie or the authorization header).
>>>
>>> Regarding asymmetric crypto, I believe you are = referring to section 7.5=3D



--

Best regards,
Kathleen
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
______________________________________= _________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_5DB35F4C-3D74-4A85-AB66-C7A7DEEDB81D-- From nobody Wed May 6 17:10:44 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7299A1B29C8 for ; Wed, 6 May 2015 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQwYrjDV2kGw for ; Wed, 6 May 2015 17:10:35 -0700 (PDT) Received: from heisenberg.jivesoftware.com (heisenberg.jivesoftware.com [204.93.66.11]) by ietfa.amsl.com (Postfix) with ESMTP id 441AE1AD305 for ; Wed, 6 May 2015 17:10:30 -0700 (PDT) X-ASG-Debug-ID: 1430956785-059a6d043d831c70001-bGWiwh Received: from mail.jiveland.com (phxcas01.corp.jiveland.com [10.81.2.11]) by heisenberg.jivesoftware.com with ESMTP id xcGZFMfDVa0unR4u; Wed, 06 May 2015 16:59:45 -0700 (PDT) X-Barracuda-Envelope-From: patrick.radtke@jivesoftware.com Received: from MBX01.jiveland.com ([fe80::9982:7054:baaa:ab73]) by PHXCAS01.jiveland.com ([10.81.2.11]) with mapi id 14.03.0158.001; Wed, 6 May 2015 16:59:44 -0700 From: Patrick Radtke To: Phil Hunt , Kathleen Moriarty Thread-Topic: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-ASG-Orig-Subj: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) Thread-Index: AQHQghce/E9Dl2ugI0+i91Zwe2nKXZ1kPl18gACjUYD//5AgEoAAdlKAgAsqYYD//5q/gA== Date: Wed, 6 May 2015 23:59:43 +0000 Message-ID: References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> In-Reply-To: <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.32.204] Content-Type: multipart/alternative; boundary="_000_D16FF3DD17F3patrickradtkejivesoftwarecom_" MIME-Version: 1.0 X-Barracuda-Connect: phxcas01.corp.jiveland.com[10.81.2.11] X-Barracuda-Start-Time: 1430956785 X-Barracuda-URL: https://spamfirewall3.jiveland.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at jivesoftware.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0231 1.0000 -1.8712 X-Barracuda-Spam-Score: -1.87 X-Barracuda-Spam-Status: No, SCORE=-1.87 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18680 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 00:10:42 -0000 --_000_D16FF3DD17F3patrickradtkejivesoftwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Everything looked good to me except the Cookie authentication for JavaScrip= t clients - there is no guidance for CSRF protection. Two Cookie/CSRF attack scenarios that come to mind (based on this doc) http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/reference= /htmlsingle/#csrf-protection-and-json 1. Attacker site does cross site POST to /Users endpoint. The Service p= rovider does not check the Content-Type header, only looks at the Cookie an= d is fooled into thinking it is a legitimate request. 2. Attacker site does cross site POST using a URI suffix to /User.scim o= r /Users.json. The Service Provider=92s REST framework automatically sets a= Content-Type header based on URI suffix, and the actual implementation is = fooled into thinking Content-Type header was set by the client. Maybe some guidance along the lines of =93To prevent CSRF attacks the servi= ce provider MUST check the Content-Type of the request and MUST NOT allow P= OSTs to uri suffixed endpoints" -Patrick From: Phil Hunt > Date: Wednesday, May 6, 2015 at 4:02 PM To: Kathleen Moriarty > Cc: "draft-ietf-scim-api.ad@ietf.org" = >, "scim@ietf.org" >, "draft-ietf-scim-api.shepherd@ietf.org" >, The IESG >,= "draft-ietf-scim-api@ietf.org" >, "scim-chairs= @ietf.org" > Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: = (with DISCUSS and COMMENT) Kathleen, Apologies for pasting a lot of text in here, but after considering comments= from you and Brian, I wanted to re-think a number of things and try and bo= il things down a bit (I probably can do some more). I=92ve essentially re-w= ritten the authentication and security sections with care not to change con= sensus, but to address the issues you mentioned. I hope we are close. Ple= ase take a look at the pasted sections below. If you are in agreement, I ca= n post them in the next document update. Thanks for your help! Phil @independentid www.independentid.com phil.hunt@oracle.com ------------------------------ Section 2 Proposed: 2. Authentication and Authorization SCIM Protocol is based upon HTTP and does not itself define a SCIM specific scheme for authentication and authorization. SCIM depends on the use of TLS and/or standard HTTP authentication and authorization schemes as per [RFC7235]. For example, the following methodologies could be used among others: TLS Client Authentication The SCIM service provider MAY request TLS client authentication (also known as mutual authentication). See Section 7.3 [RFC5246]. HTTP Origin-Bound Authentication (HOBA) is a variation on TLS client authentication and uses a digital-signature-based design for an HTTP authentication method (see [RFC7486]). The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. Bearer Tokens Bearer tokens [RFC6750] MAY be used when combined with TLS and a token framework such as OAuth2 [RFC6749]. See Section 7.3 for security considerations regarding the use of bearer tokens in SCIM. While bearer tokens most often represent an authorization, it is assumed that the authorization was based upon a successful authentication of the SCIM client. Accordingly the SCIM service provider must have a method for validating, parsing, and or introspecting the bearer token for the relevant authentication and authorization information. The method for this is assumed to be defined by the token issuing system and is beyond the scope of this specification. POP Tokens A proof-of-possession token demonstrates the presenter of the token possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is sometimes also described as the presenter being a holder-of-key. See OAuth [I-D.ietf-oauth-pop-architecture] for an example of such a token and its use. Cookies Javascript clients MAY assert HTTP cookies over TLS that contain an authentication state that is understood by the SCIM service provider (see [RFC6265]). An example of this is scenarios where web-form authentication has taken place with the user and HTTP cookies were set representing the authentication state. For the purposes of SCIM, the security considerations in Section 7.3 apply. As per Section 4.1 of [RFC7235], a SCIM service provider SHALL indicate supported HTTP authentication schemes via the "WWW- Authenticate" header. For all of the above methodologies, the SCIM service provider MUST be able to map the authenticated client to an access control policy in order to determine the client's authorization to retrieve and update SCIM resources. For example, while a browser session may have been established via HTTP cookie or TLS client authentication, the unique client MUST be mapped to a security subject (e.g., User). The authorization model and the process by which this is done is beyond the scope of this specification. Because SCIM is a protocol for provisioning resources cross domains (e.g., user accounts and access control information such as groups), weaker authentication mechanisms based on static symmetric secrets such as passwords SHOULD NOT be used. In particular, the authentication schemes (e.g., Basic Authentication) described in [RFC2617] SHOULD NOT be used. When processing requests, the service provider SHOULD consider the subject performing the request and whether the action is appropriate given the subject and the resource affected by the request. The subject performing the request is usually determined directly or indirectly from the "Authorization" header present in the request. For example, a subject MAY be permitted to retrieve and update their own "User" resource, but will normally have restricted ability to access resources associated with other Users. In other cases, the SCIM service provider might only grant access to a subject's own associated "User" resource (e.g., for the purpose of updating personal contact attributes). For illustrative purposes only, examples show an OAuth2 bearer token value [RFC6750] in the authorization header; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8 This is not intended to imply that bearer tokens are preferred. However, the use of bearer tokens in the specification does reflect common implementation practice. 2.1. Anonymous Requests In some SCIM deployments it MAY be acceptable to permit unauthenticated (anonymous) requests. For example, a user self- registration request where the service provider chooses to accept a SCIM Create request (see Section 3.3) from an anonymous client. See Section 7.5, for security considerations regarding anonymous requests. ------------------------------ Section 7 Proposed (note the example in 7.4 needs correction still): 7. Security Considerations 7.1. HTTP Considerations SCIM Protocol layers on top of Hypertext Transfer Protocol and thus subject to the security considerations of HTTP Section 9 [RFC7230] and its related specifications. As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate the userinfo (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message as they are now disallowed in HTTP. 7.2. TLS Support Considerations SCIM resources (e.g., Users and Groups) can contain sensitive information including passwords. Therefore, SCIM clients and service providers MUST require the use of a transport-layer security mechanism when communicating with SCIM service providers. The SCIM service provider MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per [RFC6125]. Implementation security considerations for TLS can be found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. 7.3. Bearer and Cookie Considerations Since the posession of a bearer token or cookie MAY authorize the holder to potentially read, modify, or delete resources, tokens and cookies MUST contain sufficient entropy to prevent a random guessing attack, such as described in Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819]. As with all SCIM communications, Bearer tokens and HTTP cookies MUST be exchanged using TLS. Bearer tokens MUST have a limited lifetime that can be determined directly or indirectly (e.g., by checking with a validation service) by the service provider. By expiring tokens, clients are forced to obtain a new token (which usually involves re-authentication) for continued authorized access. For example, in OAuth2, a client MAY use OAuth token refresh to obtain a new bearer token after authenticating to an authorization server. See Section 6 of [RFC6749]. As with Bearer tokens, an HTTP cookie SHOULD last no longer than the lifetime of a browser session. An expiry time should be set that limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. 7.4. Privacy Considerations 7.4.1. Personal Information The SCIM Core Schema specifications defines attributes that MAY contain personally identifying information as well as other sensitive personal data. The privacy considerations in the Security Considerations Section of [I-D.ietf-scim-core-schema] MUST be considered. 7.4.2. Disclosure of Sensitive Information in URIs As mentioned in Section 9.4 [RFC7231], SCIM clients requesting information using query filters using HTTP GET SHOULD give consideration to the information content of the filters and whether their exposure in a URI would represent a breach of security or confidentiality through leakage in a web browsers or server logs. This is particularly true for information that is legally considered "personally identifiable information" or is otherwise restricted by privacy laws. In these situations to ensure maximum security and confidentiality, clients SHOULD query using HTTP POST (see Section 3.4.3 ). Servers that receive HTTP GET requests using filters that contain restricted or confidential information SHOULD respond with HTTP status 403 indicating the operation is FORBIDDEN. A detailed error, "confidential_restricted" may be returned indicating the request must be submitted using POST. A non-normative example: HTTP/1.1 403 FORBIDDEN { "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "Errors":[ { "description": "Query filter involving 'name' is restricted or confidential", "error":"confidential_restricted" } ] } 7.5. Anonymous Requests If a SCIM service provider accepts anonymous requests such as SCIM resource creation requests (via HTTP POST), appropriate security measures should be put in place to prevent or limit exposure to attacks. The following counter-measures MAY be used: o Try to authenticate web UI components that forumulate the SCIM creation request. While the end-user MAY be anonymous, the web user interface component often has its own way to authenticate to the SCIM service provider (e.g., has an OAuth client credential [RFC6749]) and the web user interface component may implement its own measures (e.g., such as CAPTCHA) to ensure a ligitimate request is being made. o Limit the number of requests any particular client MAY make in a period of time. o For User resources, default newly created resource with an "active" setting of "false" and use a secondary confirmation process (e.g., email confirmation) to ensure the resource created is real. 7.6. Secure Storage and Handling of Sensitive Data An attacker may obtain valid username/password combinations from the SCIM service provider's underlying database by gaining access to the database and/or launching injection attacks. This could lead to unintended disclosure of username/password combinations. The impact may extend beyond the domain of the SCIM service provider if the data was provisioned from other domains. Administrators should undertake industry best practices to protect the storage of credentials and in particular SHOULD follow recommendations outlines in Section 5.1.4.1 [RFC6819]. These recommendations include but are not limited to: o Provide injection attack counter measures (e.g., by validating all inputs and parameters), o No cleartext storage of credentials, o Store credentials using an encrypted protection mechanism, and o Avoid passwords and consider use of asymmetric cryptography based credentials. As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take counter measures to prevent online attacks on secrets such as: o Utilize secure password policy in order to increase user password entrophy to hinder online attacks and password guessing, o Mitigate attacks on passwords by locking respective accounts have a number of failed attempts, o Use "tar pit" techniques by temporarily locking a respective account and delaying responses for a certain duration. The duration may increase with the number of failed attempts, and o Use authentication system that use CAPTCHA's and other factors for authenticating users further reducing the possibility of automated attacks. 7.7. Case Insensitive Comparison & International Languages When comparing unicode strings such as in query filters or testing for uniqueness of usernames and passwords, strings MUST be appropriately prepared before comparison. See Section 5. On Apr 29, 2015, at 1:31 PM, Phil Hunt > wrote: Thanks. I think we have a plan! Phil On Apr 29, 2015, at 13:27, Kathleen Moriarty > wrote: Hi Phil, On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt > wrote: Am I correct in assuming authentication is specifically excluded per the c= harter. The assumption was/is SCIM uses typical http authen/authz schemes a= nd does not provide or mandate a method. That said we have reservations about using 2617 mechanisms and prefer stron= ger options. Good. This needs to be stated explicitly because of existing standards. M= y concerns are because of this text in your draft: 2. Authentication and Authorization Because SCIM builds on the HTTP protocol, it does not itself define a scheme for authentication and authorization. SCIM depends on standard HTTP authentication schemes. Implementers SHOULD support existing authentication/authorization schemes. In particular, OAuth2 (see [RFC6749], [RFC6750]) is RECOMMENDED. Because it says OAuth2 is recommended for authentication and you are using = this for bearer tokens, I am going to assume that the 3 options established= for that purpose are being used, with the default being HTTP Basic. In my= original discuss, I provided a link to the updated version of Basic (in th= e RFC editor queue). When you recommend against it's use, you should refer= to the security considerations section of that draft, it updates 2617 for = Basic. Digest is in a separate update. Since bearer tokens are used, I have to assume all of the security issues w= ith those as well. First is the IETF registered and supported authenticati= on methods, then the lack of security in the token itself. Holder-of-key t= okens require proof of possession (there is some crypto to do this). The o= nly thing you can do to protect a bearer token is to use TLS and there need= s to be a reference to the security section I mentioned in my original post= so users know where to look to understand issues with bearer tokens. I hope that helps. Is this is the approach we are looking for? Yes, being explicit would be very helpful as I'll assume defaults and limit= ations like registered/supported methods. Thank you, Kathleen Thanks, Phil > On Apr 29, 2015, at 13:08, Kathleen Moriarty > wrote: > > Phil and I chatted a bit and he is working up some text with specific > authentication options. I said I would look up some more references and = am > providing them inline here. > > On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com= > wrote: > >> Hi Phil, >> >> Just a quick response for now and more later. I'll find the specific >> references and registry for authentication used with OAuth. I'm the AD = and >> have been reading their drafts carefully. >> >> Thanks, >> Kathleen >> >> Sent from my iPhone >> >>> On Apr 29, 2015, at 1:13 PM, Phil Hunt > wrote: >>> >>> Kathleen, >>> >>> Thanks for your comments. My comments in line=85 >>> >>> General comment. At the end of the day, SCIM is just an HTTP protocol >> (an application) and as such can use any of the normal HTTP mechanisms. = In >> OAuth terms it is just a resource server. I wonder what we can point to= as >> a general best practice for authentication and authorization. > > Yes, the issue I hit was that the text of this draft said that OAuth is t= he > authentication protocol, when it's only an authorization protocol. As > such, a reader might jump to a conclusion that HTTP Basic is the way to g= o > since it's the first method (and default) for OAuth in the OAuth 2.0 > framework. Recent drafts that mention the same registry where the > supported authentication protocols from the client to the AS have not > updated that short list. If you could rewrite the text to specify > recommended authentication types, that would be good. > > See section 2.3 of https://tools.ietf.org/html/rfc6749 > and the 3 methods defined are stated again in the dyn registry draft( > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically > saying to authenticate to use a token, these methods are available: > > token_endpoint_auth_method > String indicator of the requested authentication method for the > token endpoint. Values defined by this specification are: > > * "none": The client is a public client as defined in OAuth 2.0 > and does not have a client secret. > * "client_secret_post": The client uses the HTTP POST parameters > defined in OAuth 2.0 section 2.3.1. > * "client_secret_basic": the client uses HTTP Basic defined in > OAuth 2.0 section 2.3.1 > > Additional values can be defined via the IANA OAuth Token Endpoint > Authentication Methods Registry established in Section 4.2. > Absolute URIs can also be used as values for this parameter > without being registered. If unspecified or omitted, the default > is "client_secret_basic", denoting HTTP Basic Authentication > Scheme as specified in Section 2.3.1 of OAuth 2.0. > > > > >> >>> The use of OAuth was in part, a reflection of the growing popularity of >> OAuth at the time of writing, and I believe a conscious attempt by the >> original authors to discourage the use of simple password authentication >> such as RFC2617=92s basic authentication. For this reason we did not wa= nt to >> use Basic in the examples. > > It's specified as the default in OAuth 2.0 when using a token. see above= . > > Phil and I already chatted and he's planning to specify recommendations > that are more secure since SCIM can use other authentication methods. > > Please take a look at the reference I gave that spells out the security > considerations for bearer tokens. They are not secure in of themselves a= nd > require the use of TLS 1.2 to prevent attacks. This needs to be clearly > stated as well with a reference included to the draft I provided that > already details the risks with bearer tokens. > > Thanks, > Kathleen > > >>> >>> Phil >>> >>> phil.hunt@yahoo.com >>> >>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty < >> Kathleen.Moriarty.ietf@gmail.com> wrote: >>>> >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-scim-api-17: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut thi= s >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> Thanks for your work on this draft. I have a few items I'd like to >>>> discuss and have provided suggestions to help the discussion. I think >>>> this should be fairly easy to get through. >>>> >>>> 1. OAuth is used for authorization and is limited to insecure methods = of >>>> authentication via HTTP supported methods and of those, OAuth only has= a >>>> few registered. HTTP Basic authentication is the default, which is >>>> horrible. Later in this draft, SCIM encourages the use of asymmetric >>>> crypto. Can this be the preferred option and there be more details >>>> listed on how to do with (references)? >>>> >>>> What is specified now is really an authorization protocol, so you'll >> need >>>> to say if HTTP Basic is what's used for authentication with OAuth >>>> (default) or something else and then the security considerations for >>>> OAuth bearer tokens and HHTP Basic. Here are some links to help: >>>> >>>> A reference to security considerations from this draft will be needed: >>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions >>>> Reference to the HTTP Basic draft will be needed to show the security >>>> issues with this option: >>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >>>> >>>> OAuth can't use something like HOBA in RFC7486, which was designed to >>>> avoid the need for passwords when using HTTP Authentication. Can SCIM >>>> work directly with other HTTP Auth methods like HOBA? The OAuth folks >> are >>>> thinking about this problem, but aren't there yet (non-password auth >>>> methods to then use Oauth authorization tokens). >>> [PH] >>> >>> The text suggests OAuth is recommended but not required reflects what >> current implementers have been doing. I am opening to reducing this from >> =93RECOMMENDED=94 and allowing deployers to use other equally secure mec= hanisms >> and to point out that the text based examples use bearer tokens to >> illustrate the use of the authorization header and are not normative. >>> >>> Regarding OAuth. I don=92t see why OAuth can=92t use HOBA. OAuth does= n=92t >> care how authentication happens only that the parties are authenticated >> before authorizing. OAuth and for that matter OIDC both depend on using >> traditional (and emerging) authentication schemes to authenticate users. >>> >>> That said, I see no reason why SCIM could not work directly with HOBA. >> SCIM does not care, it merely assumes clients are authenticated (presuma= bly >> via session cookie or the authorization header). >>> >>> Regarding asymmetric crypto, I believe you are referring to section 7.5= =3D -- Best regards, Kathleen _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D16FF3DD17F3patrickradtkejivesoftwarecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Everything looked good to me except the Cookie authentication for JavaScrip= t clients - there is no guidance for CSRF protection.
Two Cookie/CSRF attack scenarios that come to mind (based on this doc)

  1. Attacker site does cross site POST to /Users endpoint.  The Servic= e provider does not check the Content-Type header, only looks at the Cookie= and is fooled into thinking it is a legitimate request.
  2. Attacker s= ite does cross site POST using a URI suffix to /User.scim or /Users.json. T= he Service Provider=92s REST framework automatically sets a Content-Type he= ader based on URI suffix, and the actual implementation is fooled into thin= king Content-Type header was set by the client.
Maybe some guidance = along the lines of =93To prevent CSRF attacks the service provider MUST check the Content-Type of the request and MUST NOT allow POSTs to uri suffixed endpoints"

-Patrick

From: Phil Hunt <phil.hunt@oracle.com>
Date: Wednesday, May 6, 2015 at 4:0= 2 PM
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c= om>
Cc: "draft-ietf-scim-api.ad@ietf.org" <draft-ietf-scim-api.ad@ietf= .org>, "scim@ietf.org"= ; <scim@ietf.org>, "draft-ietf-scim-api.sheph= erd@ietf.org" <draft-ietf-scim-api.shepherd@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-scim-api@ietf.org&q= uot; <draft-ietf-scim-ap= i@ietf.org>, "scim-chai= rs@ietf.org" <scim-chairs@ietf.org> Subject: Re: [scim] Kathleen Moriar= ty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT)

Kathleen,

Apologies for pasting a lot of text in here, but after cons= idering comments from you and Brian, I wanted to re-think a number of thing= s and try and boil things down a bit (I probably can do some more). I=92ve = essentially re-written the authentication and security sections with care not to change consensus, but to address th= e issues you mentioned.  I hope we are close.  Please take a look= at the pasted sections below. If you are in agreement, I can post them in = the next document update.

Thanks for your help!

Phil

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

------------------------------
Section 2 Proposed:
2.  Authentication and Authorization

   SCIM Protocol is based upon HTTP and does not itself define a SCIM
   specific scheme for authentication and authorization.  SCIM depends
   on the use of TLS and/or standard HTTP authentication and
   authorization schemes as per [RFC7235].  For example, the following
   methodologies could be used among others:

   TLS Client Authentication
      The SCIM service provider MAY request TLS client authentication
      (also known as mutual authentication).  See Section 7.3 [RFC5246].

      HTTP Origin-Bound Authentication (HOBA) is a variation on TLS
      client authentication and uses a digital-signature-based design
      for an HTTP authentication method (see [RFC7486]).  The design can
      also be used in JavaScript-based authentication embedded in HTML.
      HOBA is an alternative to HTTP authentication schemes that require
      passwords and therefore avoids all problems related to passwords,
      such as leakage of server-side password databases.

   Bearer Tokens
      Bearer tokens [RFC6750] MAY be used when combined with TLS and a
      token framework such as OAuth2 [RFC6749].  See Section 7.3 for
      security considerations regarding the use of bearer tokens in
      SCIM.  While bearer tokens most often represent an authorization,
      it is assumed that the authorization was based upon a successful
      authentication of the SCIM client.  Accordingly the SCIM service
      provider must have a method for validating, parsing, and or
      introspecting the bearer token for the relevant authentication and
      authorization information.  The method for this is assumed to be
      defined by the token issuing system and is beyond the scope of
      this specification.

   POP Tokens
      A proof-of-possession token demonstrates the presenter of the
      token possesses a particular key and that the recipient can
      cryptographically confirm proof-of-possession of the key by the
      presenter.  This property is sometimes also described as the
      presenter being a holder-of-key.  See OAuth
      [I-D.ietf-oauth-pop-architecture] for an example of such a token
      and its use.

   Cookies
      Javascript clients MAY assert HTTP cookies over TLS that contain
      an authentication state that is understood by the SCIM service
      provider (see [RFC6265]).  An example of this is scenarios where
      web-form authentication has taken place with the user and HTTP
      cookies were set representing the authentication state.  For the
      purposes of SCIM, the security considerations in Section 7.3
      apply.

   As per Section 4.1 of [RFC7235], a SCIM service provider SHALL
   indicate supported HTTP authentication schemes via the "WWW-
   Authenticate" header.

   For all of the above methodologies, the SCIM service provider MUST be
   able to map the authenticated client to an access control policy in
   order to determine the client's authorization to retrieve and update
   SCIM resources.  For example, while a browser session may have been
   established via HTTP cookie or TLS client authentication, the unique
   client MUST be mapped to a security subject (e.g., User).  The
   authorization model and the process by which this is done is beyond
   the scope of this specification.

   Because SCIM is a protocol for provisioning resources cross domains
   (e.g., user accounts and access control information such as groups),
   weaker authentication mechanisms based on static symmetric secrets
   such as passwords SHOULD NOT be used.  In particular, the
   authentication schemes (e.g., Basic Authentication) described in
   [RFC2617] SHOULD NOT be used.

   When processing requests, the service provider SHOULD consider the
   subject performing the request and whether the action is appropriate
   given the subject and the resource affected by the request.  The
   subject performing the request is usually determined directly or
   indirectly from the "Authorization" header present in the requ=
est.
   For example, a subject MAY be permitted to retrieve and update their
   own "User" resource, but will normally have restricted ability=
 to
   access resources associated with other Users.  In other cases, the
   SCIM service provider might only grant access to a subject's own
   associated "User" resource (e.g., for the purpose of updating
   personal contact attributes).

   For illustrative purposes only, examples show an OAuth2 bearer token
   value [RFC6750] in the authorization header; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   This is not intended to imply that bearer tokens are preferred.
   However, the use of bearer tokens in the specification does reflect
   common implementation practice.


2.1.  Anonymous Requests

   In some SCIM deployments it MAY be acceptable to permit
   unauthenticated (anonymous) requests.  For example, a user self-
   registration request where the service provider chooses to accept a
   SCIM Create request (see Section 3.3) from an anonymous client.  See
   Section 7.5, for security considerations regarding anonymous
   requests.

------------------------------
Section 7 Proposed (note the example in 7.4 needs correction still):

7. =
 Security Considerations

7.1.  HTTP Considerations

   SCIM Protocol layers on top of Hypertext Transfer Protocol and thus
   subject to the security considerations of HTTP Section 9 [RFC7230]
   and its related specifications.

   As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
   the userinfo (i.e., username and password) component (and its "@&qu=
ot;
   delimiter) when an "http" URI reference is generated with a me=
ssage
   as they are now disallowed in HTTP.

7.2.  TLS Support Considerations

   SCIM resources (e.g., Users and Groups) can contain sensitive
   information including passwords.  Therefore, SCIM clients and service
   providers MUST require the use of a transport-layer security
   mechanism when communicating with SCIM service providers.  The SCIM
   service provider MUST support TLS 1.2 [RFC5246] and MAY support
   additional transport-layer mechanisms meeting its security
   requirements.  When using TLS, the client MUST perform a TLS/SSL
   server certificate check, per [RFC6125].  Implementation security
   considerations for TLS can be found in "Recommendations for Secure
   Use of TLS and DTLS" [RFC7525].

7.3.  Bearer and Cookie Considerations

   Since the posession of a bearer token or cookie MAY authorize the
   holder to potentially read, modify, or delete resources, tokens and
   cookies MUST contain sufficient entropy to prevent a random guessing
   attack, such as described in Section 5.2 of [RFC6750] and
   Section 5.1.4.2.2 of [RFC6819].

   As with all SCIM communications, Bearer tokens and HTTP cookies MUST
   be exchanged using TLS.

   Bearer tokens MUST have a limited lifetime that can be determined
   directly or indirectly (e.g., by checking with a validation service)
   by the service provider.  By expiring tokens, clients are forced to
   obtain a new token (which usually involves re-authentication) for
   continued authorized access.  For example, in OAuth2, a client MAY
   use OAuth token refresh to obtain a new bearer token after
   authenticating to an authorization server.  See Section 6 of
   [RFC6749].

   As with Bearer tokens, an HTTP cookie SHOULD last no longer than the
   lifetime of a browser session.  An expiry time should be set that
   limits session cookie lifetime as per Section 5.2.1 of [RFC6265].

7.4.  Privacy Considerations

7.4.1.  Personal Information

   The SCIM Core Schema specifications defines attributes that MAY
   contain personally identifying information as well as other sensitive
   personal data.  The privacy considerations in the Security
   Considerations Section of [I-D.ietf-scim-core-schema] MUST be
   considered.

7.4.2.  Disclosure of Sensitive Information in URIs

   As mentioned in Section 9.4 [RFC7231], SCIM clients requesting
   information using query filters using HTTP GET SHOULD give
   consideration to the information content of the filters and whether
   their exposure in a URI would represent a breach of security or
   confidentiality through leakage in a web browsers or server logs.
   This is particularly true for information that is legally considered
   "personally identifiable information" or is otherwise restrict=
ed by
   privacy laws.  In these situations to ensure maximum security and
   confidentiality, clients SHOULD query using HTTP POST (see
   Section 3.4.3 ).

   Servers that receive HTTP GET requests using filters that contain
   restricted or confidential information SHOULD respond with HTTP
   status 403 indicating the operation is FORBIDDEN.  A detailed error,
   "confidential_restricted" may be returned indicating the reque=
st must
   be submitted using POST.  A non-normative example:


  HTTP/1.1 403 FORBIDDEN

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error=
"],
    "Errors":[
      {
        "description":
          "Query filter involving 'name' is restricted or confidential=
",
        "error":"confidential_restricted"
      }
    ]
  }

7.5.  Anonymous Requests

   If a SCIM service provider accepts anonymous requests such as SCIM
   resource creation requests (via HTTP POST), appropriate security
   measures should be put in place to prevent or limit exposure to
   attacks.  The following counter-measures MAY be used:

   o  Try to authenticate web UI components that forumulate the SCIM
      creation request.  While the end-user MAY be anonymous, the web
      user interface component often has its own way to authenticate to
      the SCIM service provider (e.g., has an OAuth client credential
      [RFC6749]) and the web user interface component may implement its
      own measures (e.g., such as CAPTCHA) to ensure a ligitimate
      request is being made.

   o  Limit the number of requests any particular client MAY make in a
      period of time.

   o  For User resources, default newly created resource with an
      "active" setting of "false" and use a secondary c=
onfirmation
      process (e.g., email confirmation) to ensure the resource created
      is real.

7.6.  Secure Storage and Handling of Sensitive Data

   An attacker may obtain valid username/password combinations from the
   SCIM service provider's underlying database by gaining access to the
   database and/or launching injection attacks.  This could lead to
   unintended disclosure of username/password combinations.  The impact
   may extend beyond the domain of the SCIM service provider if the data
   was provisioned from other domains.

   Administrators should undertake industry best practices to protect
   the storage of credentials and in particular SHOULD follow
   recommendations outlines in Section 5.1.4.1 [RFC6819].  These
   recommendations include but are not limited to:

   o  Provide injection attack counter measures (e.g., by validating all
      inputs and parameters),

   o  No cleartext storage of credentials,

   o  Store credentials using an encrypted protection mechanism, and

   o  Avoid passwords and consider use of asymmetric cryptography based
      credentials.

   As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take
   counter measures to prevent online attacks on secrets such as:

   o  Utilize secure password policy in order to increase user password
      entrophy to hinder online attacks and password guessing,

   o  Mitigate attacks on passwords by locking respective accounts have
      a number of failed attempts,

   o  Use "tar pit" techniques by temporarily locking a respectiv=
e
      account and delaying responses for a certain duration.  The
      duration may increase with the number of failed attempts, and

   o  Use authentication system that use CAPTCHA's and other factors for
      authenticating users further reducing the possibility of automated
      attacks.

7.7.  Case Insensitive Comparison & International Languages

   When comparing unicode strings such as in query filters or testing
   for uniqueness of usernames and passwords, strings MUST be
   appropriately prepared before comparison.  See Section 5.

On Apr 29, 2015, at 1:31 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Thanks. I think we have a plan!

Phil

On Apr 29, 2015, at 13:27, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:

Hi Phil,

On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt <phi= l.hunt@yahoo.com> wrote:
Am I correct in assuming  authentication is specifically excluded per = the charter. The assumption was/is SCIM uses typical http authen/authz sche= mes and does not provide or mandate a method.

That said we have reservations about using 2617 mechanisms and prefer stron= ger options.

Good.  This needs to be stated explicitly because of e= xisting standards.  My concerns are because of this text in your draft= :

2.  Authen=
tication and Authorization

   Because SCIM builds on the HTTP protocol, it does not itself define a
   scheme for authentication and authorization.  SCIM depends on
   standard HTTP authentication schemes.  Implementers SHOULD support
   existing authentication/authorization schemes.  In particular, OAuth2&nb=
sp;
   (see [RFC6749], [RFC6750]) is RECOMMENDED. 

Because it says OAuth2 is recommended for authentication an= d you are using this for bearer tokens, I am going to assume that the 3 opt= ions established for that purpose are being used, with the default being HT= TP Basic.  In my original discuss, I provided a link to the updated version of Basic (in the RFC editor queue= ).  When you recommend against it's use, you should refer to the secur= ity considerations section of that draft, it updates 2617 for Basic.  = Digest is in a separate update.

Since bearer tokens are used, I have to assume all of the s= ecurity issues with those as well.  First is the IETF registered and s= upported authentication methods, then the lack of security in the token its= elf.  Holder-of-key tokens require proof of possession (there is some crypto to do this).  The only thing you = can do to protect a bearer token is to use TLS and there needs to be a refe= rence to the security section I mentioned in my original post so users know= where to look to understand issues with bearer tokens.

I hope that helps.

Is this is the approach we are looking for?
Yes, being explicit would be very helpful as I'll assume de= faults and limitations like registered/supported methods. 

Thank you,
Kathleen


Thanks,

Phil

> On Apr 29, 2015, at 13:08, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com<= /a>> wrote:
>
> Phil and I chatted a bit and he is working up some text with specific<= br class=3D""> > authentication options.  I said I would look up some more referen= ces and am
> providing them inline here.
>
> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty <
> kathlee= n.moriarty.ietf@gmail.com> wrote:
>
>> Hi Phil,
>>
>> Just a quick response for now and more later.  I'll find the = specific
>> references and registry for authentication used with OAuth.  = I'm the AD and
>> have been reading their drafts carefully.
>>
>> Thanks,
>> Kathleen
>>
>> Sent from my iPhone
>>
>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt <phil.hunt@yahoo.com> wrote:
>>>
>>> Kathleen,
>>>
>>> Thanks for your comments. My comments in line=85
>>>
>>> General comment.  At the end of the day, SCIM is just an = HTTP protocol
>> (an application) and as such can use any of the normal HTTP mechan= isms. In
>> OAuth terms it is just a resource server.  I wonder what we c= an point to as
>> a general best practice for authentication and authorization.
>
> Yes, the issue I hit was that the text of this draft said that OAuth i= s the
> authentication protocol, when it's only an authorization protocol.&nbs= p; As
> such, a reader might jump to a conclusion that HTTP Basic is the way t= o go
> since it's the first method (and default) for OAuth in the OAuth 2.0 > framework.  Recent drafts that mention the same registry where th= e
> supported authentication protocols from the client to the AS have not<= br class=3D""> > updated that short list.  If you could rewrite the text to specif= y
> recommended authentication types, that would be good.
>
> See section 2.3 of https://tools.ietf.org/html/rfc6749
> and the 3 methods defined are stated again in the dyn registry draft(<= br class=3D""> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically > saying to authenticate to use a token, these methods are available: >
> token_endpoint_auth_method
>      String indicator of the requested authentication m= ethod for the
>      token endpoint.  Values defined by this speci= fication are:
>
>      *  "none": The client is a public c= lient as defined in OAuth 2.0
>         and does not have a client secret. >      *  "client_secret_post": The client= uses the HTTP POST parameters
>         defined in OAuth 2.0 section 2.3.1. >      *  "client_secret_basic": the clien= t uses HTTP Basic defined in
>         OAuth 2.0 section 2.3.1
>
>      Additional values can be defined via the IANA OAut= h Token Endpoint
>      Authentication Methods Registry established in Sec= tion 4.2.
>      Absolute URIs can also be used as values for this = parameter
>      without being registered.  If unspecified or = omitted, the default
>      is "client_secret_basic", denoting HTTP = Basic Authentication
>      Scheme as specified in Section 2.3.1 of OAuth 2.0.=
>
>
>
>
>>
>>> The use of OAuth was in part, a reflection of the growing popu= larity of
>> OAuth at the time of writing, and I believe a conscious attempt by= the
>> original authors to discourage the use of simple password authenti= cation
>> such as RFC2617=92s basic authentication.  For this reason we= did not want to
>> use Basic in the examples.
>
> It's specified as the default in OAuth 2.0 when using a token.  s= ee above.
>
> Phil and I already chatted and he's planning to specify recommendation= s
> that are more secure since SCIM can use other authentication methods.<= br class=3D""> >
> Please take a look at the reference I gave that spells out the securit= y
> considerations for bearer tokens.  They are not secure in of them= selves and
> require the use of TLS 1.2 to prevent attacks.  This needs to be = clearly
> stated as well with a reference included to the draft I provided that<= br class=3D""> > already details the risks with bearer tokens.
>
> Thanks,
> Kathleen
>
>
>>>
>>> Phil
>>>
>>> phil.hunt@ya= hoo.com
>>>
>>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <
>> Kat= hleen.Moriarty.ietf@gmail.com> wrote:
>>>>
>>>> Kathleen Moriarty has entered the following ballot positio= n for
>>>> draft-ietf-scim-api-17: Discuss
>>>>
>>>> When responding, please keep the subject line intact and r= eply to all
>>>> email addresses included in the To and CC lines. (Feel fre= e to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positi= ons.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be fo= und here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------= ------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------= ------------
>>>>
>>>> Thanks for your work on this draft.  I have a few ite= ms I'd like to
>>>> discuss and have provided suggestions to help the discussi= on.  I think
>>>> this should be fairly easy to get through.
>>>>
>>>> 1. OAuth is used for authorization and is limited to insec= ure methods of
>>>> authentication via HTTP supported methods and of those, OA= uth only has a
>>>> few registered.  HTTP Basic authentication is the def= ault, which is
>>>> horrible.  Later in this draft, SCIM encourages the u= se of asymmetric
>>>> crypto.  Can this be the preferred option and there b= e more details
>>>> listed on how to do with (references)?
>>>>
>>>> What is specified now is really an authorization protocol,= so you'll
>> need
>>>> to say if HTTP Basic is what's used for authentication wit= h OAuth
>>>> (default) or something else and then the security consider= ations for
>>>> OAuth bearer tokens and HHTP Basic.  Here are some li= nks to help:
>>>>
>>>> A reference to security considerations from this draft wil= l be needed:
>>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
>>>> Reference to the HTTP Basic draft will be needed to show t= he security
>>>> issues with this option:
>>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/<= br class=3D""> >>>>
>>>> OAuth can't use something like HOBA in RFC7486, which was = designed to
>>>> avoid the need for passwords when using HTTP Authenticatio= n.  Can SCIM
>>>> work directly with other HTTP Auth methods like HOBA? The = OAuth folks
>> are
>>>> thinking about this problem, but aren't there yet (non-pas= sword auth
>>>> methods to then use Oauth authorization tokens).
>>> [PH]
>>>
>>> The text suggests OAuth is recommended but not required reflec= ts what
>> current implementers have been doing. I am opening to reducing thi= s from
>> =93RECOMMENDED=94 and allowing deployers to use other equally secu= re mechanisms
>> and to point out that the text based examples use bearer tokens to=
>> illustrate the use of the authorization header and are not normati= ve.
>>>
>>> Regarding OAuth.  I don=92t see why OAuth can=92t use HOB= A.  OAuth doesn=92t
>> care how authentication happens only that the parties are authenti= cated
>> before authorizing.  OAuth and for that matter OIDC both depe= nd on using
>> traditional (and emerging) authentication schemes to authenticate = users.
>>>
>>> That said, I see no reason why SCIM could not work directly wi= th HOBA.
>> SCIM does not care, it merely assumes clients are authenticated (p= resumably
>> via session cookie or the authorization header).
>>>
>>> Regarding asymmetric crypto, I believe you are referring to se= ction 7.5=3D



--

Best regards,
Kathleen
__________________________________________= _____
scim mailing list
scim@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/scim
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim

 --_000_D16FF3DD17F3patrickradtkejivesoftwarecom_-- From nobody Thu May 7 08:32:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1A01A92F4; Thu, 7 May 2015 08:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1iDS9tGvUVa; Thu, 7 May 2015 08:32:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F3D1A92F5; Thu, 7 May 2015 08:32:29 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t47FWROx030438 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 May 2015 15:32:27 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t47FWRkR009817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2015 15:32:27 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t47FWQK7020637; Thu, 7 May 2015 15:32:26 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 May 2015 08:32:25 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Thu, 7 May 2015 08:32:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90A04069-60FF-4E91-9A91-55025A13255B@oracle.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> To: Patrick Radtke X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , Kathleen Moriarty , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:32:33 -0000 Patrick & Kathleen, Would a reference to the security considerations for RFC6265 =93HTTP = State Management Mechanism" cover this adequately? =20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 6, 2015, at 4:59 PM, Patrick Radtke = wrote: >=20 > Everything looked good to me except the Cookie authentication for = JavaScript clients - there is no guidance for CSRF protection. > Two Cookie/CSRF attack scenarios that come to mind (based on this doc) > = http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/referenc= e/htmlsingle/#csrf-protection-and-json >=20 >=20 > 1. Attacker site does cross site POST to /Users endpoint. The = Service provider does not check the Content-Type header, only looks at = the Cookie and is fooled into thinking it is a legitimate request. > 2. Attacker site does cross site POST using a URI suffix to = /User.scim or /Users.json. The Service Provider=92s REST framework = automatically sets a Content-Type header based on URI suffix, and the = actual implementation is fooled into thinking Content-Type header was = set by the client. >=20 > Maybe some guidance along the lines of =93To prevent CSRF attacks the = service provider MUST check the Content-Type of the request and MUST NOT = allow POSTs to uri suffixed endpoints" >=20 > -Patrick >=20 > From: Phil Hunt > > Date: Wednesday, May 6, 2015 at 4:02 PM > To: Kathleen Moriarty = = > > Cc: = "draft-ietf-scim-api.ad@ietf.org" = >,= "scim@ietf.org" = >, = "draft-ietf-scim-api.shepherd@ietf.org" = >, The IESG >, = "draft-ietf-scim-api@ietf.org" = >, = "scim-chairs@ietf.org" = > > Subject: Re: [scim] Kathleen Moriarty's Discuss on = draft-ietf-scim-api-17: (with DISCUSS and COMMENT) >=20 > Kathleen, >=20 > Apologies for pasting a lot of text in here, but after considering = comments from you and Brian, I wanted to re-think a number of things and = try and boil things down a bit (I probably can do some more). I=92ve = essentially re-written the authentication and security sections with = care not to change consensus, but to address the issues you mentioned. = I hope we are close. Please take a look at the pasted sections below. = If you are in agreement, I can post them in the next document update. >=20 > Thanks for your help! >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > ------------------------------ > Section 2 Proposed: >=20 > 2. Authentication and Authorization >=20 > SCIM Protocol is based upon HTTP and does not itself define a SCIM > specific scheme for authentication and authorization. SCIM depends > on the use of TLS and/or standard HTTP authentication and > authorization schemes as per [RFC7235]. For example, the following > methodologies could be used among others: >=20 > TLS Client Authentication > The SCIM service provider MAY request TLS client authentication > (also known as mutual authentication). See Section 7.3 = [RFC5246]. >=20 > HTTP Origin-Bound Authentication (HOBA) is a variation on TLS > client authentication and uses a digital-signature-based design > for an HTTP authentication method (see [RFC7486]). The design = can > also be used in JavaScript-based authentication embedded in HTML. > HOBA is an alternative to HTTP authentication schemes that = require > passwords and therefore avoids all problems related to passwords, > such as leakage of server-side password databases. >=20 > Bearer Tokens > Bearer tokens [RFC6750] MAY be used when combined with TLS and a > token framework such as OAuth2 [RFC6749]. See Section 7.3 for > security considerations regarding the use of bearer tokens in > SCIM. While bearer tokens most often represent an authorization, > it is assumed that the authorization was based upon a successful > authentication of the SCIM client. Accordingly the SCIM service > provider must have a method for validating, parsing, and or > introspecting the bearer token for the relevant authentication = and > authorization information. The method for this is assumed to be > defined by the token issuing system and is beyond the scope of > this specification. >=20 > POP Tokens > A proof-of-possession token demonstrates the presenter of the > token possesses a particular key and that the recipient can > cryptographically confirm proof-of-possession of the key by the > presenter. This property is sometimes also described as the > presenter being a holder-of-key. See OAuth > [I-D.ietf-oauth-pop-architecture] for an example of such a token > and its use. >=20 > Cookies > Javascript clients MAY assert HTTP cookies over TLS that contain > an authentication state that is understood by the SCIM service > provider (see [RFC6265]). An example of this is scenarios where > web-form authentication has taken place with the user and HTTP > cookies were set representing the authentication state. For the > purposes of SCIM, the security considerations in Section 7.3 > apply. >=20 > As per Section 4.1 of [RFC7235], a SCIM service provider SHALL > indicate supported HTTP authentication schemes via the "WWW- > Authenticate" header. >=20 > For all of the above methodologies, the SCIM service provider MUST = be > able to map the authenticated client to an access control policy in > order to determine the client's authorization to retrieve and update > SCIM resources. For example, while a browser session may have been > established via HTTP cookie or TLS client authentication, the unique > client MUST be mapped to a security subject (e.g., User). The > authorization model and the process by which this is done is beyond > the scope of this specification. >=20 > Because SCIM is a protocol for provisioning resources cross domains > (e.g., user accounts and access control information such as groups), > weaker authentication mechanisms based on static symmetric secrets > such as passwords SHOULD NOT be used. In particular, the > authentication schemes (e.g., Basic Authentication) described in > [RFC2617] SHOULD NOT be used. >=20 > When processing requests, the service provider SHOULD consider the > subject performing the request and whether the action is appropriate > given the subject and the resource affected by the request. The > subject performing the request is usually determined directly or > indirectly from the "Authorization" header present in the request. > For example, a subject MAY be permitted to retrieve and update their > own "User" resource, but will normally have restricted ability to > access resources associated with other Users. In other cases, the > SCIM service provider might only grant access to a subject's own > associated "User" resource (e.g., for the purpose of updating > personal contact attributes). >=20 > For illustrative purposes only, examples show an OAuth2 bearer token > value [RFC6750] in the authorization header; e.g., >=20 > GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 > Host: example.com > Authorization: Bearer h480djs93hd8 >=20 > This is not intended to imply that bearer tokens are preferred. > However, the use of bearer tokens in the specification does reflect > common implementation practice. >=20 >=20 > 2.1. Anonymous Requests >=20 > In some SCIM deployments it MAY be acceptable to permit > unauthenticated (anonymous) requests. For example, a user self- > registration request where the service provider chooses to accept a > SCIM Create request (see Section 3.3) from an anonymous client. See > Section 7.5, for security considerations regarding anonymous > requests. >=20 >=20 > ------------------------------ > Section 7 Proposed (note the example in 7.4 needs correction still): >=20 >=20 > 7. Security Considerations >=20 > 7.1. HTTP Considerations >=20 > SCIM Protocol layers on top of Hypertext Transfer Protocol and thus > subject to the security considerations of HTTP Section 9 [RFC7230] > and its related specifications. >=20 > As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT = generate > the userinfo (i.e., username and password) component (and its "@" > delimiter) when an "http" URI reference is generated with a message > as they are now disallowed in HTTP. >=20 > 7.2. TLS Support Considerations >=20 > SCIM resources (e.g., Users and Groups) can contain sensitive > information including passwords. Therefore, SCIM clients and = service > providers MUST require the use of a transport-layer security > mechanism when communicating with SCIM service providers. The SCIM > service provider MUST support TLS 1.2 [RFC5246] and MAY support > additional transport-layer mechanisms meeting its security > requirements. When using TLS, the client MUST perform a TLS/SSL > server certificate check, per [RFC6125]. Implementation security > considerations for TLS can be found in "Recommendations for Secure > Use of TLS and DTLS" [RFC7525]. >=20 > 7.3. Bearer and Cookie Considerations >=20 > Since the posession of a bearer token or cookie MAY authorize the > holder to potentially read, modify, or delete resources, tokens and > cookies MUST contain sufficient entropy to prevent a random guessing > attack, such as described in Section 5.2 of [RFC6750] and > Section 5.1.4.2.2 of [RFC6819]. >=20 > As with all SCIM communications, Bearer tokens and HTTP cookies MUST > be exchanged using TLS. >=20 > Bearer tokens MUST have a limited lifetime that can be determined > directly or indirectly (e.g., by checking with a validation service) > by the service provider. By expiring tokens, clients are forced to > obtain a new token (which usually involves re-authentication) for > continued authorized access. For example, in OAuth2, a client MAY > use OAuth token refresh to obtain a new bearer token after > authenticating to an authorization server. See Section 6 of > [RFC6749]. >=20 > As with Bearer tokens, an HTTP cookie SHOULD last no longer than the > lifetime of a browser session. An expiry time should be set that > limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. >=20 > 7.4. Privacy Considerations >=20 > 7.4.1. Personal Information >=20 > The SCIM Core Schema specifications defines attributes that MAY > contain personally identifying information as well as other = sensitive > personal data. The privacy considerations in the Security > Considerations Section of [I-D.ietf-scim-core-schema] MUST be > considered. >=20 > 7.4.2. Disclosure of Sensitive Information in URIs >=20 > As mentioned in Section 9.4 [RFC7231], SCIM clients requesting > information using query filters using HTTP GET SHOULD give > consideration to the information content of the filters and whether > their exposure in a URI would represent a breach of security or > confidentiality through leakage in a web browsers or server logs. > This is particularly true for information that is legally considered > "personally identifiable information" or is otherwise restricted by > privacy laws. In these situations to ensure maximum security and > confidentiality, clients SHOULD query using HTTP POST (see > Section 3.4.3 ). >=20 > Servers that receive HTTP GET requests using filters that contain > restricted or confidential information SHOULD respond with HTTP > status 403 indicating the operation is FORBIDDEN. A detailed error, > "confidential_restricted" may be returned indicating the request = must > be submitted using POST. A non-normative example: >=20 >=20 > HTTP/1.1 403 FORBIDDEN >=20 > { > "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], > "Errors":[ > { > "description": > "Query filter involving 'name' is restricted or = confidential", > "error":"confidential_restricted" > } > ] > } >=20 > 7.5. Anonymous Requests >=20 > If a SCIM service provider accepts anonymous requests such as SCIM > resource creation requests (via HTTP POST), appropriate security > measures should be put in place to prevent or limit exposure to > attacks. The following counter-measures MAY be used: >=20 > o Try to authenticate web UI components that forumulate the SCIM > creation request. While the end-user MAY be anonymous, the web > user interface component often has its own way to authenticate to > the SCIM service provider (e.g., has an OAuth client credential > [RFC6749]) and the web user interface component may implement its > own measures (e.g., such as CAPTCHA) to ensure a ligitimate > request is being made. >=20 > o Limit the number of requests any particular client MAY make in a > period of time. >=20 > o For User resources, default newly created resource with an > "active" setting of "false" and use a secondary confirmation > process (e.g., email confirmation) to ensure the resource created > is real. >=20 > 7.6. Secure Storage and Handling of Sensitive Data >=20 > An attacker may obtain valid username/password combinations from the > SCIM service provider's underlying database by gaining access to the > database and/or launching injection attacks. This could lead to > unintended disclosure of username/password combinations. The impact > may extend beyond the domain of the SCIM service provider if the = data > was provisioned from other domains. >=20 > Administrators should undertake industry best practices to protect > the storage of credentials and in particular SHOULD follow > recommendations outlines in Section 5.1.4.1 [RFC6819]. These > recommendations include but are not limited to: >=20 > o Provide injection attack counter measures (e.g., by validating = all > inputs and parameters), >=20 > o No cleartext storage of credentials, >=20 > o Store credentials using an encrypted protection mechanism, and >=20 > o Avoid passwords and consider use of asymmetric cryptography based > credentials. >=20 > As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take > counter measures to prevent online attacks on secrets such as: >=20 > o Utilize secure password policy in order to increase user password > entrophy to hinder online attacks and password guessing, >=20 > o Mitigate attacks on passwords by locking respective accounts have > a number of failed attempts, >=20 > o Use "tar pit" techniques by temporarily locking a respective > account and delaying responses for a certain duration. The > duration may increase with the number of failed attempts, and >=20 > o Use authentication system that use CAPTCHA's and other factors = for > authenticating users further reducing the possibility of = automated > attacks. >=20 > 7.7. Case Insensitive Comparison & International Languages >=20 > When comparing unicode strings such as in query filters or testing > for uniqueness of usernames and passwords, strings MUST be > appropriately prepared before comparison. See Section 5. >=20 >=20 > On Apr 29, 2015, at 1:31 PM, Phil Hunt = > wrote: >=20 > Thanks. I think we have a plan! >=20 > Phil >=20 > On Apr 29, 2015, at 13:27, Kathleen Moriarty = = > wrote: >=20 > Hi Phil, >=20 > On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt = > wrote: > Am I correct in assuming authentication is specifically excluded per = the charter. The assumption was/is SCIM uses typical http authen/authz = schemes and does not provide or mandate a method. >=20 > That said we have reservations about using 2617 mechanisms and prefer = stronger options. >=20 > Good. This needs to be stated explicitly because of existing = standards. My concerns are because of this text in your draft: >=20 >=20 > 2. Authentication and Authorization >=20 > Because SCIM builds on the HTTP protocol, it does not itself define = a > scheme for authentication and authorization. SCIM depends on > standard HTTP authentication schemes. Implementers SHOULD support > existing authentication/authorization schemes. In particular, = OAuth2 >=20 > (see [RFC6749], [RFC6750]) is RECOMMENDED. >=20 > Because it says OAuth2 is recommended for authentication and you are = using this for bearer tokens, I am going to assume that the 3 options = established for that purpose are being used, with the default being HTTP = Basic. In my original discuss, I provided a link to the updated version = of Basic (in the RFC editor queue). When you recommend against it's = use, you should refer to the security considerations section of that = draft, it updates 2617 for Basic. Digest is in a separate update. >=20 > Since bearer tokens are used, I have to assume all of the security = issues with those as well. First is the IETF registered and supported = authentication methods, then the lack of security in the token itself. = Holder-of-key tokens require proof of possession (there is some crypto = to do this). The only thing you can do to protect a bearer token is to = use TLS and there needs to be a reference to the security section I = mentioned in my original post so users know where to look to understand = issues with bearer tokens. >=20 > I hope that helps. >=20 > Is this is the approach we are looking for? > Yes, being explicit would be very helpful as I'll assume defaults and = limitations like registered/supported methods. >=20 > Thank you, > Kathleen >=20 >=20 > Thanks, >=20 > Phil >=20 >> On Apr 29, 2015, at 13:08, Kathleen Moriarty = = > wrote: >>=20 >> Phil and I chatted a bit and he is working up some text with specific >> authentication options. I said I would look up some more references = and am >> providing them inline here. >>=20 >> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < >> = kathleen.moriarty.ietf@gmail.com>= wrote: >>=20 >>> Hi Phil, >>>=20 >>> Just a quick response for now and more later. I'll find the = specific >>> references and registry for authentication used with OAuth. I'm the = AD and >>> have been reading their drafts carefully. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt = > wrote: >>>>=20 >>>> Kathleen, >>>>=20 >>>> Thanks for your comments. My comments in line=85 >>>>=20 >>>> General comment. At the end of the day, SCIM is just an HTTP = protocol >>> (an application) and as such can use any of the normal HTTP = mechanisms. In >>> OAuth terms it is just a resource server. I wonder what we can = point to as >>> a general best practice for authentication and authorization. >>=20 >> Yes, the issue I hit was that the text of this draft said that OAuth = is the >> authentication protocol, when it's only an authorization protocol. = As >> such, a reader might jump to a conclusion that HTTP Basic is the way = to go >> since it's the first method (and default) for OAuth in the OAuth 2.0 >> framework. Recent drafts that mention the same registry where the >> supported authentication protocols from the client to the AS have not >> updated that short list. If you could rewrite the text to specify >> recommended authentication types, that would be good. >>=20 >> See section 2.3 of https://tools.ietf.org/html/rfc6749 >> and the 3 methods defined are stated again in the dyn registry draft( >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically >> saying to authenticate to use a token, these methods are available: >>=20 >> token_endpoint_auth_method >> String indicator of the requested authentication method for the >> token endpoint. Values defined by this specification are: >>=20 >> * "none": The client is a public client as defined in OAuth 2.0 >> and does not have a client secret. >> * "client_secret_post": The client uses the HTTP POST parameters >> defined in OAuth 2.0 section 2.3.1. >> * "client_secret_basic": the client uses HTTP Basic defined in >> OAuth 2.0 section 2.3.1 >>=20 >> Additional values can be defined via the IANA OAuth Token = Endpoint >> Authentication Methods Registry established in Section 4.2. >> Absolute URIs can also be used as values for this parameter >> without being registered. If unspecified or omitted, the default >> is "client_secret_basic", denoting HTTP Basic Authentication >> Scheme as specified in Section 2.3.1 of OAuth 2.0. >>=20 >>=20 >>=20 >>=20 >>>=20 >>>> The use of OAuth was in part, a reflection of the growing = popularity of >>> OAuth at the time of writing, and I believe a conscious attempt by = the >>> original authors to discourage the use of simple password = authentication >>> such as RFC2617=92s basic authentication. For this reason we did = not want to >>> use Basic in the examples. >>=20 >> It's specified as the default in OAuth 2.0 when using a token. see = above From nobody Thu May 7 08:39:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759481AC41A; Thu, 7 May 2015 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mjgwqEztfCh; Thu, 7 May 2015 08:39:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5208A1AC412; Thu, 7 May 2015 08:39:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507153923.2232.28046.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 08:39:23 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-08.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:39:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Definitions, Overview, Concepts and Requirements Authors : Kepeng LI Phil Hunt Bhumip Khasnabish Anthony Nadalin Zachary Zeltsan Filename : draft-ietf-scim-use-cases-08.txt Pages : 18 Date : 2015-05-07 Abstract: This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models and flows, and includes user scenarios, use cases, and requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-use-cases-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 7 08:42:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA161AC3A6 for ; Thu, 7 May 2015 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph39D4KeM-3G for ; Thu, 7 May 2015 08:42:22 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1D1A8941 for ; Thu, 7 May 2015 08:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1431013341; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Vkd+Pdp0pTjWLmWM2m4PW0iXf1z0BmWnjg/RvX1hd3E=; b=s83ANNrB2Z0LVpsLKRios4olgLGX+HsxMDLrUNmfvC+AmaxLt09yGtzDQfkudaPLdLGIlRleVgQM+OJV0/9z4UJRd0PRovtTxqQbjkeGCJUmbFUP3Icfe9rmu7KPeYvxSGaHBSDiBZdrUnFj63qh8p8xYLuIblV6Y3uptIYArwM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02004; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.22.38.171(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Thu, 07 May 2015 23:42:14 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 07 May 2015 23:42:09 +0800 From: "Kepeng Li" To: Kathleen Moriarty Message-ID: Thread-Topic: [scim] Status of use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3513886934_6968726" Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:42:24 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3513886934_6968726 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hi Kathleen, Please find the updated draft with your suggested texts: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-08 Thanks. Kind Regards Kepeng=20 =B7=A2=BC=FE=C8=CB: Kathleen Moriarty =C8=D5=C6=DA: Wednesday, 6 May, 2015 5:20 pm =D6=C1: Li Kepeng =B3=AD=CB=CD: Barry Leiba , "scim@ietf.org" =D6=F7=CC=E2: Re: [scim] Status of use-cases Thank you for the updates to the draft. It would be good to also see a statement in the security considerations section that includes leaving out data elements or obscuring them to protect users privacy. Privacy concerns aren't limited to regulations and this would help to make that point. Perhaps something like the following, after the third paragraph: Additionally, privacy sensitive data elements may be omitted or obscured in SCIM transactions or stored records to protect these data elements for a user. For instance a role based identifier might be used in place of an individual's name. Best regards, Kathleen On Sat, May 2, 2015 at 12:43 PM, Kepeng Li wrote: > Hi Barry, >=20 > Thanks for your reminder. >=20 >> >There's still a DISCUSS on the use-cases doc. What is the status of > addressing that, as well as the non-blocking comments from IESG > Evaluation? >=20 > I just posted some resolutions to the review comments, and provided a new > version: > https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >=20 > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-07 >=20 >=20 > Hopefully we can close all the IESG comments. >=20 >=20 > Kind Regards > Kepeng >=20 > =D4=DA 1/5/15 6:39 pm=A3=AC "Barry Leiba" =D0=B4=C8=EB: >=20 >> >There's still a DISCUSS on the use-cases doc. What is the status of >> >addressing that, as well as the non-blocking comments from IESG >> >evaluation? >> > >> >Barry >> > >> >_______________________________________________ >> >scim mailing list >> >scim@ietf.org >> >https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --=20 Best regards, Kathleen --B_3513886934_6968726 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi Kathleen,

Please find the updated = draft with your suggested texts:


Thanks.
=
Kind Regards=
Kepeng 

=B7=A2=BC=FE=C8=CB: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m>
=C8=D5=C6=DA: Wednesday, 6 May, = 2015 5:20 pm
=D6=C1: Li Kepeng <kepeng.lkp@alibaba-inc.com><= br>=B3=AD=CB=CD: Barry Leiba <barryleiba@computer.org>, "scim@ietf.org" <scim= @ietf.org>
=D6=F7=CC=E2: Re: [scim]= Status of use-cases

Thank you for th= e updates to the draft.  It would be good to also see a statement in th= e security considerations section that includes leaving out data elements or= obscuring them to protect users privacy.  Privacy concerns aren't limi= ted to regulations and this would help to make that point.  Perhaps som= ething like the following, after the third paragraph:

Add= itionally, privacy sensitive data elements may be omitted or obscured in SCI= M transactions or stored records to protect these data elements for a user.&= nbsp; For instance a role based identifier might be used in place of an indi= vidual's name.

Best regards,
Kathleen



On Sat, May 2, 2015 at 12:43 PM, Kepeng Li &= lt;kepeng.lkp@al= ibaba-inc.com> wrote:
Hi Barry,
Thanks for your reminder.

>There's still a DISCUSS on the use-cases doc.  What is the status = of
addressing that, as well as the non-blocking comments from IESG
E= valuation?

I just posted some resolutions to the review comments, and provided a new version:
https://datatracker.ietf.org/doc/draft-ietf-scim-use-= cases/

Diff from previous version:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-scim-use-cases-07


Hopefully we can close all the IESG comments.


Kind Regards
Kepeng

=D4=DA 1/5/15 6:39 pm=A3=AC "Barry Leiba" <barryleiba@computer.org> =D0=B4=C8=EB:

>There's still a DISCUSS on the use-cases doc.  What is the status = of
>addressing that, as well as the non-blocking comments from IESG
>evaluation?
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>ht= tps://www.ietf.org/mailman/listinfo/scim


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

=

--

Best regards,
Kathleen
--B_3513886934_6968726-- From nobody Thu May 7 08:47:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CFA1AC3FB; Thu, 7 May 2015 08:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmCfLO1MGmlk; Thu, 7 May 2015 08:47:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 662EC1AC3D5; Thu, 7 May 2015 08:47:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507154730.1447.15860.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 08:47:30 -0700 Archived-At: Cc: scim@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-use-cases.shepherd@ietf.org, draft-ietf-scim-use-cases@ietf.org, draft-ietf-scim-use-cases.ad@ietf.org Subject: [scim] Kathleen Moriarty's No Objection on draft-ietf-scim-use-cases-08: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:47:31 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-scim-use-cases-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you very much for addressing each of my discusses and comments. The security and privacy consideration additions are much appreciated. From nobody Thu May 7 09:53:08 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B231A1BE7 for ; Thu, 7 May 2015 09:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4uZnSdP9b2R for ; Thu, 7 May 2015 09:53:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8031A0210 for ; Thu, 7 May 2015 09:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=604; q=dns/txt; s=iport; t=1431017586; x=1432227186; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=q193BP+01xozzs0n4gqZdV7+JwjEVq1ZO1RwC7vED10=; b=fPEFTtGLhSMUgdoAJJbuHg0KX169V8BkQu57M1zhtnPHP7mpDwbfYtgp fMpXLIrjbZjd+DeszjnM2hIX6L+6hUCXa93W4i55ZjgRue62y5KSPfB0t h490GNZNN+b6FFXW+SDF5bha1Ssoy5DCd24FeWkCgCmsqKgA8e5tGzCK+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBgD5l0tV/51dJa1cgwxUXgbEdII7CoYFAoE4TAEBAQEBAYELhCEBAQQBAQFrGwIBCEYnCyUCBAESiCwNxlIBAQEBAQEBAQEBAQEBAQEBAQEBFQSLOYUMhC0Fi1yGTIpYljkjg3ZvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="10043607" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 07 May 2015 16:53:06 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t47Gr6xG013216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 16:53:06 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.175]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 7 May 2015 11:53:05 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] Status of use-cases Thread-Index: AQHQg/sxx9NXYU06Kku3ndwvglzgmJ1woxOA Date: Thu, 7 May 2015 16:53:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.40.138] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <05B9D308580E4344B93E16E66AAC779E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:53:08 -0000 Barry, I believe the latest version of the use cases draft (draft-ietf-scim-use-cases-08.txt) and Kathleen=B9s acceptance of the changes to the security/privacy section address all comments received so far. Cheers, Morteza On 5/1/15, 3:39 AM, "Barry Leiba" wrote: >There's still a DISCUSS on the use-cases doc. What is the status of >addressing that, as well as the non-blocking comments from IESG >evaluation? > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 7 10:10:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5F1A039D for ; Thu, 7 May 2015 10:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9D_GLoUQ5b6 for ; Thu, 7 May 2015 10:10:30 -0700 (PDT) Received: from heisenberg.jivesoftware.com (heisenberg.jivesoftware.com [204.93.66.11]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0D1A1A04 for ; Thu, 7 May 2015 10:10:28 -0700 (PDT) X-ASG-Debug-ID: 1431017560-059a6d043d84c070001-bGWiwh Received: from mail.jiveland.com (phxcas01.jiveland.com [10.81.2.11]) by heisenberg.jivesoftware.com with ESMTP id z0KuKVFWXk1YHIxr; Thu, 07 May 2015 09:52:40 -0700 (PDT) X-Barracuda-Envelope-From: patrick.radtke@jivesoftware.com Received: from MBX01.jiveland.com ([fe80::9982:7054:baaa:ab73]) by PHXCAS01.jiveland.com ([10.81.2.11]) with mapi id 14.03.0158.001; Thu, 7 May 2015 09:52:40 -0700 From: Patrick Radtke To: Phil Hunt Thread-Topic: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-ASG-Orig-Subj: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) Thread-Index: AQHQghce/E9Dl2ugI0+i91Zwe2nKXZ1kPl18gACjUYD//5AgEoAAdlKAgAsqYYD//5q/gIABefGA//+hEwA= Date: Thu, 7 May 2015 16:52:38 +0000 Message-ID: References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> <90A04069-60FF-4E91-9A91-55025A13255B@oracle.com> In-Reply-To: <90A04069-60FF-4E91-9A91-55025A13255B@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.32.204] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3E3C6D520DAB32448B84C276828AA578@jivesoftware.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: phxcas01.jiveland.com[10.81.2.11] X-Barracuda-Start-Time: 1431017560 X-Barracuda-URL: https://spamfirewall3.jiveland.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at jivesoftware.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4994 1.0000 0.0000 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18701 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , Kathleen Moriarty , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 17:10:33 -0000 I didn=B9t catch that reference in my initial read through. I think that RFC covers all the downsides associated with cookies. -Patrick On 5/7/15, 8:32 AM, "Phil Hunt" wrote: >Patrick & Kathleen, > >Would a reference to the security considerations for RFC6265 =B3HTTP State >Management Mechanism" cover this adequately? > >Phil > >@independentid >www.independentid.com >phil.hunt@oracle.com > >> On May 6, 2015, at 4:59 PM, Patrick Radtke >> wrote: >>=20 >> Everything looked good to me except the Cookie authentication for >>JavaScript clients - there is no guidance for CSRF protection. >> Two Cookie/CSRF attack scenarios that come to mind (based on this doc) >>=20 >>http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/referen >>ce/htmlsingle/#csrf-protection-and-json >>=20 >>=20 >> 1. Attacker site does cross site POST to /Users endpoint. The >>Service provider does not check the Content-Type header, only looks at >>the Cookie and is fooled into thinking it is a legitimate request. >> 2. Attacker site does cross site POST using a URI suffix to >>/User.scim or /Users.json. The Service Provider=B9s REST framework >>automatically sets a Content-Type header based on URI suffix, and the >>actual implementation is fooled into thinking Content-Type header was >>set by the client. >>=20 >> Maybe some guidance along the lines of =B3To prevent CSRF attacks the >>service provider MUST check the Content-Type of the request and MUST NOT >>allow POSTs to uri suffixed endpoints" >>=20 >> -Patrick >>=20 >> From: Phil Hunt > >> Date: Wednesday, May 6, 2015 at 4:02 PM >> To: Kathleen Moriarty >>>>> >> Cc:=20 >>"draft-ietf-scim-api.ad@ietf.org" >>=20 >>> >>, "scim@ietf.org" >>>, >>"draft-ietf-scim-api.shepherd@ietf.org>d@ietf.org>"=20 >>>d@ietf.org>>, The IESG >, >>"draft-ietf-scim-api@ietf.org" >>>, >>"scim-chairs@ietf.org" >>> >> Subject: Re: [scim] Kathleen Moriarty's Discuss on >>draft-ietf-scim-api-17: (with DISCUSS and COMMENT) >>=20 >> Kathleen, >>=20 >> Apologies for pasting a lot of text in here, but after considering >>comments from you and Brian, I wanted to re-think a number of things and >>try and boil things down a bit (I probably can do some more). I=B9ve >>essentially re-written the authentication and security sections with >>care not to change consensus, but to address the issues you mentioned. >>I hope we are close. Please take a look at the pasted sections below. >>If you are in agreement, I can post them in the next document update. >>=20 >> Thanks for your help! >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> ------------------------------ >> Section 2 Proposed: >>=20 >> 2. Authentication and Authorization >>=20 >> SCIM Protocol is based upon HTTP and does not itself define a SCIM >> specific scheme for authentication and authorization. SCIM depends >> on the use of TLS and/or standard HTTP authentication and >> authorization schemes as per [RFC7235]. For example, the following >> methodologies could be used among others: >>=20 >> TLS Client Authentication >> The SCIM service provider MAY request TLS client authentication >> (also known as mutual authentication). See Section 7.3 [RFC5246]. >>=20 >> HTTP Origin-Bound Authentication (HOBA) is a variation on TLS >> client authentication and uses a digital-signature-based design >> for an HTTP authentication method (see [RFC7486]). The design can >> also be used in JavaScript-based authentication embedded in HTML. >> HOBA is an alternative to HTTP authentication schemes that require >> passwords and therefore avoids all problems related to passwords, >> such as leakage of server-side password databases. >>=20 >> Bearer Tokens >> Bearer tokens [RFC6750] MAY be used when combined with TLS and a >> token framework such as OAuth2 [RFC6749]. See Section 7.3 for >> security considerations regarding the use of bearer tokens in >> SCIM. While bearer tokens most often represent an authorization, >> it is assumed that the authorization was based upon a successful >> authentication of the SCIM client. Accordingly the SCIM service >> provider must have a method for validating, parsing, and or >> introspecting the bearer token for the relevant authentication and >> authorization information. The method for this is assumed to be >> defined by the token issuing system and is beyond the scope of >> this specification. >>=20 >> POP Tokens >> A proof-of-possession token demonstrates the presenter of the >> token possesses a particular key and that the recipient can >> cryptographically confirm proof-of-possession of the key by the >> presenter. This property is sometimes also described as the >> presenter being a holder-of-key. See OAuth >> [I-D.ietf-oauth-pop-architecture] for an example of such a token >> and its use. >>=20 >> Cookies >> Javascript clients MAY assert HTTP cookies over TLS that contain >> an authentication state that is understood by the SCIM service >> provider (see [RFC6265]). An example of this is scenarios where >> web-form authentication has taken place with the user and HTTP >> cookies were set representing the authentication state. For the >> purposes of SCIM, the security considerations in Section 7.3 >> apply. >>=20 >> As per Section 4.1 of [RFC7235], a SCIM service provider SHALL >> indicate supported HTTP authentication schemes via the "WWW- >> Authenticate" header. >>=20 >> For all of the above methodologies, the SCIM service provider MUST be >> able to map the authenticated client to an access control policy in >> order to determine the client's authorization to retrieve and update >> SCIM resources. For example, while a browser session may have been >> established via HTTP cookie or TLS client authentication, the unique >> client MUST be mapped to a security subject (e.g., User). The >> authorization model and the process by which this is done is beyond >> the scope of this specification. >>=20 >> Because SCIM is a protocol for provisioning resources cross domains >> (e.g., user accounts and access control information such as groups), >> weaker authentication mechanisms based on static symmetric secrets >> such as passwords SHOULD NOT be used. In particular, the >> authentication schemes (e.g., Basic Authentication) described in >> [RFC2617] SHOULD NOT be used. >>=20 >> When processing requests, the service provider SHOULD consider the >> subject performing the request and whether the action is appropriate >> given the subject and the resource affected by the request. The >> subject performing the request is usually determined directly or >> indirectly from the "Authorization" header present in the request. >> For example, a subject MAY be permitted to retrieve and update their >> own "User" resource, but will normally have restricted ability to >> access resources associated with other Users. In other cases, the >> SCIM service provider might only grant access to a subject's own >> associated "User" resource (e.g., for the purpose of updating >> personal contact attributes). >>=20 >> For illustrative purposes only, examples show an OAuth2 bearer token >> value [RFC6750] in the authorization header; e.g., >>=20 >> GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 >> Host: example.com >> Authorization: Bearer h480djs93hd8 >>=20 >> This is not intended to imply that bearer tokens are preferred. >> However, the use of bearer tokens in the specification does reflect >> common implementation practice. >>=20 >>=20 >> 2.1. Anonymous Requests >>=20 >> In some SCIM deployments it MAY be acceptable to permit >> unauthenticated (anonymous) requests. For example, a user self- >> registration request where the service provider chooses to accept a >> SCIM Create request (see Section 3.3) from an anonymous client. See >> Section 7.5, for security considerations regarding anonymous >> requests. >>=20 >>=20 >> ------------------------------ >> Section 7 Proposed (note the example in 7.4 needs correction still): >>=20 >>=20 >> 7. Security Considerations >>=20 >> 7.1. HTTP Considerations >>=20 >> SCIM Protocol layers on top of Hypertext Transfer Protocol and thus >> subject to the security considerations of HTTP Section 9 [RFC7230] >> and its related specifications. >>=20 >> As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate >> the userinfo (i.e., username and password) component (and its "@" >> delimiter) when an "http" URI reference is generated with a message >> as they are now disallowed in HTTP. >>=20 >> 7.2. TLS Support Considerations >>=20 >> SCIM resources (e.g., Users and Groups) can contain sensitive >> information including passwords. Therefore, SCIM clients and service >> providers MUST require the use of a transport-layer security >> mechanism when communicating with SCIM service providers. The SCIM >> service provider MUST support TLS 1.2 [RFC5246] and MAY support >> additional transport-layer mechanisms meeting its security >> requirements. When using TLS, the client MUST perform a TLS/SSL >> server certificate check, per [RFC6125]. Implementation security >> considerations for TLS can be found in "Recommendations for Secure >> Use of TLS and DTLS" [RFC7525]. >>=20 >> 7.3. Bearer and Cookie Considerations >>=20 >> Since the posession of a bearer token or cookie MAY authorize the >> holder to potentially read, modify, or delete resources, tokens and >> cookies MUST contain sufficient entropy to prevent a random guessing >> attack, such as described in Section 5.2 of [RFC6750] and >> Section 5.1.4.2.2 of [RFC6819]. >>=20 >> As with all SCIM communications, Bearer tokens and HTTP cookies MUST >> be exchanged using TLS. >>=20 >> Bearer tokens MUST have a limited lifetime that can be determined >> directly or indirectly (e.g., by checking with a validation service) >> by the service provider. By expiring tokens, clients are forced to >> obtain a new token (which usually involves re-authentication) for >> continued authorized access. For example, in OAuth2, a client MAY >> use OAuth token refresh to obtain a new bearer token after >> authenticating to an authorization server. See Section 6 of >> [RFC6749]. >>=20 >> As with Bearer tokens, an HTTP cookie SHOULD last no longer than the >> lifetime of a browser session. An expiry time should be set that >> limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. >>=20 >> 7.4. Privacy Considerations >>=20 >> 7.4.1. Personal Information >>=20 >> The SCIM Core Schema specifications defines attributes that MAY >> contain personally identifying information as well as other sensitive >> personal data. The privacy considerations in the Security >> Considerations Section of [I-D.ietf-scim-core-schema] MUST be >> considered. >>=20 >> 7.4.2. Disclosure of Sensitive Information in URIs >>=20 >> As mentioned in Section 9.4 [RFC7231], SCIM clients requesting >> information using query filters using HTTP GET SHOULD give >> consideration to the information content of the filters and whether >> their exposure in a URI would represent a breach of security or >> confidentiality through leakage in a web browsers or server logs. >> This is particularly true for information that is legally considered >> "personally identifiable information" or is otherwise restricted by >> privacy laws. In these situations to ensure maximum security and >> confidentiality, clients SHOULD query using HTTP POST (see >> Section 3.4.3 ). >>=20 >> Servers that receive HTTP GET requests using filters that contain >> restricted or confidential information SHOULD respond with HTTP >> status 403 indicating the operation is FORBIDDEN. A detailed error, >> "confidential_restricted" may be returned indicating the request must >> be submitted using POST. A non-normative example: >>=20 >>=20 >> HTTP/1.1 403 FORBIDDEN >>=20 >> { >> "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], >> "Errors":[ >> { >> "description": >> "Query filter involving 'name' is restricted or confidential", >> "error":"confidential_restricted" >> } >> ] >> } >>=20 >> 7.5. Anonymous Requests >>=20 >> If a SCIM service provider accepts anonymous requests such as SCIM >> resource creation requests (via HTTP POST), appropriate security >> measures should be put in place to prevent or limit exposure to >> attacks. The following counter-measures MAY be used: >>=20 >> o Try to authenticate web UI components that forumulate the SCIM >> creation request. While the end-user MAY be anonymous, the web >> user interface component often has its own way to authenticate to >> the SCIM service provider (e.g., has an OAuth client credential >> [RFC6749]) and the web user interface component may implement its >> own measures (e.g., such as CAPTCHA) to ensure a ligitimate >> request is being made. >>=20 >> o Limit the number of requests any particular client MAY make in a >> period of time. >>=20 >> o For User resources, default newly created resource with an >> "active" setting of "false" and use a secondary confirmation >> process (e.g., email confirmation) to ensure the resource created >> is real. >>=20 >> 7.6. Secure Storage and Handling of Sensitive Data >>=20 >> An attacker may obtain valid username/password combinations from the >> SCIM service provider's underlying database by gaining access to the >> database and/or launching injection attacks. This could lead to >> unintended disclosure of username/password combinations. The impact >> may extend beyond the domain of the SCIM service provider if the data >> was provisioned from other domains. >>=20 >> Administrators should undertake industry best practices to protect >> the storage of credentials and in particular SHOULD follow >> recommendations outlines in Section 5.1.4.1 [RFC6819]. These >> recommendations include but are not limited to: >>=20 >> o Provide injection attack counter measures (e.g., by validating all >> inputs and parameters), >>=20 >> o No cleartext storage of credentials, >>=20 >> o Store credentials using an encrypted protection mechanism, and >>=20 >> o Avoid passwords and consider use of asymmetric cryptography based >> credentials. >>=20 >> As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take >> counter measures to prevent online attacks on secrets such as: >>=20 >> o Utilize secure password policy in order to increase user password >> entrophy to hinder online attacks and password guessing, >>=20 >> o Mitigate attacks on passwords by locking respective accounts have >> a number of failed attempts, >>=20 >> o Use "tar pit" techniques by temporarily locking a respective >> account and delaying responses for a certain duration. The >> duration may increase with the number of failed attempts, and >>=20 >> o Use authentication system that use CAPTCHA's and other factors for >> authenticating users further reducing the possibility of automated >> attacks. >>=20 >> 7.7. Case Insensitive Comparison & International Languages >>=20 >> When comparing unicode strings such as in query filters or testing >> for uniqueness of usernames and passwords, strings MUST be >> appropriately prepared before comparison. See Section 5. >>=20 >>=20 >> On Apr 29, 2015, at 1:31 PM, Phil Hunt >>> wrote: >>=20 >> Thanks. I think we have a plan! >>=20 >> Phil >>=20 >> On Apr 29, 2015, at 13:27, Kathleen Moriarty >>>>> wrote: >>=20 >> Hi Phil, >>=20 >> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt >>> wrote: >> Am I correct in assuming authentication is specifically excluded per >>the charter. The assumption was/is SCIM uses typical http authen/authz >>schemes and does not provide or mandate a method. >>=20 >> That said we have reservations about using 2617 mechanisms and prefer >>stronger options. >>=20 >> Good. This needs to be stated explicitly because of existing >>standards. My concerns are because of this text in your draft: >>=20 >>=20 >> 2. Authentication and Authorization >>=20 >> Because SCIM builds on the HTTP protocol, it does not itself define a >> scheme for authentication and authorization. SCIM depends on >> standard HTTP authentication schemes. Implementers SHOULD support >> existing authentication/authorization schemes. In particular, OAuth2 >>=20 >> (see [RFC6749], [RFC6750]) is RECOMMENDED. >>=20 >> Because it says OAuth2 is recommended for authentication and you are >>using this for bearer tokens, I am going to assume that the 3 options >>established for that purpose are being used, with the default being HTTP >>Basic. In my original discuss, I provided a link to the updated version >>of Basic (in the RFC editor queue). When you recommend against it's >>use, you should refer to the security considerations section of that >>draft, it updates 2617 for Basic. Digest is in a separate update. >>=20 >> Since bearer tokens are used, I have to assume all of the security >>issues with those as well. First is the IETF registered and supported >>authentication methods, then the lack of security in the token itself. >>Holder-of-key tokens require proof of possession (there is some crypto >>to do this). The only thing you can do to protect a bearer token is to >>use TLS and there needs to be a reference to the security section I >>mentioned in my original post so users know where to look to understand >>issues with bearer tokens. >>=20 >> I hope that helps. >>=20 >> Is this is the approach we are looking for? >> Yes, being explicit would be very helpful as I'll assume defaults and >>limitations like registered/supported methods. >>=20 >> Thank you, >> Kathleen >>=20 >>=20 >> Thanks, >>=20 >> Phil >>=20 >>> On Apr 29, 2015, at 13:08, Kathleen Moriarty >>>>>m>> wrote: >>>=20 >>> Phil and I chatted a bit and he is working up some text with specific >>> authentication options. I said I would look up some more references >>>and am >>> providing them inline here. >>>=20 >>> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < >>>=20 >>>kathleen.moriarty.ietf@gmail.com>>>> wrote: >>>=20 >>>> Hi Phil, >>>>=20 >>>> Just a quick response for now and more later. I'll find the specific >>>> references and registry for authentication used with OAuth. I'm the >>>>AD and >>>> have been reading their drafts carefully. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt >>>>>> wrote: >>>>>=20 >>>>> Kathleen, >>>>>=20 >>>>> Thanks for your comments. My comments in line=8A >>>>>=20 >>>>> General comment. At the end of the day, SCIM is just an HTTP >>>>>protocol >>>> (an application) and as such can use any of the normal HTTP >>>>mechanisms. In >>>> OAuth terms it is just a resource server. I wonder what we can point >>>>to as >>>> a general best practice for authentication and authorization. >>>=20 >>> Yes, the issue I hit was that the text of this draft said that OAuth >>>is the >>> authentication protocol, when it's only an authorization protocol. As >>> such, a reader might jump to a conclusion that HTTP Basic is the way >>>to go >>> since it's the first method (and default) for OAuth in the OAuth 2.0 >>> framework. Recent drafts that mention the same registry where the >>> supported authentication protocols from the client to the AS have not >>> updated that short list. If you could rewrite the text to specify >>> recommended authentication types, that would be good. >>>=20 >>> See section 2.3 of https://tools.ietf.org/html/rfc6749 >>> and the 3 methods defined are stated again in the dyn registry draft( >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically >>> saying to authenticate to use a token, these methods are available: >>>=20 >>> token_endpoint_auth_method >>> String indicator of the requested authentication method for the >>> token endpoint. Values defined by this specification are: >>>=20 >>> * "none": The client is a public client as defined in OAuth 2.0 >>> and does not have a client secret. >>> * "client_secret_post": The client uses the HTTP POST parameters >>> defined in OAuth 2.0 section 2.3.1. >>> * "client_secret_basic": the client uses HTTP Basic defined in >>> OAuth 2.0 section 2.3.1 >>>=20 >>> Additional values can be defined via the IANA OAuth Token Endpoint >>> Authentication Methods Registry established in Section 4.2. >>> Absolute URIs can also be used as values for this parameter >>> without being registered. If unspecified or omitted, the default >>> is "client_secret_basic", denoting HTTP Basic Authentication >>> Scheme as specified in Section 2.3.1 of OAuth 2.0. >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>> The use of OAuth was in part, a reflection of the growing popularity >>>>>of >>>> OAuth at the time of writing, and I believe a conscious attempt by the >>>> original authors to discourage the use of simple password >>>>authentication >>>> such as RFC2617=B9s basic authentication. For this reason we did not >>>>want to >>>> use Basic in the examples. >>>=20 >>> It's specified as the default in OAuth 2.0 when using a token. see >>>above > From nobody Thu May 7 10:22:08 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48751A1A10 for ; Thu, 7 May 2015 10:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glJiApRGUVX1 for ; Thu, 7 May 2015 10:22:06 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDD21A1A04 for ; Thu, 7 May 2015 10:22:06 -0700 (PDT) Received: by wgin8 with SMTP id n8so50417812wgi.0 for ; Thu, 07 May 2015 10:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Oj8r8E6N5vgkIzTkF5qSgyf+S1IB5Qw/Zl8ehd0cZ/U=; b=ngYrcXoQI21Gxozs1hmCHMsj2UrFQbJkBDF+NtprDBDMi6LeTKansYgh7SDDSDwjKm erljNMdiXoLfvTbRUzJl8W/qowcCttO7cJmQwB9KdlwD7Nhqy/TYWN7d52PLTJDEdmzI mOfDbOxChOIvEt1w3e12evYGdOR02z8pFfNTVLY+8k2jWS5APwbS5JyS803Qg2XFDchc Si/j6Xh/IfgeL0+1ci0gvUaxLe6zAordQQto6x6idCS02InXUWZOVQNqoK6c11Lka+/0 LTNlp9Tg6CQws5aZQj5uDtMmBos4CP/7VtLbAmGCqqUHv1I9I0zkwCXTQwri4QXfZ9RK AFRA== MIME-Version: 1.0 X-Received: by 10.194.7.97 with SMTP id i1mr9701648wja.107.1431019324989; Thu, 07 May 2015 10:22:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.194.237.234 with HTTP; Thu, 7 May 2015 10:22:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 May 2015 18:22:04 +0100 X-Google-Sender-Auth: UQKx3p5wMwBcnDc-7-OtHAKpyvY Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary=047d7b5d86a58865c305158126f7 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 17:22:07 -0000 --047d7b5d86a58865c305158126f7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks! Barry On Thursday, May 7, 2015, Morteza Ansari (moransar) wrote: > Barry, > > I believe the latest version of the use cases draft > (draft-ietf-scim-use-cases-08.txt) and Kathleen=B9s acceptance of the > changes to the security/privacy section address all comments received so > far. > > > Cheers, > Morteza > > On 5/1/15, 3:39 AM, "Barry Leiba" = > > wrote: > > >There's still a DISCUSS on the use-cases doc. What is the status of > >addressing that, as well as the non-blocking comments from IESG > >evaluation? > > > >Barry > > > >_______________________________________________ > >scim mailing list > >scim@ietf.org > >https://www.ietf.org/mailman/listinfo/scim > > --047d7b5d86a58865c305158126f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks!

Barry

On Thursday, May 7, 2015, Morteza A= nsari (moransar) <moransar@cisco.c= om> wrote:
Barry,

I believe the latest version of the use cases draft
(draft-ietf-scim-use-cases-08.txt) and Kathleen=B9s acceptance of the
changes to the security/privacy section address all comments received so far.


Cheers,
Morteza

On 5/1/15, 3:39 AM, "Barry Leiba" <barr= yleiba@computer.org> wrote:

>There's still a DISCUSS on the use-cases doc.=A0 What is the status= of
>addressing that, as well as the non-blocking comments from IESG
>evaluation?
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>https://www.ietf.org/mailman/listinfo/scim

--047d7b5d86a58865c305158126f7-- From nobody Fri May 8 00:59:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233061A0091; Fri, 8 May 2015 00:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VxOSNbdFklS; Fri, 8 May 2015 00:59:30 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9AB1ACEDF; Fri, 8 May 2015 00:59:30 -0700 (PDT) Received: by pdea3 with SMTP id a3so70937613pde.3; Fri, 08 May 2015 00:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DPbS7OjePPff0DY4ruiEb0NeGe+/8L818/V83UFhbBg=; b=KQANkdz7GFQyM58NDaZkY7TcsiaVhPZjTGcbcJ3Ln9deImZD6z6qUpFWr0lGdG/A+k iMgo12KvZhGsmxrwkmijqZ9cH/tw50ci40ONauDJ/FA42/GxNcvfVjmhM5R2DUH3/Ttp QMMH17N4hEUk0M1E69yvJPaoSlbSqxgkBqjNY+rntGG7+p7YS+H+dF5Kw2tVntEb04zV ogExUK7a3qS5WouNkt/i3z+TPLwZY7dxs1PmMGrdO16ttWH0sccDQlp20TxIEz2SfSRH Yy9hhQm7BDvhjZ+yJqOsiRTd2ftfvlAFttS15rMKMD33CFyNoUSMu98vZRCr0GvNlGUh xaBQ== X-Received: by 10.68.224.10 with SMTP id qy10mr4543660pbc.23.1431071933136; Fri, 08 May 2015 00:58:53 -0700 (PDT) Received: from [10.248.236.202] ([166.170.38.54]) by mx.google.com with ESMTPSA id ck4sm4279864pbc.67.2015.05.08.00.58.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 May 2015 00:58:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 8 May 2015 08:58:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> <90A04069-60FF-4E91-9A91-55025A13255B@oracle.com> To: Patrick Radtke Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" , Phil Hunt Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 07:59:35 -0000 Hi, The text is very much improved, thank you for your efforts! I do have some suggestions and will propose text around the bearer tokens te= xt to include text on the defaults for authentication of oauth bearer tokens= (http Basic, none & secret) as well as to the link to the security consider= ations previously mentioned for bearer tokens. I won't have time until late= r today, so if you're able to propose something with the previous references= provided (including the updated HTTP basic draft for sec considerations, I m= ight be able to clear sooner do you can update the draft. Thank you! Kathleen=20 Sent from my iPhone > On May 7, 2015, at 5:52 PM, Patrick Radtke wrote: >=20 > I didn=C2=B9t catch that reference in my initial read through. > I think that RFC covers all the downsides associated with cookies. >=20 > -Patrick >=20 >=20 >> On 5/7/15, 8:32 AM, "Phil Hunt" wrote: >>=20 >> Patrick & Kathleen, >>=20 >> Would a reference to the security considerations for RFC6265 =C2=B3HTTP S= tate >> Management Mechanism" cover this adequately? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On May 6, 2015, at 4:59 PM, Patrick Radtke >>> wrote: >>>=20 >>> Everything looked good to me except the Cookie authentication for >>> JavaScript clients - there is no guidance for CSRF protection. >>> Two Cookie/CSRF attack scenarios that come to mind (based on this doc) >>>=20 >>> http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/refere= n >>> ce/htmlsingle/#csrf-protection-and-json >>>=20 >>>=20 >>> 1. Attacker site does cross site POST to /Users endpoint. The >>> Service provider does not check the Content-Type header, only looks at >>> the Cookie and is fooled into thinking it is a legitimate request. >>> 2. Attacker site does cross site POST using a URI suffix to >>> /User.scim or /Users.json. The Service Provider=C2=B9s REST framework >>> automatically sets a Content-Type header based on URI suffix, and the >>> actual implementation is fooled into thinking Content-Type header was >>> set by the client. >>>=20 >>> Maybe some guidance along the lines of =C2=B3To prevent CSRF attacks the= >>> service provider MUST check the Content-Type of the request and MUST NOT= >>> allow POSTs to uri suffixed endpoints" >>>=20 >>> -Patrick >>>=20 >>> From: Phil Hunt > >>> Date: Wednesday, May 6, 2015 at 4:02 PM >>> To: Kathleen Moriarty >>> >> Cc:=20 >>> "draft-ietf-scim-api.ad@ietf.org= " >>>=20 >>> = > >>> , "scim@ietf.org" >>> >, >>> "draft-ietf-scim-api.shepherd@ietf.org>> d@ietf.org>"=20 >>> >> d@ietf.org>>, The IESG >, >>> "draft-ietf-scim-api@ietf.org" >>> >, >>> "scim-chairs@ietf.org" >>> > >>> Subject: Re: [scim] Kathleen Moriarty's Discuss on >>> draft-ietf-scim-api-17: (with DISCUSS and COMMENT) >>>=20 >>> Kathleen, >>>=20 >>> Apologies for pasting a lot of text in here, but after considering >>> comments from you and Brian, I wanted to re-think a number of things and= >>> try and boil things down a bit (I probably can do some more). I=C2=B9ve >>> essentially re-written the authentication and security sections with >>> care not to change consensus, but to address the issues you mentioned. >>> I hope we are close. Please take a look at the pasted sections below. >>> If you are in agreement, I can post them in the next document update. >>>=20 >>> Thanks for your help! >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>> ------------------------------ >>> Section 2 Proposed: >>>=20 >>> 2. Authentication and Authorization >>>=20 >>> SCIM Protocol is based upon HTTP and does not itself define a SCIM >>> specific scheme for authentication and authorization. SCIM depends >>> on the use of TLS and/or standard HTTP authentication and >>> authorization schemes as per [RFC7235]. For example, the following >>> methodologies could be used among others: >>>=20 >>> TLS Client Authentication >>> The SCIM service provider MAY request TLS client authentication >>> (also known as mutual authentication). See Section 7.3 [RFC5246]. >>>=20 >>> HTTP Origin-Bound Authentication (HOBA) is a variation on TLS >>> client authentication and uses a digital-signature-based design >>> for an HTTP authentication method (see [RFC7486]). The design can >>> also be used in JavaScript-based authentication embedded in HTML. >>> HOBA is an alternative to HTTP authentication schemes that require >>> passwords and therefore avoids all problems related to passwords, >>> such as leakage of server-side password databases. >>>=20 >>> Bearer Tokens >>> Bearer tokens [RFC6750] MAY be used when combined with TLS and a >>> token framework such as OAuth2 [RFC6749]. See Section 7.3 for >>> security considerations regarding the use of bearer tokens in >>> SCIM. While bearer tokens most often represent an authorization, >>> it is assumed that the authorization was based upon a successful >>> authentication of the SCIM client. Accordingly the SCIM service >>> provider must have a method for validating, parsing, and or >>> introspecting the bearer token for the relevant authentication and >>> authorization information. The method for this is assumed to be >>> defined by the token issuing system and is beyond the scope of >>> this specification. >>>=20 >>> POP Tokens >>> A proof-of-possession token demonstrates the presenter of the >>> token possesses a particular key and that the recipient can >>> cryptographically confirm proof-of-possession of the key by the >>> presenter. This property is sometimes also described as the >>> presenter being a holder-of-key. See OAuth >>> [I-D.ietf-oauth-pop-architecture] for an example of such a token >>> and its use. >>>=20 >>> Cookies >>> Javascript clients MAY assert HTTP cookies over TLS that contain >>> an authentication state that is understood by the SCIM service >>> provider (see [RFC6265]). An example of this is scenarios where >>> web-form authentication has taken place with the user and HTTP >>> cookies were set representing the authentication state. For the >>> purposes of SCIM, the security considerations in Section 7.3 >>> apply. >>>=20 >>> As per Section 4.1 of [RFC7235], a SCIM service provider SHALL >>> indicate supported HTTP authentication schemes via the "WWW- >>> Authenticate" header. >>>=20 >>> For all of the above methodologies, the SCIM service provider MUST be >>> able to map the authenticated client to an access control policy in >>> order to determine the client's authorization to retrieve and update >>> SCIM resources. For example, while a browser session may have been >>> established via HTTP cookie or TLS client authentication, the unique >>> client MUST be mapped to a security subject (e.g., User). The >>> authorization model and the process by which this is done is beyond >>> the scope of this specification. >>>=20 >>> Because SCIM is a protocol for provisioning resources cross domains >>> (e.g., user accounts and access control information such as groups), >>> weaker authentication mechanisms based on static symmetric secrets >>> such as passwords SHOULD NOT be used. In particular, the >>> authentication schemes (e.g., Basic Authentication) described in >>> [RFC2617] SHOULD NOT be used. >>>=20 >>> When processing requests, the service provider SHOULD consider the >>> subject performing the request and whether the action is appropriate >>> given the subject and the resource affected by the request. The >>> subject performing the request is usually determined directly or >>> indirectly from the "Authorization" header present in the request. >>> For example, a subject MAY be permitted to retrieve and update their >>> own "User" resource, but will normally have restricted ability to >>> access resources associated with other Users. In other cases, the >>> SCIM service provider might only grant access to a subject's own >>> associated "User" resource (e.g., for the purpose of updating >>> personal contact attributes). >>>=20 >>> For illustrative purposes only, examples show an OAuth2 bearer token >>> value [RFC6750] in the authorization header; e.g., >>>=20 >>> GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 >>> Host: example.com >>> Authorization: Bearer h480djs93hd8 >>>=20 >>> This is not intended to imply that bearer tokens are preferred. >>> However, the use of bearer tokens in the specification does reflect >>> common implementation practice. >>>=20 >>>=20 >>> 2.1. Anonymous Requests >>>=20 >>> In some SCIM deployments it MAY be acceptable to permit >>> unauthenticated (anonymous) requests. For example, a user self- >>> registration request where the service provider chooses to accept a >>> SCIM Create request (see Section 3.3) from an anonymous client. See >>> Section 7.5, for security considerations regarding anonymous >>> requests. >>>=20 >>>=20 >>> ------------------------------ >>> Section 7 Proposed (note the example in 7.4 needs correction still): >>>=20 >>>=20 >>> 7. Security Considerations >>>=20 >>> 7.1. HTTP Considerations >>>=20 >>> SCIM Protocol layers on top of Hypertext Transfer Protocol and thus >>> subject to the security considerations of HTTP Section 9 [RFC7230] >>> and its related specifications. >>>=20 >>> As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate >>> the userinfo (i.e., username and password) component (and its "@" >>> delimiter) when an "http" URI reference is generated with a message >>> as they are now disallowed in HTTP. >>>=20 >>> 7.2. TLS Support Considerations >>>=20 >>> SCIM resources (e.g., Users and Groups) can contain sensitive >>> information including passwords. Therefore, SCIM clients and service >>> providers MUST require the use of a transport-layer security >>> mechanism when communicating with SCIM service providers. The SCIM >>> service provider MUST support TLS 1.2 [RFC5246] and MAY support >>> additional transport-layer mechanisms meeting its security >>> requirements. When using TLS, the client MUST perform a TLS/SSL >>> server certificate check, per [RFC6125]. Implementation security >>> considerations for TLS can be found in "Recommendations for Secure >>> Use of TLS and DTLS" [RFC7525]. >>>=20 >>> 7.3. Bearer and Cookie Considerations >>>=20 >>> Since the posession of a bearer token or cookie MAY authorize the >>> holder to potentially read, modify, or delete resources, tokens and >>> cookies MUST contain sufficient entropy to prevent a random guessing >>> attack, such as described in Section 5.2 of [RFC6750] and >>> Section 5.1.4.2.2 of [RFC6819]. >>>=20 >>> As with all SCIM communications, Bearer tokens and HTTP cookies MUST >>> be exchanged using TLS. >>>=20 >>> Bearer tokens MUST have a limited lifetime that can be determined >>> directly or indirectly (e.g., by checking with a validation service) >>> by the service provider. By expiring tokens, clients are forced to >>> obtain a new token (which usually involves re-authentication) for >>> continued authorized access. For example, in OAuth2, a client MAY >>> use OAuth token refresh to obtain a new bearer token after >>> authenticating to an authorization server. See Section 6 of >>> [RFC6749]. >>>=20 >>> As with Bearer tokens, an HTTP cookie SHOULD last no longer than the >>> lifetime of a browser session. An expiry time should be set that >>> limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. >>>=20 >>> 7.4. Privacy Considerations >>>=20 >>> 7.4.1. Personal Information >>>=20 >>> The SCIM Core Schema specifications defines attributes that MAY >>> contain personally identifying information as well as other sensitive >>> personal data. The privacy considerations in the Security >>> Considerations Section of [I-D.ietf-scim-core-schema] MUST be >>> considered. >>>=20 >>> 7.4.2. Disclosure of Sensitive Information in URIs >>>=20 >>> As mentioned in Section 9.4 [RFC7231], SCIM clients requesting >>> information using query filters using HTTP GET SHOULD give >>> consideration to the information content of the filters and whether >>> their exposure in a URI would represent a breach of security or >>> confidentiality through leakage in a web browsers or server logs. >>> This is particularly true for information that is legally considered >>> "personally identifiable information" or is otherwise restricted by >>> privacy laws. In these situations to ensure maximum security and >>> confidentiality, clients SHOULD query using HTTP POST (see >>> Section 3.4.3 ). >>>=20 >>> Servers that receive HTTP GET requests using filters that contain >>> restricted or confidential information SHOULD respond with HTTP >>> status 403 indicating the operation is FORBIDDEN. A detailed error, >>> "confidential_restricted" may be returned indicating the request must >>> be submitted using POST. A non-normative example: >>>=20 >>>=20 >>> HTTP/1.1 403 FORBIDDEN >>>=20 >>> { >>> "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], >>> "Errors":[ >>> { >>> "description": >>> "Query filter involving 'name' is restricted or confidential", >>> "error":"confidential_restricted" >>> } >>> ] >>> } >>>=20 >>> 7.5. Anonymous Requests >>>=20 >>> If a SCIM service provider accepts anonymous requests such as SCIM >>> resource creation requests (via HTTP POST), appropriate security >>> measures should be put in place to prevent or limit exposure to >>> attacks. The following counter-measures MAY be used: >>>=20 >>> o Try to authenticate web UI components that forumulate the SCIM >>> creation request. While the end-user MAY be anonymous, the web >>> user interface component often has its own way to authenticate to >>> the SCIM service provider (e.g., has an OAuth client credential >>> [RFC6749]) and the web user interface component may implement its >>> own measures (e.g., such as CAPTCHA) to ensure a ligitimate >>> request is being made. >>>=20 >>> o Limit the number of requests any particular client MAY make in a >>> period of time. >>>=20 >>> o For User resources, default newly created resource with an >>> "active" setting of "false" and use a secondary confirmation >>> process (e.g., email confirmation) to ensure the resource created >>> is real. >>>=20 >>> 7.6. Secure Storage and Handling of Sensitive Data >>>=20 >>> An attacker may obtain valid username/password combinations from the >>> SCIM service provider's underlying database by gaining access to the >>> database and/or launching injection attacks. This could lead to >>> unintended disclosure of username/password combinations. The impact >>> may extend beyond the domain of the SCIM service provider if the data >>> was provisioned from other domains. >>>=20 >>> Administrators should undertake industry best practices to protect >>> the storage of credentials and in particular SHOULD follow >>> recommendations outlines in Section 5.1.4.1 [RFC6819]. These >>> recommendations include but are not limited to: >>>=20 >>> o Provide injection attack counter measures (e.g., by validating all >>> inputs and parameters), >>>=20 >>> o No cleartext storage of credentials, >>>=20 >>> o Store credentials using an encrypted protection mechanism, and >>>=20 >>> o Avoid passwords and consider use of asymmetric cryptography based >>> credentials. >>>=20 >>> As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take >>> counter measures to prevent online attacks on secrets such as: >>>=20 >>> o Utilize secure password policy in order to increase user password >>> entrophy to hinder online attacks and password guessing, >>>=20 >>> o Mitigate attacks on passwords by locking respective accounts have >>> a number of failed attempts, >>>=20 >>> o Use "tar pit" techniques by temporarily locking a respective >>> account and delaying responses for a certain duration. The >>> duration may increase with the number of failed attempts, and >>>=20 >>> o Use authentication system that use CAPTCHA's and other factors for >>> authenticating users further reducing the possibility of automated >>> attacks. >>>=20 >>> 7.7. Case Insensitive Comparison & International Languages >>>=20 >>> When comparing unicode strings such as in query filters or testing >>> for uniqueness of usernames and passwords, strings MUST be >>> appropriately prepared before comparison. See Section 5. >>>=20 >>>=20 >>> On Apr 29, 2015, at 1:31 PM, Phil Hunt >>> > wrote: >>>=20 >>> Thanks. I think we have a plan! >>>=20 >>> Phil >>>=20 >>> On Apr 29, 2015, at 13:27, Kathleen Moriarty >>> >>>> wrote: >>>=20 >>> Hi Phil, >>>=20 >>> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt >>> > wrote: >>> Am I correct in assuming authentication is specifically excluded per >>> the charter. The assumption was/is SCIM uses typical http authen/authz >>> schemes and does not provide or mandate a method. >>>=20 >>> That said we have reservations about using 2617 mechanisms and prefer >>> stronger options. >>>=20 >>> Good. This needs to be stated explicitly because of existing >>> standards. My concerns are because of this text in your draft: >>>=20 >>>=20 >>> 2. Authentication and Authorization >>>=20 >>> Because SCIM builds on the HTTP protocol, it does not itself define a >>> scheme for authentication and authorization. SCIM depends on >>> standard HTTP authentication schemes. Implementers SHOULD support >>> existing authentication/authorization schemes. In particular, OAuth2 >>>=20 >>> (see [RFC6749], [RFC6750]) is RECOMMENDED. >>>=20 >>> Because it says OAuth2 is recommended for authentication and you are >>> using this for bearer tokens, I am going to assume that the 3 options >>> established for that purpose are being used, with the default being HTTP= >>> Basic. In my original discuss, I provided a link to the updated version= >>> of Basic (in the RFC editor queue). When you recommend against it's >>> use, you should refer to the security considerations section of that >>> draft, it updates 2617 for Basic. Digest is in a separate update. >>>=20 >>> Since bearer tokens are used, I have to assume all of the security >>> issues with those as well. First is the IETF registered and supported >>> authentication methods, then the lack of security in the token itself. >>> Holder-of-key tokens require proof of possession (there is some crypto >>> to do this). The only thing you can do to protect a bearer token is to >>> use TLS and there needs to be a reference to the security section I >>> mentioned in my original post so users know where to look to understand >>> issues with bearer tokens. >>>=20 >>> I hope that helps. >>>=20 >>> Is this is the approach we are looking for? >>> Yes, being explicit would be very helpful as I'll assume defaults and >>> limitations like registered/supported methods. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Phil >>>=20 >>>> On Apr 29, 2015, at 13:08, Kathleen Moriarty >>>> >>> m>> wrote: >>>>=20 >>>> Phil and I chatted a bit and he is working up some text with specific >>>> authentication options. I said I would look up some more references >>>> and am >>>> providing them inline here. >>>>=20 >>>> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < >>>>=20 >>>> kathleen.moriarty.ietf@gmail.com>>>>> wrote: >>>>=20 >>>>> Hi Phil, >>>>>=20 >>>>> Just a quick response for now and more later. I'll find the specific >>>>> references and registry for authentication used with OAuth. I'm the >>>>> AD and >>>>> have been reading their drafts carefully. >>>>>=20 >>>>> Thanks, >>>>> Kathleen >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt >>>>>> > wrote: >>>>>>=20 >>>>>> Kathleen, >>>>>>=20 >>>>>> Thanks for your comments. My comments in line=C5=A0 >>>>>>=20 >>>>>> General comment. At the end of the day, SCIM is just an HTTP >>>>>> protocol >>>>> (an application) and as such can use any of the normal HTTP >>>>> mechanisms. In >>>>> OAuth terms it is just a resource server. I wonder what we can point >>>>> to as >>>>> a general best practice for authentication and authorization. >>>>=20 >>>> Yes, the issue I hit was that the text of this draft said that OAuth >>>> is the >>>> authentication protocol, when it's only an authorization protocol. As >>>> such, a reader might jump to a conclusion that HTTP Basic is the way >>>> to go >>>> since it's the first method (and default) for OAuth in the OAuth 2.0 >>>> framework. Recent drafts that mention the same registry where the >>>> supported authentication protocols from the client to the AS have not >>>> updated that short list. If you could rewrite the text to specify >>>> recommended authentication types, that would be good. >>>>=20 >>>> See section 2.3 of https://tools.ietf.org/html/rfc6749 >>>> and the 3 methods defined are stated again in the dyn registry draft( >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically >>>> saying to authenticate to use a token, these methods are available: >>>>=20 >>>> token_endpoint_auth_method >>>> String indicator of the requested authentication method for the >>>> token endpoint. Values defined by this specification are: >>>>=20 >>>> * "none": The client is a public client as defined in OAuth 2.0 >>>> and does not have a client secret. >>>> * "client_secret_post": The client uses the HTTP POST parameters >>>> defined in OAuth 2.0 section 2.3.1. >>>> * "client_secret_basic": the client uses HTTP Basic defined in >>>> OAuth 2.0 section 2.3.1 >>>>=20 >>>> Additional values can be defined via the IANA OAuth Token Endpoint >>>> Authentication Methods Registry established in Section 4.2. >>>> Absolute URIs can also be used as values for this parameter >>>> without being registered. If unspecified or omitted, the default >>>> is "client_secret_basic", denoting HTTP Basic Authentication >>>> Scheme as specified in Section 2.3.1 of OAuth 2.0. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> The use of OAuth was in part, a reflection of the growing popularity >>>>>> of >>>>> OAuth at the time of writing, and I believe a conscious attempt by the= >>>>> original authors to discourage the use of simple password >>>>> authentication >>>>> such as RFC2617=C2=B9s basic authentication. For this reason we did n= ot >>>>> want to >>>>> use Basic in the examples. >>>>=20 >>>> It's specified as the default in OAuth 2.0 when using a token. see >>>> above >=20 From nobody Fri May 8 09:09:24 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533891AC425; Fri, 8 May 2015 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lmvDpvmB711; Fri, 8 May 2015 09:09:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5131ABD36; Fri, 8 May 2015 09:09:16 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t48G998b021326 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 May 2015 16:09:09 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t48G99ui015385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 May 2015 16:09:09 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t48G99lt012111; Fri, 8 May 2015 16:09:09 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 May 2015 09:09:08 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Fri, 8 May 2015 09:09:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <489E5622-887A-49DE-912D-014C155E84FA@oracle.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> <906B9E1F-D3A7-4896-921E-AD4F43B50704@oracle.com> <90A04069-60FF-4E91-9A91-55025A13255B@oracle.com> To: Kathleen Moriarty X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , Patrick Radtke , "scim@ietf.org" , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 16:09:21 -0000 Ok. Sounds good.=20 I have some other items from Elwyn to do (on both drafts). Eg use relative u= ri's in the examples Based on your comments we are in good shape for a new rev for the weekend wh= ich should give lots of time for the telechat.=20 Thanks, Phil > On May 8, 2015, at 00:58, Kathleen Moriarty wrote: >=20 > Hi, >=20 > The text is very much improved, thank you for your efforts! >=20 > I do have some suggestions and will propose text around the bearer tokens t= ext to include text on the defaults for authentication of oauth bearer token= s (http Basic, none & secret) as well as to the link to the security conside= rations previously mentioned for bearer tokens. I won't have time until lat= er today, so if you're able to propose something with the previous reference= s provided (including the updated HTTP basic draft for sec considerations, I= might be able to clear sooner do you can update the draft. >=20 > Thank you! > Kathleen=20 >=20 > Sent from my iPhone >=20 >> On May 7, 2015, at 5:52 PM, Patrick Radtke wrote: >>=20 >> I didn=C2=B9t catch that reference in my initial read through. >> I think that RFC covers all the downsides associated with cookies. >>=20 >> -Patrick >>=20 >>=20 >>> On 5/7/15, 8:32 AM, "Phil Hunt" wrote: >>>=20 >>> Patrick & Kathleen, >>>=20 >>> Would a reference to the security considerations for RFC6265 =C2=B3HTTP S= tate >>> Management Mechanism" cover this adequately? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On May 6, 2015, at 4:59 PM, Patrick Radtke >>>> wrote: >>>>=20 >>>> Everything looked good to me except the Cookie authentication for >>>> JavaScript clients - there is no guidance for CSRF protection. >>>> Two Cookie/CSRF attack scenarios that come to mind (based on this doc) >>>>=20 >>>> http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/refer= en >>>> ce/htmlsingle/#csrf-protection-and-json >>>>=20 >>>>=20 >>>> 1. Attacker site does cross site POST to /Users endpoint. The >>>> Service provider does not check the Content-Type header, only looks at >>>> the Cookie and is fooled into thinking it is a legitimate request. >>>> 2. Attacker site does cross site POST using a URI suffix to >>>> /User.scim or /Users.json. The Service Provider=C2=B9s REST framework >>>> automatically sets a Content-Type header based on URI suffix, and the >>>> actual implementation is fooled into thinking Content-Type header was >>>> set by the client. >>>>=20 >>>> Maybe some guidance along the lines of =C2=B3To prevent CSRF attacks th= e >>>> service provider MUST check the Content-Type of the request and MUST NO= T >>>> allow POSTs to uri suffixed endpoints" >>>>=20 >>>> -Patrick >>>>=20 >>>> From: Phil Hunt > >>>> Date: Wednesday, May 6, 2015 at 4:02 PM >>>> To: Kathleen Moriarty >>>> >>> Cc:=20 >>>> "draft-ietf-scim-api.ad@ietf.org" >>>>=20 >>>> > >>>> , "scim@ietf.org" >>>> >, >>>> "draft-ietf-scim-api.shepherd@ietf.org>>> d@ietf.org>"=20 >>>> >>> d@ietf.org>>, The IESG >, >>>> "draft-ietf-scim-api@ietf.org" >>>> >, >>>> "scim-chairs@ietf.org" >>>> > >>>> Subject: Re: [scim] Kathleen Moriarty's Discuss on >>>> draft-ietf-scim-api-17: (with DISCUSS and COMMENT) >>>>=20 >>>> Kathleen, >>>>=20 >>>> Apologies for pasting a lot of text in here, but after considering >>>> comments from you and Brian, I wanted to re-think a number of things an= d >>>> try and boil things down a bit (I probably can do some more). I=C2=B9ve= >>>> essentially re-written the authentication and security sections with >>>> care not to change consensus, but to address the issues you mentioned. >>>> I hope we are close. Please take a look at the pasted sections below. >>>> If you are in agreement, I can post them in the next document update. >>>>=20 >>>> Thanks for your help! >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> ------------------------------ >>>> Section 2 Proposed: >>>>=20 >>>> 2. Authentication and Authorization >>>>=20 >>>> SCIM Protocol is based upon HTTP and does not itself define a SCIM >>>> specific scheme for authentication and authorization. SCIM depends >>>> on the use of TLS and/or standard HTTP authentication and >>>> authorization schemes as per [RFC7235]. For example, the following >>>> methodologies could be used among others: >>>>=20 >>>> TLS Client Authentication >>>> The SCIM service provider MAY request TLS client authentication >>>> (also known as mutual authentication). See Section 7.3 [RFC5246]. >>>>=20 >>>> HTTP Origin-Bound Authentication (HOBA) is a variation on TLS >>>> client authentication and uses a digital-signature-based design >>>> for an HTTP authentication method (see [RFC7486]). The design can >>>> also be used in JavaScript-based authentication embedded in HTML. >>>> HOBA is an alternative to HTTP authentication schemes that require >>>> passwords and therefore avoids all problems related to passwords, >>>> such as leakage of server-side password databases. >>>>=20 >>>> Bearer Tokens >>>> Bearer tokens [RFC6750] MAY be used when combined with TLS and a >>>> token framework such as OAuth2 [RFC6749]. See Section 7.3 for >>>> security considerations regarding the use of bearer tokens in >>>> SCIM. While bearer tokens most often represent an authorization, >>>> it is assumed that the authorization was based upon a successful >>>> authentication of the SCIM client. Accordingly the SCIM service >>>> provider must have a method for validating, parsing, and or >>>> introspecting the bearer token for the relevant authentication and >>>> authorization information. The method for this is assumed to be >>>> defined by the token issuing system and is beyond the scope of >>>> this specification. >>>>=20 >>>> POP Tokens >>>> A proof-of-possession token demonstrates the presenter of the >>>> token possesses a particular key and that the recipient can >>>> cryptographically confirm proof-of-possession of the key by the >>>> presenter. This property is sometimes also described as the >>>> presenter being a holder-of-key. See OAuth >>>> [I-D.ietf-oauth-pop-architecture] for an example of such a token >>>> and its use. >>>>=20 >>>> Cookies >>>> Javascript clients MAY assert HTTP cookies over TLS that contain >>>> an authentication state that is understood by the SCIM service >>>> provider (see [RFC6265]). An example of this is scenarios where >>>> web-form authentication has taken place with the user and HTTP >>>> cookies were set representing the authentication state. For the >>>> purposes of SCIM, the security considerations in Section 7.3 >>>> apply. >>>>=20 >>>> As per Section 4.1 of [RFC7235], a SCIM service provider SHALL >>>> indicate supported HTTP authentication schemes via the "WWW- >>>> Authenticate" header. >>>>=20 >>>> For all of the above methodologies, the SCIM service provider MUST be >>>> able to map the authenticated client to an access control policy in >>>> order to determine the client's authorization to retrieve and update >>>> SCIM resources. For example, while a browser session may have been >>>> established via HTTP cookie or TLS client authentication, the unique >>>> client MUST be mapped to a security subject (e.g., User). The >>>> authorization model and the process by which this is done is beyond >>>> the scope of this specification. >>>>=20 >>>> Because SCIM is a protocol for provisioning resources cross domains >>>> (e.g., user accounts and access control information such as groups), >>>> weaker authentication mechanisms based on static symmetric secrets >>>> such as passwords SHOULD NOT be used. In particular, the >>>> authentication schemes (e.g., Basic Authentication) described in >>>> [RFC2617] SHOULD NOT be used. >>>>=20 >>>> When processing requests, the service provider SHOULD consider the >>>> subject performing the request and whether the action is appropriate >>>> given the subject and the resource affected by the request. The >>>> subject performing the request is usually determined directly or >>>> indirectly from the "Authorization" header present in the request. >>>> For example, a subject MAY be permitted to retrieve and update their >>>> own "User" resource, but will normally have restricted ability to >>>> access resources associated with other Users. In other cases, the >>>> SCIM service provider might only grant access to a subject's own >>>> associated "User" resource (e.g., for the purpose of updating >>>> personal contact attributes). >>>>=20 >>>> For illustrative purposes only, examples show an OAuth2 bearer token >>>> value [RFC6750] in the authorization header; e.g., >>>>=20 >>>> GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 >>>> Host: example.com >>>> Authorization: Bearer h480djs93hd8 >>>>=20 >>>> This is not intended to imply that bearer tokens are preferred. >>>> However, the use of bearer tokens in the specification does reflect >>>> common implementation practice. >>>>=20 >>>>=20 >>>> 2.1. Anonymous Requests >>>>=20 >>>> In some SCIM deployments it MAY be acceptable to permit >>>> unauthenticated (anonymous) requests. For example, a user self- >>>> registration request where the service provider chooses to accept a >>>> SCIM Create request (see Section 3.3) from an anonymous client. See >>>> Section 7.5, for security considerations regarding anonymous >>>> requests. >>>>=20 >>>>=20 >>>> ------------------------------ >>>> Section 7 Proposed (note the example in 7.4 needs correction still): >>>>=20 >>>>=20 >>>> 7. Security Considerations >>>>=20 >>>> 7.1. HTTP Considerations >>>>=20 >>>> SCIM Protocol layers on top of Hypertext Transfer Protocol and thus >>>> subject to the security considerations of HTTP Section 9 [RFC7230] >>>> and its related specifications. >>>>=20 >>>> As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate >>>> the userinfo (i.e., username and password) component (and its "@" >>>> delimiter) when an "http" URI reference is generated with a message >>>> as they are now disallowed in HTTP. >>>>=20 >>>> 7.2. TLS Support Considerations >>>>=20 >>>> SCIM resources (e.g., Users and Groups) can contain sensitive >>>> information including passwords. Therefore, SCIM clients and service >>>> providers MUST require the use of a transport-layer security >>>> mechanism when communicating with SCIM service providers. The SCIM >>>> service provider MUST support TLS 1.2 [RFC5246] and MAY support >>>> additional transport-layer mechanisms meeting its security >>>> requirements. When using TLS, the client MUST perform a TLS/SSL >>>> server certificate check, per [RFC6125]. Implementation security >>>> considerations for TLS can be found in "Recommendations for Secure >>>> Use of TLS and DTLS" [RFC7525]. >>>>=20 >>>> 7.3. Bearer and Cookie Considerations >>>>=20 >>>> Since the posession of a bearer token or cookie MAY authorize the >>>> holder to potentially read, modify, or delete resources, tokens and >>>> cookies MUST contain sufficient entropy to prevent a random guessing >>>> attack, such as described in Section 5.2 of [RFC6750] and >>>> Section 5.1.4.2.2 of [RFC6819]. >>>>=20 >>>> As with all SCIM communications, Bearer tokens and HTTP cookies MUST >>>> be exchanged using TLS. >>>>=20 >>>> Bearer tokens MUST have a limited lifetime that can be determined >>>> directly or indirectly (e.g., by checking with a validation service) >>>> by the service provider. By expiring tokens, clients are forced to >>>> obtain a new token (which usually involves re-authentication) for >>>> continued authorized access. For example, in OAuth2, a client MAY >>>> use OAuth token refresh to obtain a new bearer token after >>>> authenticating to an authorization server. See Section 6 of >>>> [RFC6749]. >>>>=20 >>>> As with Bearer tokens, an HTTP cookie SHOULD last no longer than the >>>> lifetime of a browser session. An expiry time should be set that >>>> limits session cookie lifetime as per Section 5.2.1 of [RFC6265]. >>>>=20 >>>> 7.4. Privacy Considerations >>>>=20 >>>> 7.4.1. Personal Information >>>>=20 >>>> The SCIM Core Schema specifications defines attributes that MAY >>>> contain personally identifying information as well as other sensitive >>>> personal data. The privacy considerations in the Security >>>> Considerations Section of [I-D.ietf-scim-core-schema] MUST be >>>> considered. >>>>=20 >>>> 7.4.2. Disclosure of Sensitive Information in URIs >>>>=20 >>>> As mentioned in Section 9.4 [RFC7231], SCIM clients requesting >>>> information using query filters using HTTP GET SHOULD give >>>> consideration to the information content of the filters and whether >>>> their exposure in a URI would represent a breach of security or >>>> confidentiality through leakage in a web browsers or server logs. >>>> This is particularly true for information that is legally considered >>>> "personally identifiable information" or is otherwise restricted by >>>> privacy laws. In these situations to ensure maximum security and >>>> confidentiality, clients SHOULD query using HTTP POST (see >>>> Section 3.4.3 ). >>>>=20 >>>> Servers that receive HTTP GET requests using filters that contain >>>> restricted or confidential information SHOULD respond with HTTP >>>> status 403 indicating the operation is FORBIDDEN. A detailed error, >>>> "confidential_restricted" may be returned indicating the request must >>>> be submitted using POST. A non-normative example: >>>>=20 >>>>=20 >>>> HTTP/1.1 403 FORBIDDEN >>>>=20 >>>> { >>>> "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], >>>> "Errors":[ >>>> { >>>> "description": >>>> "Query filter involving 'name' is restricted or confidential", >>>> "error":"confidential_restricted" >>>> } >>>> ] >>>> } >>>>=20 >>>> 7.5. Anonymous Requests >>>>=20 >>>> If a SCIM service provider accepts anonymous requests such as SCIM >>>> resource creation requests (via HTTP POST), appropriate security >>>> measures should be put in place to prevent or limit exposure to >>>> attacks. The following counter-measures MAY be used: >>>>=20 >>>> o Try to authenticate web UI components that forumulate the SCIM >>>> creation request. While the end-user MAY be anonymous, the web >>>> user interface component often has its own way to authenticate to >>>> the SCIM service provider (e.g., has an OAuth client credential >>>> [RFC6749]) and the web user interface component may implement its >>>> own measures (e.g., such as CAPTCHA) to ensure a ligitimate >>>> request is being made. >>>>=20 >>>> o Limit the number of requests any particular client MAY make in a >>>> period of time. >>>>=20 >>>> o For User resources, default newly created resource with an >>>> "active" setting of "false" and use a secondary confirmation >>>> process (e.g., email confirmation) to ensure the resource created >>>> is real. >>>>=20 >>>> 7.6. Secure Storage and Handling of Sensitive Data >>>>=20 >>>> An attacker may obtain valid username/password combinations from the >>>> SCIM service provider's underlying database by gaining access to the >>>> database and/or launching injection attacks. This could lead to >>>> unintended disclosure of username/password combinations. The impact >>>> may extend beyond the domain of the SCIM service provider if the data >>>> was provisioned from other domains. >>>>=20 >>>> Administrators should undertake industry best practices to protect >>>> the storage of credentials and in particular SHOULD follow >>>> recommendations outlines in Section 5.1.4.1 [RFC6819]. These >>>> recommendations include but are not limited to: >>>>=20 >>>> o Provide injection attack counter measures (e.g., by validating all >>>> inputs and parameters), >>>>=20 >>>> o No cleartext storage of credentials, >>>>=20 >>>> o Store credentials using an encrypted protection mechanism, and >>>>=20 >>>> o Avoid passwords and consider use of asymmetric cryptography based >>>> credentials. >>>>=20 >>>> As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take >>>> counter measures to prevent online attacks on secrets such as: >>>>=20 >>>> o Utilize secure password policy in order to increase user password >>>> entrophy to hinder online attacks and password guessing, >>>>=20 >>>> o Mitigate attacks on passwords by locking respective accounts have >>>> a number of failed attempts, >>>>=20 >>>> o Use "tar pit" techniques by temporarily locking a respective >>>> account and delaying responses for a certain duration. The >>>> duration may increase with the number of failed attempts, and >>>>=20 >>>> o Use authentication system that use CAPTCHA's and other factors for >>>> authenticating users further reducing the possibility of automated >>>> attacks. >>>>=20 >>>> 7.7. Case Insensitive Comparison & International Languages >>>>=20 >>>> When comparing unicode strings such as in query filters or testing >>>> for uniqueness of usernames and passwords, strings MUST be >>>> appropriately prepared before comparison. See Section 5. >>>>=20 >>>>=20 >>>> On Apr 29, 2015, at 1:31 PM, Phil Hunt >>>> > wrote: >>>>=20 >>>> Thanks. I think we have a plan! >>>>=20 >>>> Phil >>>>=20 >>>> On Apr 29, 2015, at 13:27, Kathleen Moriarty >>>> >>>>> wrote: >>>>=20 >>>> Hi Phil, >>>>=20 >>>> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt >>>> > wrote: >>>> Am I correct in assuming authentication is specifically excluded per >>>> the charter. The assumption was/is SCIM uses typical http authen/authz >>>> schemes and does not provide or mandate a method. >>>>=20 >>>> That said we have reservations about using 2617 mechanisms and prefer >>>> stronger options. >>>>=20 >>>> Good. This needs to be stated explicitly because of existing >>>> standards. My concerns are because of this text in your draft: >>>>=20 >>>>=20 >>>> 2. Authentication and Authorization >>>>=20 >>>> Because SCIM builds on the HTTP protocol, it does not itself define a >>>> scheme for authentication and authorization. SCIM depends on >>>> standard HTTP authentication schemes. Implementers SHOULD support >>>> existing authentication/authorization schemes. In particular, OAuth2 >>>>=20 >>>> (see [RFC6749], [RFC6750]) is RECOMMENDED. >>>>=20 >>>> Because it says OAuth2 is recommended for authentication and you are >>>> using this for bearer tokens, I am going to assume that the 3 options >>>> established for that purpose are being used, with the default being HTT= P >>>> Basic. In my original discuss, I provided a link to the updated versio= n >>>> of Basic (in the RFC editor queue). When you recommend against it's >>>> use, you should refer to the security considerations section of that >>>> draft, it updates 2617 for Basic. Digest is in a separate update. >>>>=20 >>>> Since bearer tokens are used, I have to assume all of the security >>>> issues with those as well. First is the IETF registered and supported >>>> authentication methods, then the lack of security in the token itself. >>>> Holder-of-key tokens require proof of possession (there is some crypto >>>> to do this). The only thing you can do to protect a bearer token is to= >>>> use TLS and there needs to be a reference to the security section I >>>> mentioned in my original post so users know where to look to understand= >>>> issues with bearer tokens. >>>>=20 >>>> I hope that helps. >>>>=20 >>>> Is this is the approach we are looking for? >>>> Yes, being explicit would be very helpful as I'll assume defaults and >>>> limitations like registered/supported methods. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Phil >>>>=20 >>>>> On Apr 29, 2015, at 13:08, Kathleen Moriarty >>>>> >>>> m>> wrote: >>>>>=20 >>>>> Phil and I chatted a bit and he is working up some text with specific >>>>> authentication options. I said I would look up some more references >>>>> and am >>>>> providing them inline here. >>>>>=20 >>>>> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < >>>>>=20 >>>>> kathleen.moriarty.ietf@gmail.com>>>>>> wrote: >>>>>=20 >>>>>> Hi Phil, >>>>>>=20 >>>>>> Just a quick response for now and more later. I'll find the specific= >>>>>> references and registry for authentication used with OAuth. I'm the >>>>>> AD and >>>>>> have been reading their drafts carefully. >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt >>>>>>> > wrote: >>>>>>>=20 >>>>>>> Kathleen, >>>>>>>=20 >>>>>>> Thanks for your comments. My comments in line=C5=A0 >>>>>>>=20 >>>>>>> General comment. At the end of the day, SCIM is just an HTTP >>>>>>> protocol >>>>>> (an application) and as such can use any of the normal HTTP >>>>>> mechanisms. In >>>>>> OAuth terms it is just a resource server. I wonder what we can point= >>>>>> to as >>>>>> a general best practice for authentication and authorization. >>>>>=20 >>>>> Yes, the issue I hit was that the text of this draft said that OAuth >>>>> is the >>>>> authentication protocol, when it's only an authorization protocol. As= >>>>> such, a reader might jump to a conclusion that HTTP Basic is the way >>>>> to go >>>>> since it's the first method (and default) for OAuth in the OAuth 2.0 >>>>> framework. Recent drafts that mention the same registry where the >>>>> supported authentication protocols from the client to the AS have not >>>>> updated that short list. If you could rewrite the text to specify >>>>> recommended authentication types, that would be good. >>>>>=20 >>>>> See section 2.3 of https://tools.ietf.org/html/rfc6749 >>>>> and the 3 methods defined are stated again in the dyn registry draft( >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically >>>>> saying to authenticate to use a token, these methods are available: >>>>>=20 >>>>> token_endpoint_auth_method >>>>> String indicator of the requested authentication method for the >>>>> token endpoint. Values defined by this specification are: >>>>>=20 >>>>> * "none": The client is a public client as defined in OAuth 2.0 >>>>> and does not have a client secret. >>>>> * "client_secret_post": The client uses the HTTP POST parameters >>>>> defined in OAuth 2.0 section 2.3.1. >>>>> * "client_secret_basic": the client uses HTTP Basic defined in >>>>> OAuth 2.0 section 2.3.1 >>>>>=20 >>>>> Additional values can be defined via the IANA OAuth Token Endpoint >>>>> Authentication Methods Registry established in Section 4.2. >>>>> Absolute URIs can also be used as values for this parameter >>>>> without being registered. If unspecified or omitted, the default >>>>> is "client_secret_basic", denoting HTTP Basic Authentication >>>>> Scheme as specified in Section 2.3.1 of OAuth 2.0. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> The use of OAuth was in part, a reflection of the growing popularity= >>>>>>> of >>>>>> OAuth at the time of writing, and I believe a conscious attempt by th= e >>>>>> original authors to discourage the use of simple password >>>>>> authentication >>>>>> such as RFC2617=C2=B9s basic authentication. For this reason we did n= ot >>>>>> want to >>>>>> use Basic in the examples. >>>>>=20 >>>>> It's specified as the default in OAuth 2.0 when using a token. see >>>>> above >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Fri May 8 23:06:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177671A9151 for ; Fri, 8 May 2015 23:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOpJ0l6q4jrU for ; Fri, 8 May 2015 23:06:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F71A914B for ; Fri, 8 May 2015 23:06:46 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4966i6x006068 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 9 May 2015 06:06:45 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4966ij2027337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 9 May 2015 06:06:44 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4966iQh002939 for ; Sat, 9 May 2015 06:06:44 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 May 2015 23:06:43 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_94F27A45-DAF4-471C-BD06-DB6957C7ECA2" Message-Id: <843919DD-2809-4E8A-8682-BF9867802185@oracle.com> Date: Fri, 8 May 2015 23:06:42 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [scim] Changes regarding error in 7.5.2 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 06:06:48 -0000 --Apple-Mail=_94F27A45-DAF4-471C-BD06-DB6957C7ECA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It was pointed out that the error response shown in section 7.5.2 is = inconsistent with the other SCIM error response and the schema.=20 The section 7.5.2 error is a forbidden response that is returned when = the client attempts to use a GET filter parameter that contains = sensitive information (that should not be processed). I propose to correct the error response and the error type to conform to = the other =E2=80=9CscimType=E2=80=9D errors as follows: Adding the sensitive error to the scimType table: | sensitive | The specified request cannot | GET (Section | | | be completed due to passing | 3.4.2). | | | of sensitive (e.g., | | | | personal) information in a | | | | request URI. For example, | | | | personal information SHALL | | | | NOT be transmitted over | | | | request URIs. See Section | | | | 7.5.2. | | +--------------+------------------------------+---------------------+ And sec 7.5.2 (basically only the example JSON is changed and the error = type)... 7.5.2. Disclosure of Sensitive Information in URIs As mentioned in Section 9.4 [RFC7231], SCIM clients requesting information using query filters using HTTP GET SHOULD give consideration to the information content of the filters and whether their exposure in a URI would represent a breach of security or confidentiality through leakage in a web browsers or server logs. This is particularly true for information that is legally considered "personally identifiable information" or is otherwise restricted by privacy laws. In these situations to ensure maximum security and confidentiality, clients SHOULD query using HTTP POST (see Section 3.4.3 ). Servers that receive HTTP GET requests using filters that contain sensitive or confidential personal information SHOULD respond with HTTP status 403 indicating the operation is FORBIDDEN. A "scimType" error of "sensitive" may be returned indicating the request must be submitted using POST. A non-normative example: HTTP/1.1 403 FORBIDDEN { "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "detail": "Query filter involving 'name' is restricted or confidential", "scimType": "sensitive", "status": "404" } Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_94F27A45-DAF4-471C-BD06-DB6957C7ECA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It was pointed out that the error response shown in section = 7.5.2 is inconsistent with the other SCIM error response and the = schema. 

The = section 7.5.2 error is a forbidden response that is returned when the = client attempts to use a GET filter parameter that contains sensitive = information (that should not be processed).

I propose to correct the error response = and the error type to conform to the other =E2=80=9CscimType=E2=80=9D = errors as follows:

Adding the sensitive error to the scimType = table:

   | =
sensitive    | The specified request cannot | GET (Section        |
   |              | be completed due to passing  | 3.4.2).             |
   |              | of sensitive (e.g.,          |                     |
   |              | personal) information in a   |                     |
   |              | request URI. For example,    |                     |
   |              | personal information SHALL   |                     |
   |              | NOT be transmitted over      |                     |
   |              | request URIs. See Section    |                     |
   |              | 7.5.2.                       |                     |
   =
+--------------+------------------------------+---------------------+

And sec 7.5.2 =
(basically only the example JSON is changed and the error =
type)...
7.5.2.  Disclosure of Sensitive =
Information in URIs

   As mentioned in Section 9.4 [RFC7231], SCIM clients requesting
   information using query filters using HTTP GET SHOULD give
   consideration to the information content of the filters and whether
   their exposure in a URI would represent a breach of security or
   confidentiality through leakage in a web browsers or server logs.
   This is particularly true for information that is legally considered
   "personally identifiable information" or is otherwise restricted by
   privacy laws.  In these situations to ensure maximum security and
   confidentiality, clients SHOULD query using HTTP POST (see
   Section 3.4.3 ).

   Servers that receive HTTP GET requests using filters that contain
   sensitive or confidential personal information SHOULD respond with
   HTTP status 403 indicating the operation is FORBIDDEN.  A "scimType"
   error of "sensitive" may be returned indicating the request must be
   submitted using POST.  A non-normative example:


  HTTP/1.1 403 FORBIDDEN

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "detail":
          "Query filter involving 'name' is restricted or confidential",
    "scimType": "sensitive",
    "status": "404"
  }


= --Apple-Mail=_94F27A45-DAF4-471C-BD06-DB6957C7ECA2-- From nobody Sat May 9 09:15:08 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690C61A037D; Sat, 9 May 2015 09:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0eCJdI2r0Cm; Sat, 9 May 2015 09:15:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429A1A0366; Sat, 9 May 2015 09:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150509161503.10292.99560.idtracker@ietfa.amsl.com> Date: Sat, 09 May 2015 09:15:03 -0700 Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org, scim@ietf.org Subject: [scim] Joel Jaeggli's No Objection on draft-ietf-scim-api-17: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 16:15:04 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-scim-api-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- " o Limit the number of requests any particular client MAY make in a period of time." Great so we going to limit the extent to which an attacker can spam the the thing. that sounds comforting. " These recommendations include but are not limited to: o Provide injection attack counter measures (e.g., by validating all inputs and parameters), o No cleartext storage of credentials, o Store credentials using an encrypted protection mechanism, and " I don鈥檛 really think of that as being a recommendation so much as a requirement . if you鈥檙e storing clear text passwords somebody needs to take away all your toys. From nobody Mon May 11 07:32:13 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D78E1A8971; Mon, 11 May 2015 07:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clW92Ygc6Rja; Mon, 11 May 2015 07:32:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DEF1A8928; Mon, 11 May 2015 07:32:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 07:32:08 -0700 Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, scim-chairs@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org Subject: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-18: (with DISCUSS) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:32:10 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-scim-core-schema-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. I do have a few items to discuss, but think they should be fairly easy to resolve. 1. Thanks for addressing the SecDir review and agreeing to put some text in about the clear text passwords and the difference between a hashed version. I'll remove the discuss on this once the updated draft is posted. https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html 2. I see the discussion from the SecDir review changes "MAY" to "may' in section 9, but I'm wondering why the word may is used as many of the attributes are PII. How about: "defines attributes that are sensitive and the contents are considered personally identifiable information(PII)" I have some more questions on PII and a suggestion to help resolve the concerns. 3. Is there a reason why the considerations are limited to/with an emphasis on the id and externalId? Most of the attributes defined in section 4 are considered PII. The id and externalID provide an index and that's important to protect, but so are many of the (optional) attributes. It would be good to make this clear in the draft. Since it is pointed out on id, it seems like the other attributes don't have privacy considerations when reading the draft, but a summary statement at the start of the draft would help where the index "id" is distinguished from the other sensitive attributes. 4. It would help to have a statement that lists the scope of where SCIM is used and that the protocol design requires encryption when this data is in transit (per the api draft), since most of the attributes defined would contain PII when used. I'm making some assumptions, so please correct the text to the scope of SCIM. The abstract has the following sentence: "This schema is intended for exchange and use with cloud service providers." What about the following: "This schema is intended for exchange and use with cloud service providers and their customers." There is also this statement int he introduction: "This schema is intended for exchange and use with cloud service providers and other cross-domain scenarios." Is it also used between service providers? If so, permission to provide customers user information between service providers gets tricky and I don't think that was covered in the API draft, but please let me know if I missed it. If data exchanged using the SCIM schema is just between an organization and a contracted service provider, there should be SLAs for security and that could be noted in the introduction with the scope statement. This will alleviate some of the privacy and security concerns as you can state the concerns, but leave it up to implementers and contracts to handle the details. If the scope statement changes, something along the lines of the following could help: "Security service level agreements for the handling of these attributes are outside the scope of this document, but are to be carefully considered by implementers." From nobody Mon May 11 08:31:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD58A1A9047 for ; Mon, 11 May 2015 08:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42w1nhAX9msH for ; Mon, 11 May 2015 08:31:17 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EEE1A904F for ; Mon, 11 May 2015 08:31:15 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so96584937lbb.3 for ; Mon, 11 May 2015 08:31:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OytnJzRqFgd79K5X3RY/0V5lqLEN9sq+OFlc/oFOT/o=; b=BA9kTZc3B+JtYbor+QBxRXH2PU5wJBItl9xV/bOMGWXkkXAwUE7ahIXreJq1AkGRH6 P5CruCYdoGlNAkLUNoJVY01M2CnFjmn0p8zr8oxK6ioxPLNXpFeZB7WBpt6rTsM96/Qh dAKaU36KCLRtjsoYJrBUo99A3D/uM2iKO4R0kWQZqw+47JxscyNjWXBDeGSyDlxevRfU /lUx4kZvXzGTefFzHxqcg5lU1K0KNcRRrlgN5hbvh93aj9IMkIDlhFTVTHotEBwHBHBC 4nZakoDjSbLqzIAHkElpX/cUHG5WmD0UHMT/Var3MEUlfcIKs4Vl9qOTUKMd3XVoWQrK n80Q== X-Gm-Message-State: ALoCoQmOif7/1Vw/Jf7y/aKcNsfgrLCLrVXGVCDqqqLS+AVD9c92Rk4mBsmE2wXyvNdyKQlp4xj5 X-Received: by 10.153.6.36 with SMTP id cr4mr8718656lad.56.1431358273695; Mon, 11 May 2015 08:31:13 -0700 (PDT) Received: from [109.105.104.160] (dhcp26.se-tug.nordu.net. [109.105.104.160]) by mx.google.com with ESMTPSA id ra7sm3115882lbb.27.2015.05.11.08.31.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 08:31:13 -0700 (PDT) Message-ID: <5550CB40.6000701@mnt.se> Date: Mon, 11 May 2015 17:31:12 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: scim@ietf.org References: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> In-Reply-To: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-18: (with DISCUSS) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:31:20 -0000 On 05/11/2015 04:32 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-scim-core-schema-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. I do have a few items to discuss, > but think they should be fairly easy to resolve. > > 1. Thanks for addressing the SecDir review and agreeing to put some text > in about the clear text passwords and the difference between a hashed > version. I'll remove the discuss on this once the updated draft is > posted. > https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html > > 2. I see the discussion from the SecDir review changes "MAY" to "may' in > section 9, but I'm wondering why the word may is used as many of the > attributes are PII. How about: > > "defines attributes that are sensitive and the contents are considered > personally identifiable information(PII)" I would vote to keep the 'may' in there because of the legal implications of the term "personally identifiable information" esp in some jurisdictions - I would prefer to avoid making statements that could be confused with legal advise :-) > > I have some more questions on PII and a suggestion to help resolve the > concerns. > > 3. Is there a reason why the considerations are limited to/with an > emphasis on the id and externalId? Most of the attributes defined in > section 4 are considered PII. The id and externalID provide an index and > that's important to protect, but so are many of the (optional) > attributes. It would be good to make this clear in the draft. Since it > is pointed out on id, it seems like the other attributes don't have > privacy considerations when reading the draft, but a summary statement at > the start of the draft would help where the index "id" is distinguished > from the other sensitive attributes. Here I actually agree. Maybe extend the original caveat on PII to almost everything in scim? From nobody Mon May 11 16:57:21 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871551B2A68; Mon, 11 May 2015 16:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGO7rOFqo3gI; Mon, 11 May 2015 16:57:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F051B2A67; Mon, 11 May 2015 16:57:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511235717.27353.69056.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 16:57:17 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-18.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:57:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-api-18.txt Pages : 89 Date : 2015-05-11 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized service. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-api-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 16:58:47 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFB1B2A70; Mon, 11 May 2015 16:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOKyCvBGvgG6; Mon, 11 May 2015 16:58:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0DD1B2A67; Mon, 11 May 2015 16:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511235844.27068.70010.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 16:58:44 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-19.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:58:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Phil Hunt Kelly Grizzle Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-19.txt Pages : 93 Date : 2015-05-11 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-core-schema-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 17:45:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EBB1B2ADF; Mon, 11 May 2015 17:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klP9TzlJKrUj; Mon, 11 May 2015 17:45:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A371A1BE7; Mon, 11 May 2015 17:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 17:45:39 -0700 Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, scim-chairs@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org Subject: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:45:40 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-scim-core-schema-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft and the updates that took care of most of the items I wanted to discuss. There is just one left and maybe an email response will clear up the scope of SCIM for me. I'm not entirely clear on how data might pass between service providers on behalf of a customer, or if this is just between an customer and a service provider. The latter doesn't have to worry about some security considerations of the former, so it would be good to know how the scope is limited. 4. It would help to have a statement that lists the scope of where SCIM is used and that the protocol design requires encryption when this data is in transit (per the api draft), since most of the attributes defined would contain PII when used. I'm making some assumptions, so please correct the text to the scope of SCIM. The abstract has the following sentence: "This schema is intended for exchange and use with cloud service providers." What about the following: "This schema is intended for exchange and use with cloud service providers and their customers." There is also this statement int he introduction: "This schema is intended for exchange and use with cloud service providers and other cross-domain scenarios." Is it also used between service providers? If so, permission to provide customers user information between service providers gets tricky and I don't think that was covered in the API draft, but please let me know if I missed it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the SecDir review adding text on clear text/hashed passwords and best practices (to avoid storing clear text, etc.). https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html Thanks for the additional privacy considerations, pointing out that most of the data that could be sent using the SCIM schema could be sensitive in addition to the id and externalId. Thanks for the additional text to out-of-scope some of the security controls that are really in the hands of implementers and may be specified through security SLAs or contracts. From nobody Mon May 11 17:52:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A71B2AE2; Mon, 11 May 2015 17:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9yQPrjmhTD4; Mon, 11 May 2015 17:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD281B2AE9; Mon, 11 May 2015 17:52:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512005217.19612.53024.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 17:52:17 -0700 Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org, scim@ietf.org Subject: [scim] Kathleen Moriarty's Yes on draft-ietf-scim-api-18: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:52:18 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-scim-api-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your work on this draft as I do think the work is important. Thank you also for working with me to resolve discusses on security and privacy concerns with the authentication and authorization protocols that may be used with SCIM. The added text on http authentication methods and security problems with OAuth bearer tokens will be very helpful to implementers and customers evaluating/negotiating security services of their service providers for provisioning. From nobody Tue May 12 11:13:54 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DE1ACE39; Tue, 12 May 2015 11:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHwEEGkXkuQw; Tue, 12 May 2015 11:13:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE931ACE31; Tue, 12 May 2015 11:13:49 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4CIDkiC002754 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 May 2015 18:13:47 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4CIDk2x031938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2015 18:13:46 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4CIDkro016422; Tue, 12 May 2015 18:13:46 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 May 2015 11:13:45 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_50CD0E1F-DA7F-4EC4-93B2-9593359A9050" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 11:13:43 -0700 Message-Id: <6F58B233-B103-4F85-A3AF-157809E3EB24@oracle.com> References: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-18: (with DISCUSS) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:13:53 -0000 --Apple-Mail=_50CD0E1F-DA7F-4EC4-93B2-9593359A9050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, Thanks for your review. I=E2=80=99ve put quite a few comments below.=20 I think we may have a different interpretation of the term =E2=80=9CPII=E2= =80=9D. I do not believe that all SCIM information constitutes PII = (personally identifiable information). My interpretation is that usually = a PII =E2=80=9Cattribute=E2=80=9D can, by itself, be used to identify an = individual. A Social Security Number, an email address are all PII. = While eye color and address may not. While many people have =E2=80=9Cblue=E2= =80=9D eyes, that information alone does not point to an individual. = Yet, it has been shown that a surprisingly limited combination of = sensitive information can be used together to identify individuals. = There is already significant research into the area of = re-identification. This merely underlines the need for protection of = sensitive information and not just PII. My understanding is that the = determination of PII largely depends on the legal jurisdiction and what = requirements are set out.=20 Would it be best to first define what is meant by PII and sensitive = information? In the spec, PII is a specific sub-set of personal = information for which we are calling for specific concerns. Phil phil.hunt@yahoo.com > On May 11, 2015, at 7:32 AM, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-scim-core-schema-18: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft. I do have a few items to discuss, > but think they should be fairly easy to resolve. >=20 > 1. Thanks for addressing the SecDir review and agreeing to put some = text > in about the clear text passwords and the difference between a hashed > version. I'll remove the discuss on this once the updated draft is > posted. > https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html Thanks >=20 > 2. I see the discussion from the SecDir review changes "MAY" to "may' = in > section 9, but I'm wondering why the word may is used as many of the > attributes are PII. How about: >=20 > "defines attributes that are sensitive and the contents are = considered > personally identifiable information(PII)=E2=80=9D (see above) Let me know if this text (slightly different from draft 18 works: The SCIM Core schema defines attributes that are sensitive and may be considered personally identifying information (PII). These privacy considerations should be considered for extensions as well as the schema defined in this specification. >=20 > I have some more questions on PII and a suggestion to help resolve the > concerns. >=20 > 3. Is there a reason why the considerations are limited to/with an > emphasis on the id and externalId? Most of the attributes defined in > section 4 are considered PII. The id and externalID provide an index = and > that's important to protect, but so are many of the (optional) > attributes. It would be good to make this clear in the draft. Since = it > is pointed out on id, it seems like the other attributes don't have > privacy considerations when reading the draft, but a summary statement = at > the start of the draft would help where the index "id" is = distinguished > from the other sensitive attributes. I=E2=80=99m not sure I understand. We called particular attention to = =E2=80=9Cid=E2=80=9D and =E2=80=9CexternalId=E2=80=9D because their were = protocol specific concerns. While the draft calls out particular = concerns for =E2=80=9Cid=E2=80=9D and =E2=80=9CexternalId=E2=80=9D, the = intent is not to diminish the concern for other sensitive attributes. The second paragraph reads=E2=80=A6. Attributes such as "id" and "externalId" are of particular concern as personally identifiable information that uniquely map to Users (because they are URIs). ... >=20 > 4. It would help to have a statement that lists the scope of where = SCIM > is used and that the protocol design requires encryption when this = data > is in transit (per the api draft), since most of the attributes = defined > would contain PII when used. =20 Again. I would draw a distinction between PII and Personally Sensitive = Information. We=E2=80=99re assuming all information is sensitive and is critical. The initial driving case was enterprises purchasing services for their = employees from cloud service providers need a standardized way to = initialize those profiles. Since then, we are hearing usage like mobile apps obtaining User profile = information from service providers. E.g. The mobile app downloads the = user profile that was set up using the browser version of an application = (e.g. conferencing system). I am also hearing about cloud-to-cloud where a user (and/or their = employer) would like to access services from another cloud provider or = partner. The initial cloud provider sets up accounts on request on the = users behalf. Some of this may be done by corporate agreement, or = through delegated authorizations such as issued by an OAuth = authorization server as agreed to by the user. We are also seeing broad interest in SCIM as a Profile service =E2=80=94 = essentially this generations HTTP Directory Service. The pairing of SCIM = and OAuth gives new user control over their information and its = propagation. (this is beyond the current charter) There is also an emerging use of SCIM for managing identities for OAuth = Clients and things. In particular a lot of work is being done on IoT. = What makes this interesting, is that some of this are just device = identities, but they still carry risk from a network security = perspective. We also then have the fact that many devices are also = tightly associated with Users, either because they possess them or = because they are delegating rights to the devices. I=E2=80=99ve said all this, because I=E2=80=99m not sure we need to = specify any of this. To specify a scope suggests we want to specifically = limit use. I=E2=80=99m not sure that is appropriate. >=20 > I'm making some assumptions, so please correct the text to the scope = of > SCIM. The abstract has the following sentence: > "This schema is intended for exchange and use with cloud > service providers." > What about the following: > "This schema is intended for exchange and use with cloud > service providers and their customers.=E2=80=9D The sentence was vague because the charter included both = enterprise-to-cloud and cloud-to-cloud. >=20 > There is also this statement int he introduction: > "This schema is intended for exchange and use with > cloud service providers and other cross-domain scenarios." >=20 > Is it also used between service providers? If so, permission to = provide > customers user information between service providers gets tricky and I > don't think that was covered in the API draft, but please let me know = if > I missed it. We did not discuss permission systems. SCIM was chartered as a = provisioning protocol. This might be appropriate if we want to discuss a = SCIM Directory charter down the road. >=20 > If data exchanged using the SCIM schema is just between an = organization > and a contracted service provider, there should be SLAs for security = and > that could be noted in the introduction with the scope statement. = This > will alleviate some of the privacy and security concerns as you can = state > the concerns, but leave it up to implementers and contracts to handle = the > details. If the scope statement changes, something along the lines of > the following could help: > "Security service level agreements for the handling of these > attributes are outside the scope of this document, but are to > be carefully considered by implementers.=E2=80=9D Agreed. I=E2=80=99m happy to put this in. Editorially, I am concerned = about including too much material that doesn=E2=80=99t specify actions = implementers should do. =20 >=20 >=20 >=20 >=20 Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_50CD0E1F-DA7F-4EC4-93B2-9593359A9050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

Thanks for your = review. I=E2=80=99ve put quite a few comments below.

I think we may have a different interpretation of the term = =E2=80=9CPII=E2=80=9D. I do not believe that all SCIM information = constitutes PII (personally identifiable information). My interpretation = is that usually a PII =E2=80=9Cattribute=E2=80=9D can, by itself, be = used to identify an individual. A Social Security Number, an email = address are all PII.  While eye color and address may not. While = many people have =E2=80=9Cblue=E2=80=9D eyes, that information alone = does not point to an individual. Yet, it has been shown that a = surprisingly limited combination of sensitive information can be used = together to identify individuals. There is already significant research = into the area of re-identification. This merely underlines the need for = protection of sensitive information and not just PII.  My = understanding is that the determination of PII largely depends on the = legal jurisdiction and what requirements are set out.

Would it be best to first define what is meant by PII and = sensitive information?  In the spec, PII is a specific sub-set of = personal information for which we are calling for specific concerns.

Phil

phil.hunt@yahoo.com

On May = 11, 2015, at 7:32 AM, Kathleen Moriarty = <Kathleen.Moriarty.ietf@gmail.com> wrote:

Kathleen Moriarty has entered the following ballot position = for
draft-ietf-scim-core-schema-18: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for your work on this draft. =  I do have a few items to discuss,
but think they = should be fairly easy to resolve.

1. Thanks = for addressing the SecDir review and agreeing to put some text
in about the clear text passwords and the difference between = a hashed
version.  I'll remove the discuss on this = once the updated draft is
posted.
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.h= tml

Thanks

2. I see = the discussion from the SecDir review changes "MAY" to "may' in
section 9, but I'm wondering why the word may is used as many = of the
attributes are PII.  How about:

"defines attributes that are = sensitive and the contents are considered
personally = identifiable information(PII)=E2=80=9D

(see above)

Let me know if this = text (slightly different from draft 18 works:

  The SCIM Core schema defines attributes that are = sensitive and may be
  considered personally = identifying information (PII).  These privacy
=   considerations should be considered for extensions as well = as the
  schema defined in this = specification.



I have some more questions on = PII and a suggestion to help resolve the
concerns.

3. Is there a reason why the considerations = are limited to/with an
emphasis on the id and externalId? =  Most of the attributes defined in
section 4 are = considered PII.  The id and externalID provide an index and
that's important to protect, but so are many of the = (optional)
attributes.  It would be good to make this = clear in the draft.  Since it
is pointed out on id, = it seems like the other attributes don't have
privacy = considerations when reading the draft, but a summary statement at
the start of the draft would help where the index "id" is = distinguished
from the other sensitive attributes.

I=E2=80=99m not sure I = understand. We called particular attention to =E2=80=9Cid=E2=80=9D and = =E2=80=9CexternalId=E2=80=9D because their were protocol specific = concerns. While the draft calls out particular concerns for =E2=80=9Cid=E2= =80=9D and =E2=80=9CexternalId=E2=80=9D, the intent is not to diminish = the concern for other sensitive attributes.

The second paragraph reads=E2=80=A6.
=   Attributes such as "id" and "externalId" are of particular = concern as
  personally identifiable = information that uniquely map to Users
=   (because they are URIs).  ...


4. It = would help to have a statement that lists the scope of where SCIM
is used and that the protocol design requires encryption when = this data
is in transit (per the api draft), since most of = the attributes defined
would contain PII when used. =  

Again. I would draw a = distinction between PII and Personally Sensitive Information.

We=E2=80=99re assuming all information is = sensitive and is critical.

The initial = driving case was enterprises purchasing services for their employees = from cloud service providers need a standardized way to initialize those = profiles.

Since then, we are hearing usage = like mobile apps obtaining User profile information from service = providers.  E.g. The mobile app downloads the user profile that was = set up using the browser version of an application (e.g. conferencing = system).

I am also hearing about = cloud-to-cloud where a user (and/or their employer) would like to access = services from another cloud provider or partner. The initial cloud = provider sets up accounts on request on the users behalf.  Some of = this may be done by corporate agreement, or through delegated = authorizations such as issued by an OAuth authorization server as agreed = to by the user.

We are also seeing broad = interest in SCIM as a Profile service =E2=80=94 essentially this = generations HTTP Directory Service. The pairing of SCIM and OAuth gives = new user control over their information and its propagation. (this is = beyond the current charter)

There is also = an emerging use of SCIM for managing identities for OAuth Clients and = things.  In particular a lot of work is being done on IoT. What = makes this interesting, is that some of this are just device identities, = but they still carry risk from a network security perspective. We also = then have the fact that many devices are also tightly associated with = Users, either because they possess them or because they are delegating = rights to the devices.

I=E2=80=99ve said = all this, because I=E2=80=99m not sure we need to specify any of this. = To specify a scope suggests we want to specifically limit use. I=E2=80=99m= not sure that is appropriate.


I'm making some assumptions, so = please correct the text to the scope of
SCIM.  The = abstract has the following sentence:
 "This schema = is intended for exchange and use with cloud
 service = providers."
What about the following:
=  "This schema is intended for exchange and use with cloud
 service providers and their customers.=E2=80=9D

The sentence was vague because = the charter included both enterprise-to-cloud and cloud-to-cloud.

There is = also this statement int he introduction:
 "This = schema is intended for exchange and use with
 cloud = service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, = permission to provide
customers user information between = service providers gets tricky and I
don't think that was = covered in the API draft, but please let me know if
I = missed it.

We did not discuss = permission systems. SCIM was chartered as a provisioning protocol. This = might be appropriate if we want to discuss a SCIM Directory charter down = the road.

If data exchanged using the SCIM schema is just between an = organization
and a contracted service provider, there = should be SLAs for security and
that could be noted in the = introduction with the scope statement.  This
will = alleviate some of the privacy and security concerns as you can state
the concerns, but leave it up to implementers and contracts = to handle the
details.  If the scope statement = changes, something along the lines of
the following could = help:
  "Security service level agreements for = the handling of these
  attributes are outside = the scope of this document, but are to
  be = carefully considered by implementers.=E2=80=9D

Agreed. I=E2=80=99m happy to put = this in. Editorially, I am concerned about including too much material = that doesn=E2=80=99t specify actions implementers should do.  






Phil

@independentid
www.independentid.com
phil.hunt@o= racle.com

= --Apple-Mail=_50CD0E1F-DA7F-4EC4-93B2-9593359A9050-- From nobody Tue May 12 11:15:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256991ACE2B; Tue, 12 May 2015 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCKmJIil8bA0; Tue, 12 May 2015 11:15:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B341ACE16; Tue, 12 May 2015 11:15:30 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4CIFR4G005540 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 May 2015 18:15:27 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4CIFRWF006227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2015 18:15:27 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4CIFQJ5017334; Tue, 12 May 2015 18:15:26 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 May 2015 11:15:25 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_265303A1-C338-433F-85B9-92BB0C868F6A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <6F58B233-B103-4F85-A3AF-157809E3EB24@oracle.com> Date: Tue, 12 May 2015 11:15:24 -0700 Message-Id: References: <20150511143208.9466.1219.idtracker@ietfa.amsl.com> <6F58B233-B103-4F85-A3AF-157809E3EB24@oracle.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-18: (with DISCUSS) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:15:34 -0000 --Apple-Mail=_265303A1-C338-433F-85B9-92BB0C868F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please ignore this last message. It appears to be an old draft message. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 12, 2015, at 11:13 AM, Phil Hunt wrote: >=20 > Kathleen, >=20 > Thanks for your review. I=E2=80=99ve put quite a few comments below.=20= >=20 > I think we may have a different interpretation of the term =E2=80=9CPII=E2= =80=9D. I do not believe that all SCIM information constitutes PII = (personally identifiable information). My interpretation is that usually = a PII =E2=80=9Cattribute=E2=80=9D can, by itself, be used to identify an = individual. A Social Security Number, an email address are all PII. = While eye color and address may not. While many people have =E2=80=9Cblue=E2= =80=9D eyes, that information alone does not point to an individual. = Yet, it has been shown that a surprisingly limited combination of = sensitive information can be used together to identify individuals. = There is already significant research into the area of = re-identification. This merely underlines the need for protection of = sensitive information and not just PII. My understanding is that the = determination of PII largely depends on the legal jurisdiction and what = requirements are set out.=20 >=20 > Would it be best to first define what is meant by PII and sensitive = information? In the spec, PII is a specific sub-set of personal = information for which we are calling for specific concerns. >=20 > Phil >=20 > phil.hunt@yahoo.com >=20 >> On May 11, 2015, at 7:32 AM, Kathleen Moriarty = wrote: >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-scim-core-schema-18: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for your work on this draft. I do have a few items to = discuss, >> but think they should be fairly easy to resolve. >>=20 >> 1. Thanks for addressing the SecDir review and agreeing to put some = text >> in about the clear text passwords and the difference between a hashed >> version. I'll remove the discuss on this once the updated draft is >> posted. >> https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html >=20 > Thanks >>=20 >> 2. I see the discussion from the SecDir review changes "MAY" to "may' = in >> section 9, but I'm wondering why the word may is used as many of the >> attributes are PII. How about: >>=20 >> "defines attributes that are sensitive and the contents are = considered >> personally identifiable information(PII)=E2=80=9D >=20 > (see above) >=20 > Let me know if this text (slightly different from draft 18 works: >=20 > The SCIM Core schema defines attributes that are sensitive and may = be > considered personally identifying information (PII). These privacy > considerations should be considered for extensions as well as the > schema defined in this specification. >=20 >=20 >>=20 >> I have some more questions on PII and a suggestion to help resolve = the >> concerns. >>=20 >> 3. Is there a reason why the considerations are limited to/with an >> emphasis on the id and externalId? Most of the attributes defined in >> section 4 are considered PII. The id and externalID provide an index = and >> that's important to protect, but so are many of the (optional) >> attributes. It would be good to make this clear in the draft. Since = it >> is pointed out on id, it seems like the other attributes don't have >> privacy considerations when reading the draft, but a summary = statement at >> the start of the draft would help where the index "id" is = distinguished >> from the other sensitive attributes. >=20 > I=E2=80=99m not sure I understand. We called particular attention to = =E2=80=9Cid=E2=80=9D and =E2=80=9CexternalId=E2=80=9D because their were = protocol specific concerns. While the draft calls out particular = concerns for =E2=80=9Cid=E2=80=9D and =E2=80=9CexternalId=E2=80=9D, the = intent is not to diminish the concern for other sensitive attributes. >=20 > The second paragraph reads=E2=80=A6. > Attributes such as "id" and "externalId" are of particular concern = as > personally identifiable information that uniquely map to Users > (because they are URIs). ... >=20 >>=20 >> 4. It would help to have a statement that lists the scope of where = SCIM >> is used and that the protocol design requires encryption when this = data >> is in transit (per the api draft), since most of the attributes = defined >> would contain PII when used. =20 >=20 > Again. I would draw a distinction between PII and Personally Sensitive = Information. >=20 > We=E2=80=99re assuming all information is sensitive and is critical. >=20 > The initial driving case was enterprises purchasing services for their = employees from cloud service providers need a standardized way to = initialize those profiles. >=20 > Since then, we are hearing usage like mobile apps obtaining User = profile information from service providers. E.g. The mobile app = downloads the user profile that was set up using the browser version of = an application (e.g. conferencing system). >=20 > I am also hearing about cloud-to-cloud where a user (and/or their = employer) would like to access services from another cloud provider or = partner. The initial cloud provider sets up accounts on request on the = users behalf. Some of this may be done by corporate agreement, or = through delegated authorizations such as issued by an OAuth = authorization server as agreed to by the user. >=20 > We are also seeing broad interest in SCIM as a Profile service =E2=80=94= essentially this generations HTTP Directory Service. The pairing of = SCIM and OAuth gives new user control over their information and its = propagation. (this is beyond the current charter) >=20 > There is also an emerging use of SCIM for managing identities for = OAuth Clients and things. In particular a lot of work is being done on = IoT. What makes this interesting, is that some of this are just device = identities, but they still carry risk from a network security = perspective. We also then have the fact that many devices are also = tightly associated with Users, either because they possess them or = because they are delegating rights to the devices. >=20 > I=E2=80=99ve said all this, because I=E2=80=99m not sure we need to = specify any of this. To specify a scope suggests we want to specifically = limit use. I=E2=80=99m not sure that is appropriate. >=20 >>=20 >> I'm making some assumptions, so please correct the text to the scope = of >> SCIM. The abstract has the following sentence: >> "This schema is intended for exchange and use with cloud >> service providers." >> What about the following: >> "This schema is intended for exchange and use with cloud >> service providers and their customers.=E2=80=9D >=20 > The sentence was vague because the charter included both = enterprise-to-cloud and cloud-to-cloud. >>=20 >> There is also this statement int he introduction: >> "This schema is intended for exchange and use with >> cloud service providers and other cross-domain scenarios." >>=20 >> Is it also used between service providers? If so, permission to = provide >> customers user information between service providers gets tricky and = I >> don't think that was covered in the API draft, but please let me know = if >> I missed it. >=20 > We did not discuss permission systems. SCIM was chartered as a = provisioning protocol. This might be appropriate if we want to discuss a = SCIM Directory charter down the road. >>=20 >> If data exchanged using the SCIM schema is just between an = organization >> and a contracted service provider, there should be SLAs for security = and >> that could be noted in the introduction with the scope statement. = This >> will alleviate some of the privacy and security concerns as you can = state >> the concerns, but leave it up to implementers and contracts to handle = the >> details. If the scope statement changes, something along the lines = of >> the following could help: >> "Security service level agreements for the handling of these >> attributes are outside the scope of this document, but are to >> be carefully considered by implementers.=E2=80=9D >=20 > Agreed. I=E2=80=99m happy to put this in. Editorially, I am concerned = about including too much material that doesn=E2=80=99t specify actions = implementers should do. =20 >=20 >>=20 >>=20 >>=20 >>=20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_265303A1-C338-433F-85B9-92BB0C868F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please ignore this last message.  It appears to be an = old draft message.


On May 12, 2015, at 11:13 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Kathleen,

Thanks for your review. I=E2=80=99ve put quite = a few comments below.

I think we may have = a different interpretation of the term =E2=80=9CPII=E2=80=9D. I do not = believe that all SCIM information constitutes PII (personally = identifiable information). My interpretation is that usually a PII = =E2=80=9Cattribute=E2=80=9D can, by itself, be used to identify an = individual. A Social Security Number, an email address are all PII. =  While eye color and address may not. While many people have = =E2=80=9Cblue=E2=80=9D eyes, that information alone does not point to an = individual. Yet, it has been shown that a surprisingly limited = combination of sensitive information can be used together to identify = individuals. There is already significant research into the area of = re-identification. This merely underlines the need for protection of = sensitive information and not just PII.  My understanding is that = the determination of PII largely depends on the legal jurisdiction and = what requirements are set out.

Would it be = best to first define what is meant by PII and sensitive information? =  In the spec, PII is a specific sub-set of personal information for = which we are calling for specific concerns.

Phil

phil.hunt@yahoo.com

On May = 11, 2015, at 7:32 AM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:

Kathleen Moriarty has entered the following = ballot position for
draft-ietf-scim-core-schema-18: = Discuss

When responding, please keep the = subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for your work on this draft. =  I do have a few items to discuss,
but think they = should be fairly easy to resolve.

1. Thanks = for addressing the SecDir review and agreeing to put some text
in about the clear text passwords and the difference between = a hashed
version.  I'll remove the discuss on this = once the updated draft is
posted.
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.h= tml

Thanks

2. I see = the discussion from the SecDir review changes "MAY" to "may' in
section 9, but I'm wondering why the word may is used as many = of the
attributes are PII.  How about:

"defines attributes that are = sensitive and the contents are considered
personally = identifiable information(PII)=E2=80=9D

(see above)

Let me know if this = text (slightly different from draft 18 works:

  The SCIM Core schema defines attributes that are = sensitive and may be
  considered personally = identifying information (PII).  These privacy
=   considerations should be considered for extensions as well = as the
  schema defined in this = specification.



I have some more questions on = PII and a suggestion to help resolve the
concerns.

3. Is there a reason why the considerations = are limited to/with an
emphasis on the id and externalId? =  Most of the attributes defined in
section 4 are = considered PII.  The id and externalID provide an index and
that's important to protect, but so are many of the = (optional)
attributes.  It would be good to make this = clear in the draft.  Since it
is pointed out on id, = it seems like the other attributes don't have
privacy = considerations when reading the draft, but a summary statement at
the start of the draft would help where the index "id" is = distinguished
from the other sensitive attributes.

I=E2=80=99m not sure I = understand. We called particular attention to =E2=80=9Cid=E2=80=9D and = =E2=80=9CexternalId=E2=80=9D because their were protocol specific = concerns. While the draft calls out particular concerns for =E2=80=9Cid=E2= =80=9D and =E2=80=9CexternalId=E2=80=9D, the intent is not to diminish = the concern for other sensitive attributes.

The second paragraph reads=E2=80=A6.
=   Attributes such as "id" and "externalId" are of particular = concern as
  personally identifiable = information that uniquely map to Users
=   (because they are URIs).  ...


4. It = would help to have a statement that lists the scope of where SCIM
is used and that the protocol design requires encryption when = this data
is in transit (per the api draft), since most of = the attributes defined
would contain PII when used. =  

Again. I would draw a = distinction between PII and Personally Sensitive Information.

We=E2=80=99re assuming all information is = sensitive and is critical.

The initial = driving case was enterprises purchasing services for their employees = from cloud service providers need a standardized way to initialize those = profiles.

Since then, we are hearing usage = like mobile apps obtaining User profile information from service = providers.  E.g. The mobile app downloads the user profile that was = set up using the browser version of an application (e.g. conferencing = system).

I am also hearing about = cloud-to-cloud where a user (and/or their employer) would like to access = services from another cloud provider or partner. The initial cloud = provider sets up accounts on request on the users behalf.  Some of = this may be done by corporate agreement, or through delegated = authorizations such as issued by an OAuth authorization server as agreed = to by the user.

We are also seeing broad = interest in SCIM as a Profile service =E2=80=94 essentially this = generations HTTP Directory Service. The pairing of SCIM and OAuth gives = new user control over their information and its propagation. (this is = beyond the current charter)

There is also = an emerging use of SCIM for managing identities for OAuth Clients and = things.  In particular a lot of work is being done on IoT. What = makes this interesting, is that some of this are just device identities, = but they still carry risk from a network security perspective. We also = then have the fact that many devices are also tightly associated with = Users, either because they possess them or because they are delegating = rights to the devices.

I=E2=80=99ve said = all this, because I=E2=80=99m not sure we need to specify any of this. = To specify a scope suggests we want to specifically limit use. I=E2=80=99m= not sure that is appropriate.


I'm making some assumptions, so = please correct the text to the scope of
SCIM.  The = abstract has the following sentence:
 "This schema = is intended for exchange and use with cloud
 service = providers."
What about the following:
=  "This schema is intended for exchange and use with cloud
 service providers and their customers.=E2=80=9D

The sentence was vague because = the charter included both enterprise-to-cloud and cloud-to-cloud.

There is = also this statement int he introduction:
 "This = schema is intended for exchange and use with
 cloud = service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, = permission to provide
customers user information between = service providers gets tricky and I
don't think that was = covered in the API draft, but please let me know if
I = missed it.

We did not discuss = permission systems. SCIM was chartered as a provisioning protocol. This = might be appropriate if we want to discuss a SCIM Directory charter down = the road.

If data exchanged using the SCIM schema is just between an = organization
and a contracted service provider, there = should be SLAs for security and
that could be noted in the = introduction with the scope statement.  This
will = alleviate some of the privacy and security concerns as you can state
the concerns, but leave it up to implementers and contracts = to handle the
details.  If the scope statement = changes, something along the lines of
the following could = help:
  "Security service level agreements for = the handling of these
  attributes are outside = the scope of this document, but are to
  be = carefully considered by implementers.=E2=80=9D

Agreed. I=E2=80=99m happy to put = this in. Editorially, I am concerned about including too much material = that doesn=E2=80=99t specify actions implementers should do.  







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

= --Apple-Mail=_265303A1-C338-433F-85B9-92BB0C868F6A-- From nobody Tue May 12 11:23:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E4B1B2EEC; Tue, 12 May 2015 11:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWhZIH0VV1oB; Tue, 12 May 2015 11:23:13 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E731B2EEB; Tue, 12 May 2015 11:23:13 -0700 (PDT) Received: by lagv1 with SMTP id v1so12357384lag.3; Tue, 12 May 2015 11:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vC2SpqWJOxfZ68SjU8bZsAZ7Rc1B2N8xifsUuClQIEA=; b=V+WXcGoT4EqZ8hgqV866bPeK+6ifKB9JH7luUdYhwo3L4LfTDdPtV/aL/Nvh1DlAM7 IK2gbN5WHXuJxi+NyFccI00akNITmlYzYQURg9iPW16pPxMFm6zg/PsDazUeUFADF8X4 /j1tXslSKVLfSlWt4RaEeEEqKvTiqVXtzFkoO6w+DKQGSd8MZEqiu260YFWKfnDxkidx pDPC7yinorr1fYa+njHoEOabundALPPTejPzUSRLtiROBIKVnru3OKO31qJK7k9/7ocw GOipibCpaHi4hwQalChJsC8FpJ4r7gufM35jAm/ixcOXdOHaGYErfrue1M5uk9BoQxHj 1g8w== MIME-Version: 1.0 X-Received: by 10.112.97.202 with SMTP id ec10mr2964030lbb.4.1431454991681; Tue, 12 May 2015 11:23:11 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 11:23:11 -0700 (PDT) In-Reply-To: References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 14:23:11 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1133b1c44a8d940515e696bb Archived-At: Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:23:17 -0000 --001a1133b1c44a8d940515e696bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, Thanks for your response. in-line. On Tue, May 12, 2015 at 2:12 PM, Phil Hunt wrote: > Kathleen, > > My understanding of the SCIM WG charter indicates the use cases are > intended to cover both enterprise to cloud provider and cloud-to-cloud > scenarios. Unless I am missing something, I think the latest drafts do > handle the issue appropriately. > > In particular, in the last update, the text put in regarding SLAs and > privacy covers the issues raised regarding the cloud-to-cloud and > enterprise-to-cloud cases: > > From the Core Schema Privacy Section (9.3): > Information should be shared on an as-needed basis. A SCIM client > should limit information to what it believes a service provider > requires, and a SCIM service provider, should only accept information > it needs. Clients and service providers should take into > consideration that personal information is being conveyed across > technical (e.g., protocol and applications), administrative (e.g. > organizational, corporate), and jurisdictional boundaries. In > particular information security and privacy must be considered. > > Security service level agreements for the handling of these > attributes are beyond the scope of this document, but are to be > carefully considered by implementers and deploying organizations. > > Please see the Privacy Considerations section of [ > I-D.ietf-scim-api > ], > for more protocol specific considerations for handling of SCIM > information. > This text is good and helpful, my concern is that it doesn't say anywhere that data could be transferred from a customer, to their service provider, then to another service provider (except with the cross-domain sentence). How does one track where their data went and would that type of scenario be negotiated in contracts or could that happen without the customer's knowledge? > > I also note that while core schema spec doesn=E2=80=99t explicitly call f= or TLS > (since it is a schema spec) it does so implicitly as we call attention to > the protocol spec: > > 9.1. Protocol > > SCIM data is intended to be exchanged using SCIM Protocol. It is > important when handling data to implement the security considerations > outlined in Section 7 of [ > I-D.ietf-scim-api]. > > Section 7.2 of SCIM Protocol indicates TLS 1.2 is required. > TLS 1.2 is already required, so this text is good. > > Would you like stronger, more explicit wording? E.g. regardless of > protocol, the exchange of sensitive information MUST be protected by > encryption such as TLS 1.2 or better? > > Or, be more limited and specifically say TLS 1.2 *and* SCIM Protocol MUST > be used. > > Let me know if you think we need to put any more introductory information > in or explicitly repeat some of the api security requirements. > > Regarding the text suggestions: > > "This schema is intended for exchange and use with cloud > > service providers and their customers." > > > This suggestion is ok with me. > OK, but could it go on to another service provider? That part wasn't clear to me with the cross domain text. Thank you! Kathleen > > Regarding: > > "This schema is intended for exchange and use with > cloud service providers and other cross-domain scenarios.=E2=80=9D > > > I=E2=80=99m thinking the text pasted above does address the concern you r= aise > regarding permissions. > > Does this address your concern? > > Phil > > phil.hunt@yahoo.com > > On May 11, 2015, at 5:45 PM, Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.com> wrote: > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft and the updates that took care of most > of the items I wanted to discuss. There is just one left and maybe an > email response will clear up the scope of SCIM for me. I'm not entirely > clear on how data might pass between service providers on behalf of a > customer, or if this is just between an customer and a service provider. > The latter doesn't have to worry about some security considerations of > the former, so it would be good to know how the scope is limited. > > 4. It would help to have a statement that lists the scope of where SCIM > is used and that the protocol design requires encryption when this data > is in transit (per the api draft), since most of the attributes defined > would contain PII when used. > > I'm making some assumptions, so please correct the text to the scope of > SCIM. The abstract has the following sentence: > "This schema is intended for exchange and use with cloud > service providers." > What about the following: > "This schema is intended for exchange and use with cloud > service providers and their customers." > > There is also this statement int he introduction: > "This schema is intended for exchange and use with > cloud service providers and other cross-domain scenarios." > > Is it also used between service providers? If so, permission to provide > customers user information between service providers gets tricky and I > don't think that was covered in the API draft, but please let me know if > I missed it. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing the SecDir review adding text on clear text/hashed > passwords and best practices (to avoid storing clear text, etc.). > https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html > > Thanks for the additional privacy considerations, pointing out that most > of the data that could be sent using the SCIM schema could be sensitive > in addition to the id and externalId. > > Thanks for the additional text to out-of-scope some of the security > controls that are really in the hands of implementers and may be > specified through security SLAs or contracts. > > > > --=20 Best regards, Kathleen --001a1133b1c44a8d940515e696bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

Thanks for your response. =C2= =A0in-line.

= On Tue, May 12, 2015 at 2:12 PM, Phil Hunt <phil.hunt@yahoo.com><= /span> wrote:
Kathleen,

My understanding of the SCIM WG chart= er indicates the use cases are intended to cover both enterprise to cloud p= rovider and cloud-to-cloud scenarios. Unless I am missing something, I thin= k the latest drafts do handle the issue appropriately.

=
In particular, in the last update, the text put in regarding SLAs and = privacy covers the issues raised regarding the cloud-to-cloud and enterpris= e-to-cloud cases:

From the Core Schema Privacy Sec= tion (9.3):
=C2=A0 =C2=A0Informat= ion should be shared on an as-needed basis.=C2=A0 A SCIM client
=C2=A0 =C2=A0should limit information to w= hat it believes a service provider
=C2=A0 =C2=A0requires, and a SCIM service provider, should only accept = information
=C2=A0 =C2=A0it nee= ds.=C2=A0 Clients and service providers should take into
<= font face=3D"Courier New">=C2=A0 =C2=A0consideration that personal informat= ion is being conveyed across
= =C2=A0 =C2=A0technical (e.g., protocol and applications), administrative (e= .g.
=C2=A0 =C2=A0organizational= , corporate), and jurisdictional boundaries.=C2=A0 In
=C2=A0 =C2=A0particular information security and pri= vacy must be considered.

=C2=A0 =C2=A0Security service le= vel agreements for the handling of these
=C2=A0 =C2=A0attributes are beyond the scope of this document, bu= t are to be
=C2=A0 =C2=A0carefu= lly considered by implementers and deploying organizations.

=C2=A0 =C2=A0Please see the Privacy Considerations section of [I-D.ietf-scim-api
],
=C2=A0 =C2=A0for= more protocol specific considerations for handling of SCIM
=C2=A0 =C2=A0information.

This text is good and helpful, my conc= ern is that it doesn't say anywhere that data could be transferred from= a customer, to their service provider, then to another service provider (e= xcept with the cross-domain sentence).=C2=A0 How does one track where their= data went and would that type of scenario be negotiated in contracts or co= uld that happen without the customer's knowledge?
=C2=A0=C2= =A0

I also note that while core schema spec doesn=E2= =80=99t explicitly call for TLS (since it is a schema spec) it does so impl= icitly as we call attention to the protocol spec:

= 9.1.=C2=A0 Protocol

=C2=A0 =C2=A0SCI= M data is intended to be exchanged using SCIM Protocol.=C2=A0 It is<= /div>
=C2=A0 =C2=A0important when handling d= ata to implement the security considerations
=C2=A0 =C2=A0outlined in Section 7 of [
I-D.ietf-scim-api].

Secti= on 7.2 of SCIM Protocol indicates TLS 1.2 is required. =C2=A0

TLS 1.2 is already required, so this t= ext is good.=C2=A0

Would you like stronger, more expl= icit wording?=C2=A0 E.g. regardless of protocol, the exchange of sensitive = information MUST be protected by encryption such as TLS 1.2 or better?

Or, be more limited and specifically say TLS 1.2 *and*= SCIM Protocol MUST be used.

Let me know if you think w= e need to put any more introductory information in or explicitly repeat som= e of the api security requirements.=C2=A0

Regardin= g the text suggestions:=C2=A0
"This schema is intended for exchange and use with cloud
=C2=A0 service providers and their custo= mers."

This suggestion is ok with me= .=C2=A0

OK, but could it go on = to another service provider?=C2=A0 That part wasn't clear to me with th= e cross domain text.

Thank you!
Kathleen= =C2=A0

Regarding:
=C2=A0 "This schema is intended for exchange and use with
= =C2=A0 cloud service providers and other cross-domain scenarios.=E2=80=9D

I=E2=80=99m thinking the text pasted a= bove does address the concern you raise regarding permissions.
Does this address your concern?=C2=A0


On May 11, 2015, at 5:45 PM, Kathleen Moriarty <Kathleen.Moriarty.= ietf@gmail.com> wrote:


----------------------------------= ------------------------------------
DISCUSS:
-----------------------= -----------------------------------------------

Thanks for your work= on this draft and the updates that took care of most
of the items I wan= ted to discuss.=C2=A0 There is just one left and maybe an
email response= will clear up the scope of SCIM for me.=C2=A0 I'm not entirely
clea= r on how data might pass between service providers on behalf of a
custom= er, or if this is just between an customer and a service provider.=C2=A0The latter doesn't have to worry about some security considerations of=
the former, so it would be good to know how the scope is limited.
4. It would help to have a statement that lists the scope of where SCIMis used and that the protocol design requires encryption when this datais in transit (per the api draft), since most of the attributes definedwould contain PII when used. =C2=A0

I'm making some assumption= s, so please correct the text to the scope of
SCIM.=C2=A0 The abstract h= as the following sentence:
=C2=A0 "This schema is intended for exch= ange and use with cloud
=C2=A0 service providers."
What about th= e following:
=C2=A0 "This schema is intended for exchange and use w= ith cloud
=C2=A0 service providers and their customers."

The= re is also this statement int he introduction:
=C2=A0 "This schema = is intended for exchange and use with
=C2=A0 cloud service providers and= other cross-domain scenarios."

Is it also used between service= providers?=C2=A0 If so, permission to provide
customers user informatio= n between service providers gets tricky and I
don't think that was c= overed in the API draft, but please let me know if
I missed it.

<= br>----------------------------------------------------------------------COMMENT:
-------------------------------------------------------------= ---------

Thanks for addressing the SecDir review adding text on cle= ar text/hashed
passwords and best practices (to avoid storing clear text= , etc.).=C2=A0
https://www.ietf.org/mail-archive/w= eb/secdir/current/msg05678.html

Thanks for the additional privac= y considerations, pointing out that most
of the data that could be sent = using the SCIM schema could be sensitive
in addition to the id and exter= nalId.

Thanks for the additional text to out-of-scope some of the se= curity
controls that are really in the hands of implementers and may be<= br>specified through security SLAs or contracts.




--

Best= regards,
Kathleen
--001a1133b1c44a8d940515e696bb-- From nobody Tue May 12 11:56:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7B1ACE39 for ; Tue, 12 May 2015 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VccYK6023E6F for ; Tue, 12 May 2015 11:12:53 -0700 (PDT) Received: from nm24.bullet.mail.ne1.yahoo.com (nm24.bullet.mail.ne1.yahoo.com [98.138.90.87]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB651ACE3A for ; Tue, 12 May 2015 11:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431454367; bh=0DbKGuoR83wgjTBUG5mEltDTfJm0lQWLO+MPk64zedI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=qZNgkgfhs7qqX7kTbRJu6Qwsp5H7z8s0xlo/lQcfu6kfA+GEx/JvhpsI9JDlafv4PdG1NUzWWih+gu15GP0Vl19bPWjWd5pEcQb0ea4WNX9eFEd6tytRHwodweSonuO0+gQ7vL+QSIwJm37BosZvCr+UODB4j2VSxQII3/PslaneTAgKHtA3YS+Ec9Ja8cIR07IQbUBFkHp9PTBJWB1doP44cMR2bmmk+n0sJ0r+b/g8B563sgHvD9GDOkN/gexwGwk9joWLP+JwCZjOy96S+OmAwjyBD0ef18Kt5F0NBrNdzb4ZyLRF0oE/CO6PWDn+GOU3MP56GWGk1cWrkVGAvg== Received: from [98.138.101.132] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2015 18:12:47 -0000 Received: from [98.138.226.57] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2015 18:12:47 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 12 May 2015 18:12:47 -0000 X-Yahoo-Newman-Id: 587658.99732.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LpMwSSIVM1kd8Et40c5bvNjF5C._eA5lv_9SoDeE0nN1jYG gZiicgtEaOciXqlo8i9ISaljJC8GiY2Y42f1_SWyCgbKoeXfydkli3nxCC.L OwaNdXI4mqhnUkImQKppaboNEoMhmuPMEiltGh97WMgItWY9bi7siCTCL0Ku _kqUIQ2GnDh_4paxWbdc.hb6CM82swgZdFe_aN5QZCJbUnfmh6wtRsllk5R2 k9uNJwMkWneWeJxxW5PfEj9tWXNA0If5xpAeluytxOVp7UAAgVEsGybbl9Pm Gifvx1kXMe2y4SN.2j4biNvpQ0haubvJSsn4ar8q_K1S5TKOsOwwfGLhF27X ILVJESsIQS.t6rzl6FYurP2OGa.8oDCD5Zi8_fNKE1U0Yk3l.y07I1TW7Bhg d4gGGbVlyNXscgiM9sDN8N68x09AIS8NRrp4fHIsZfsu1yPm_G7XaEifEAve 8CXC4OAvvcyqNlnAwPM5pBHczgCr2TBsFp57XZM3vAN_QT5Qn.d_lNrPkAlU K8Co8CEsq6UMRmXftwxTwrkBA2YReVQ-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: multipart/alternative; boundary="Apple-Mail=_A7535CAC-9FF2-4B86-A079-716D86962753" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 11:12:45 -0700 Message-Id: References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Tue, 12 May 2015 11:56:49 -0700 Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:12:56 -0000 --Apple-Mail=_A7535CAC-9FF2-4B86-A079-716D86962753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, My understanding of the SCIM WG charter indicates the use cases are = intended to cover both enterprise to cloud provider and cloud-to-cloud = scenarios. Unless I am missing something, I think the latest drafts do = handle the issue appropriately. In particular, in the last update, the text put in regarding SLAs and = privacy covers the issues raised regarding the cloud-to-cloud and = enterprise-to-cloud cases: =46rom the Core Schema Privacy Section (9.3): Information should be shared on an as-needed basis. A SCIM client should limit information to what it believes a service provider requires, and a SCIM service provider, should only accept information it needs. Clients and service providers should take into consideration that personal information is being conveyed across technical (e.g., protocol and applications), administrative (e.g. organizational, corporate), and jurisdictional boundaries. In particular information security and privacy must be considered. Security service level agreements for the handling of these attributes are beyond the scope of this document, but are to be carefully considered by implementers and deploying organizations. Please see the Privacy Considerations section of [ I-D.ietf-scim-api ], for more protocol specific considerations for handling of SCIM information. I also note that while core schema spec doesn=E2=80=99t explicitly call = for TLS (since it is a schema spec) it does so implicitly as we call = attention to the protocol spec: 9.1. Protocol SCIM data is intended to be exchanged using SCIM Protocol. It is important when handling data to implement the security considerations outlined in Section 7 of [ I-D.ietf-scim-api]. Section 7.2 of SCIM Protocol indicates TLS 1.2 is required. =20 Would you like stronger, more explicit wording? E.g. regardless of = protocol, the exchange of sensitive information MUST be protected by = encryption such as TLS 1.2 or better? Or, be more limited and specifically say TLS 1.2 *and* SCIM Protocol = MUST be used. Let me know if you think we need to put any more introductory = information in or explicitly repeat some of the api security = requirements.=20 Regarding the text suggestions:=20 > "This schema is intended for exchange and use with cloud > service providers and their customers." This suggestion is ok with me.=20 Regarding: > "This schema is intended for exchange and use with > cloud service providers and other cross-domain scenarios.=E2=80=9D I=E2=80=99m thinking the text pasted above does address the concern you = raise regarding permissions. Does this address your concern?=20 Phil phil.hunt@yahoo.com > On May 11, 2015, at 5:45 PM, Kathleen Moriarty = wrote: >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft and the updates that took care of = most > of the items I wanted to discuss. There is just one left and maybe an > email response will clear up the scope of SCIM for me. I'm not = entirely > clear on how data might pass between service providers on behalf of a > customer, or if this is just between an customer and a service = provider.=20 > The latter doesn't have to worry about some security considerations of > the former, so it would be good to know how the scope is limited. >=20 > 4. It would help to have a statement that lists the scope of where = SCIM > is used and that the protocol design requires encryption when this = data > is in transit (per the api draft), since most of the attributes = defined > would contain PII when used. =20 >=20 > I'm making some assumptions, so please correct the text to the scope = of > SCIM. The abstract has the following sentence: > "This schema is intended for exchange and use with cloud > service providers." > What about the following: > "This schema is intended for exchange and use with cloud > service providers and their customers." >=20 > There is also this statement int he introduction: > "This schema is intended for exchange and use with > cloud service providers and other cross-domain scenarios." >=20 > Is it also used between service providers? If so, permission to = provide > customers user information between service providers gets tricky and I > don't think that was covered in the API draft, but please let me know = if > I missed it. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for addressing the SecDir review adding text on clear = text/hashed > passwords and best practices (to avoid storing clear text, etc.).=20 > https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html >=20 > Thanks for the additional privacy considerations, pointing out that = most > of the data that could be sent using the SCIM schema could be = sensitive > in addition to the id and externalId. >=20 > Thanks for the additional text to out-of-scope some of the security > controls that are really in the hands of implementers and may be > specified through security SLAs or contracts. >=20 >=20 --Apple-Mail=_A7535CAC-9FF2-4B86-A079-716D86962753 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

My understanding of the = SCIM WG charter indicates the use cases are intended to cover both = enterprise to cloud provider and cloud-to-cloud scenarios. Unless I am = missing something, I think the latest drafts do handle the issue = appropriately.

In particular, in the last update, the text put in regarding = SLAs and privacy covers the issues raised regarding the cloud-to-cloud = and enterprise-to-cloud cases:

=46rom the Core Schema Privacy Section = (9.3):
   Information should be shared on an as-needed = basis.  A SCIM client
   should limit information to = what it believes a service provider
   requires, and a SCIM = service provider, should only accept information
   it needs. =  Clients and service providers should take into
  =  consideration that personal information is being conveyed = across
   technical (e.g., protocol and applications), = administrative (e.g.
   organizational, corporate), and = jurisdictional boundaries.  In
   particular information = security and privacy must be considered.

   Security = service level agreements for the handling of these
   attributes = are beyond the scope of this document, but are to be
   carefully = considered by implementers and deploying organizations.

   Please see the Privacy Considerations section of = [
I-D.ietf-scim-api
],
   for more protocol specific considerations = for handling of SCIM
   information.

I also note that while core schema spec = doesn=E2=80=99t explicitly call for TLS (since it is a schema spec) it = does so implicitly as we call attention to the protocol spec:

9.1.  Protocol

   SCIM data = is intended to be exchanged using SCIM Protocol.  It = is
   important when handling data to implement the = security considerations
   outlined in Section 7 of = [
I-D.ietf-scim-api].

Section 7.2 of SCIM Protocol indicates = TLS 1.2 is required.  

Would you like stronger, more explicit wording?  E.g. = regardless of protocol, the exchange of sensitive information MUST be = protected by encryption such as TLS 1.2 or better?

Or, be more limited and = specifically say TLS 1.2 *and* SCIM Protocol MUST be used.

Let me know if you think we need to put = any more introductory information in or explicitly repeat some of the = api security requirements. 

Regarding the text = suggestions: 
"This schema is intended for exchange and use with = cloud
  service = providers and their customers."

This suggestion is ok with me. 

Regarding:
  "This schema is intended for exchange = and use with
  cloud service providers and other = cross-domain scenarios.=E2=80=9D

I=E2=80=99m thinking the text = pasted above does address the concern you raise regarding = permissions.

Does this address your concern? 

Phil

phil.hunt@yahoo.com

On May 11, 2015, at 5:45 = PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for your work on this draft = and the updates that took care of most
of the items I = wanted to discuss.  There is just one left and maybe an
email response will clear up the scope of SCIM for me. =  I'm not entirely
clear on how data might pass = between service providers on behalf of a
customer, or if = this is just between an customer and a service provider. 
The latter doesn't have to worry about some security = considerations of
the former, so it would be good to know = how the scope is limited.

4. It would help = to have a statement that lists the scope of where SCIM
is = used and that the protocol design requires encryption when this data
is in transit (per the api draft), since most of the = attributes defined
would contain PII when used.  

I'm making some assumptions, so please correct = the text to the scope of
SCIM.  The abstract has the = following sentence:
  "This schema is intended for = exchange and use with cloud
  service providers."
What about the following:
  "This schema = is intended for exchange and use with cloud
  service = providers and their customers."

There is = also this statement int he introduction:
  "This = schema is intended for exchange and use with
  cloud = service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, = permission to provide
customers user information between = service providers gets tricky and I
don't think that was = covered in the API draft, but please let me know if
I = missed it.


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for addressing the SecDir = review adding text on clear text/hashed
passwords and best = practices (to avoid storing clear text, etc.). 
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.h= tml

Thanks for the additional privacy = considerations, pointing out that most
of the data that = could be sent using the SCIM schema could be sensitive
in = addition to the id and externalId.

Thanks = for the additional text to out-of-scope some of the security
controls that are really in the hands of implementers and may = be
specified through security SLAs or contracts.



= --Apple-Mail=_A7535CAC-9FF2-4B86-A079-716D86962753-- From nobody Tue May 12 11:58:21 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7C1A8887; Tue, 12 May 2015 11:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8-z4f3T-Wh3; Tue, 12 May 2015 11:58:17 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D374A1ACE85; Tue, 12 May 2015 11:58:16 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CIwDmY001977 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2015 20:58:13 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4CIw8ac022038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 20:58:11 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431457093; bh=JfN/ro1Rv5YkGOznwgPV0xDbjqXnL0hOXPZisHxS6ew=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=K1KabXiMA/QkcST17Slt8cm9W8UwCazJZi/6LGbR3Ehvk7ca3+u+7/PQJCyQ6Of8Y Ow6ug9wsAfj+MLGDrPfjmsfuBLHWTjvqafenNRVwsmbdGtpva14RsdYs/cB6cNxqBl z0VafBC7d6RycMFu7c9a1m2RgyFDAkeyQ4vQwnL8= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 12 May 2015 20:58:08 +0200 Message-ID: <55524D3F.40802@sunet.se> Date: Tue, 12 May 2015 20:58:07 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Phil Hunt References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Or6Wdi3 - 5cd0ef3bd63c - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:58:20 -0000 > > This text is good and helpful, my concern is that it doesn't say > anywhere that data could be transferred from a customer, to their > service provider, then to another service provider (except with the > cross-domain sentence). How does one track where their data went and > would that type of scenario be negotiated in contracts or could that > happen without the customer's knowledge? To me it sounds like we've ventured away from the realm of protocol design and into the realm of contracts and SLAs. I'm not sure I see how we could put anything other than a "nota bene" about this in the text. Cheers Leif From nobody Tue May 12 12:03:46 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834621A8887; Tue, 12 May 2015 12:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nPQao2kc301; Tue, 12 May 2015 12:03:40 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01941A8844; Tue, 12 May 2015 12:03:39 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so13161788lbb.3; Tue, 12 May 2015 12:03:38 -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=tL3icQA+eImQvRdy5FD+IWYLuninbEL+9P4pGXUaFh0=; b=YgIdoCwcy0RkDRARf908ke3ulXxk1JSqNbtqQc5gxvQod1OQGNs18zuggGKPJ/9lBt 6Ob7ZRyxha7CAeC3q7fLmRNn5xGb/UUM6y2OPLqgbpmq9zfIPaJtSxv7FF3wne7YxX+8 5mQDOP2XRn13OGl4/CWBBZR2PLsxqbzU9opeuHxxLHM9aZerMZVJFSaPEyN26t9thWTn ZgY5ZiVCuPDRibtq51Fhs5CH9cK/yunPrtubhSN/ageiTfExwzGgJMUsxlm1+cEdEQ3f E+TT2jhkLmfXJ23QRMLJJjHA5TJtU4tsdOHAEGKBLfkDlPDNhiC08nygMf6VPcFLtg6t zBxw== MIME-Version: 1.0 X-Received: by 10.152.121.42 with SMTP id lh10mr6202890lab.0.1431457418131; Tue, 12 May 2015 12:03:38 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 12:03:38 -0700 (PDT) In-Reply-To: <55524D3F.40802@sunet.se> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> Date: Tue, 12 May 2015 15:03:38 -0400 Message-ID: From: Kathleen Moriarty To: Leif Johansson Content-Type: multipart/alternative; boundary=089e01177485eb3cef0515e726a0 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:03:41 -0000 --089e01177485eb3cef0515e726a0 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 2:58 PM, Leif Johansson wrote: > > > > > This text is good and helpful, my concern is that it doesn't say > > anywhere that data could be transferred from a customer, to their > > service provider, then to another service provider (except with the > > cross-domain sentence). How does one track where their data went and > > would that type of scenario be negotiated in contracts or could that > > happen without the customer's knowledge? > > To me it sounds like we've ventured away from the realm of protocol > design and into the realm of contracts and SLAs. I'm not sure I see > how we could put anything other than a "nota bene" about this in > the text. > I'm thinking more along the lines of a security warning, since the data might go beyond where a customer thinks it is going. It would be good for users to be aware of this possibility so they know if they need to take precautions. An N.B. is fine. I didn't meant to imply that contracts should be mentioned with this, but rather that users were aware and they might take that step because the security consideration was noted. Thanks, Kathleen > > Cheers Leif > > -- Best regards, Kathleen --089e01177485eb3cef0515e726a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 2:58 PM, Leif Johansson <<= a href=3D"mailto:leifj@sunet.se" target=3D"_blank">leifj@sunet.se> wrote:

>
> This text is good and helpful, my concern is that it doesn't say > anywhere that data could be transferred from a customer, to their
> service provider, then to another service provider (except with the > cross-domain sentence).=C2=A0 How does one track where their data went= and
> would that type of scenario be negotiated in contracts or could that > happen without the customer's knowledge?

To me it sounds like we've ventured away from the realm of proto= col
design and into the realm of contracts and SLAs. I'm not sure I see
how we could put anything other than a "nota bene" about this in<= br> the text.

I'm thinking more along t= he lines of a security warning, since the data might go beyond where a cust= omer thinks it is going.=C2=A0 It would be good for users to be aware of th= is possibility so they know if they need to take precautions.=C2=A0 An N.B.= is fine.=C2=A0 I didn't meant to imply that contracts should be mentio= ned with this, but rather that users were aware and they might take that st= ep because the security consideration was noted.

T= hanks,
Kathleen =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif




--

Best regards,
Kath= leen
--089e01177485eb3cef0515e726a0-- From nobody Tue May 12 12:10:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF291A89AA; Tue, 12 May 2015 12:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvfzHd2EaZcs; Tue, 12 May 2015 12:10:47 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6A31ACE22; Tue, 12 May 2015 12:10:33 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CJAVSk018706 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2015 21:10:31 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4CJARvw023585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 21:10:29 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431457831; bh=Bfy25RLaLEhtrIwxB57jvYTEgzYYgGmxgXJXZMgZ0Qg=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=QR8dYZUlW7T1pVmbVEHZyJXfF64kvBl1xGb4ayKAd4gVM1x7YQcRRh0R05ObjLPkA haLwCS6IjxNixCQqRfeOKDQybtpP+r+RZLu78f7bgsjfJQBW2rUMZvHWP8tmtTW5A3 GrG7PDrdm2hVxTCrQdmWzHjzWEmzIZQ5YJ9apqs8= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 12 May 2015 21:10:26 +0200 Message-ID: <55525022.6040701@sunet.se> Date: Tue, 12 May 2015 21:10:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Or7avLl - 75e3aa94a6d8 - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:10:48 -0000 On 05/12/2015 09:03 PM, Kathleen Moriarty wrote: > > > On Tue, May 12, 2015 at 2:58 PM, Leif Johansson > wrote: > > > > > > This text is good and helpful, my concern is that it doesn't say > > anywhere that data could be transferred from a customer, to their > > service provider, then to another service provider (except with the > > cross-domain sentence). How does one track where their data went and > > would that type of scenario be negotiated in contracts or could that > > happen without the customer's knowledge? > > To me it sounds like we've ventured away from the realm of protocol > design and into the realm of contracts and SLAs. I'm not sure I see > how we could put anything other than a "nota bene" about this in > the text. > > > I'm thinking more along the lines of a security warning, since the data > might go beyond where a customer thinks it is going. It would be good > for users to be aware of this possibility so they know if they need to > take precautions. An N.B. is fine. I didn't meant to imply that > contracts should be mentioned with this, but rather that users were > aware and they might take that step because the security consideration > was noted. > So this is like saying "if you send an email, somebody might forward it". I'm not trying to be facetious but I'm struggling to understand why this is a particular feature of SCIM... ... or maybe we just decided to up the stakes a bit on privacy. I would be totally fine with that answer! Cheers Leif From nobody Tue May 12 12:21:59 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCF01ACE81; Tue, 12 May 2015 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjjyek-SyMBe; Tue, 12 May 2015 12:21:52 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EB21A8955; Tue, 12 May 2015 12:21:52 -0700 (PDT) Received: by widdi4 with SMTP id di4so167998384wid.0; Tue, 12 May 2015 12:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=M5HwtcLByOLXKZ/3qP6xdw6ZaeeII1PIeUPMIQxCSJo=; b=b2KZXMIHlvyr14DcfXtwtKwfUNfvG7/ebu6myWMNWZ/0Qmsid0EB5b5To9UbGkVXtX ALbNXOIxNNMkuBgqCUu8jUOheTFrtSkZdsQO6z0yVYRlMdCGefGIOSVIIw8IQEZ42xy2 oqk3oEOIHfqJDwoe+XBBR1NOmhY2eI2JnRnql8qVrLBj2tA25ix4cZwg079hiEWM5U/x 60eguri1SviGE95agM018d4Esza6tTZrDznTKz2aLi/uKsp8Cv8dtULU+8+MirVslZCh bDvs0/J1rUMCCLQ2GNxM5ey8lzzwa55C/IV8PUUOXtZkd2R+YXgg/H2RrL/vFmM8suGs gJtg== MIME-Version: 1.0 X-Received: by 10.194.90.147 with SMTP id bw19mr3862310wjb.60.1431458511352; Tue, 12 May 2015 12:21:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.194.237.234 with HTTP; Tue, 12 May 2015 12:21:51 -0700 (PDT) In-Reply-To: <55525022.6040701@sunet.se> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> Date: Tue, 12 May 2015 20:21:51 +0100 X-Google-Sender-Auth: Me5n7Uml9K8HlyLejAfdAvjE4wU Message-ID: From: Barry Leiba To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, Kathleen Moriarty , draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:21:54 -0000 >> I'm thinking more along the lines of a security warning, since the data >> might go beyond where a customer thinks it is going. It would be good >> for users to be aware of this possibility so they know if they need to >> take precautions. An N.B. is fine. I didn't meant to imply that >> contracts should be mentioned with this, but rather that users were >> aware and they might take that step because the security consideration >> was noted. > > So this is like saying "if you send an email, somebody might forward > it". I'm not trying to be facetious but I'm struggling to understand > why this is a particular feature of SCIM... Yes, this is what I was thinking, before Leif responded. We might be getting into a situation where, in order to make things privacy-aware, we're going beyond the reasonable realm of protocol specifications. We should be putting things in our protocol documentation to encourage good practices and to raise awareness of privacy concerns. But we shouldn't be sticking something into every protocol that says that information you give to another part might go places you didn't anticipate -- unless that protocol has specific aspects that make dissemination more likely. It's already the case that any information you give when you sign up for any service (whether it be your ISP, Google, or LL Bean) can be passed on to advertisers, bad guys, or whomever. We, as a community, need to raise awareness of that, but the place to do it isn't in every protocol document we write. Is there more to this request than that? Barry From nobody Tue May 12 12:22:19 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E491ACE81; Tue, 12 May 2015 12:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTT0XmyUL0Yp; Tue, 12 May 2015 12:22:10 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759561A8955; Tue, 12 May 2015 12:22:10 -0700 (PDT) Received: by laat2 with SMTP id t2so13567803laa.1; Tue, 12 May 2015 12:22:09 -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=blrB+1jZ+Q3NIThHBzpR1RJzbihg2uUdzdFiVngf0uA=; b=TR7nUy3S+GnPmwDoay8JlUg0PxZMJw0gRho8WCFDA60QllpvuLSPfCDwjvvqBhpL+h cJpE1q23nn0lYi+8Ut9v7/z3NFMm6KWpui9KkmX/f5yDQrLOMR7Swa4OfRgL3sdzAutb SXMANm506Y3B46FeR09Vdcwyd9o2M8AYAz36VjywrVLhflQT4kIaMEWQMXscKR6jPRBC mlOac62boauv2/KQIflpbih74SXh+DR6JIImpJK8iGpOasJvcpGpwRBWcAVp49OK7gRY N78ojuLMrTRwYoqlRlD/8HWFjCLvuLrBZPKWim1Dt3ngNnmIAEEwrd38cg+zzEsYlYHd sdwA== MIME-Version: 1.0 X-Received: by 10.112.167.228 with SMTP id zr4mr12987126lbb.113.1431458528990; Tue, 12 May 2015 12:22:08 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 12:22:08 -0700 (PDT) In-Reply-To: <55525022.6040701@sunet.se> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> Date: Tue, 12 May 2015 15:22:08 -0400 Message-ID: From: Kathleen Moriarty To: Leif Johansson Content-Type: multipart/alternative; boundary=001a11c2432a219d3e0515e76918 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:22:17 -0000 --001a11c2432a219d3e0515e76918 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 3:10 PM, Leif Johansson wrote: > On 05/12/2015 09:03 PM, Kathleen Moriarty wrote: > > > > > > On Tue, May 12, 2015 at 2:58 PM, Leif Johansson > > wrote: > > > > > > > > > > This text is good and helpful, my concern is that it doesn't say > > > anywhere that data could be transferred from a customer, to their > > > service provider, then to another service provider (except with the > > > cross-domain sentence). How does one track where their data went > and > > > would that type of scenario be negotiated in contracts or could > that > > > happen without the customer's knowledge? > > > > To me it sounds like we've ventured away from the realm of protocol > > design and into the realm of contracts and SLAs. I'm not sure I see > > how we could put anything other than a "nota bene" about this in > > the text. > > > > > > I'm thinking more along the lines of a security warning, since the data > > might go beyond where a customer thinks it is going. It would be good > > for users to be aware of this possibility so they know if they need to > > take precautions. An N.B. is fine. I didn't meant to imply that > > contracts should be mentioned with this, but rather that users were > > aware and they might take that step because the security consideration > > was noted. > > > > So this is like saying "if you send an email, somebody might forward > it". I'm not trying to be facetious but I'm struggling to understand > why this is a particular feature of SCIM... > I'd say this is pretty different from email, but even with that it's well documented that email goes through relays and could be copied at any point along the way... when in a mail queue on a server where it's not protected by transport encryption. > > ... or maybe we just decided to up the stakes a bit on privacy. I would > be totally fine with that answer! > It doesn't concern you that your info could be forwarded legitimately using the protocol and that isn't mentioned explicitly? I'm putting my hat back on as a former CISO, head of security, etc. where I evaluated such services and I would need to know this bit of information for the handling of sensitive and privacy related information. I know I was a PITA to the service providers and vendors I worked with, but this is exactly the kind of thing I'd want to know - where are all the places my data could flow to and how does it flow there (you've answered the latter already- all TLS protected). > > Cheers Leif > > > -- Best regards, Kathleen --001a11c2432a219d3e0515e76918 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 3:10 PM, Leif Johansson <<= a href=3D"mailto:leifj@sunet.se" target=3D"_blank">leifj@sunet.se> wrote:
On 05/12/20= 15 09:03 PM, Kathleen Moriarty wrote:
>
>
> On Tue, May 12, 2015 at 2:58 PM, Leif Johansson <leifj@sunet.se
> <mailto:l= eifj@sunet.se>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This text is good and helpful, my concern is t= hat it doesn't say
>=C2=A0 =C2=A0 =C2=A0> anywhere that data could be transferred from a= customer, to their
>=C2=A0 =C2=A0 =C2=A0> service provider, then to another service prov= ider (except with the
>=C2=A0 =C2=A0 =C2=A0> cross-domain sentence).=C2=A0 How does one tra= ck where their data went and
>=C2=A0 =C2=A0 =C2=A0> would that type of scenario be negotiated in c= ontracts or could that
>=C2=A0 =C2=A0 =C2=A0> happen without the customer's knowledge? >
>=C2=A0 =C2=A0 =C2=A0To me it sounds like we've ventured away from t= he realm of protocol
>=C2=A0 =C2=A0 =C2=A0design and into the realm of contracts and SLAs. I&= #39;m not sure I see
>=C2=A0 =C2=A0 =C2=A0how we could put anything other than a "nota b= ene" about this in
>=C2=A0 =C2=A0 =C2=A0the text.
>
>
> I'm thinking more along the lines of a security warning, since the= data
> might go beyond where a customer thinks it is going.=C2=A0 It would be= good
> for users to be aware of this possibility so they know if they need to=
> take precautions.=C2=A0 An N.B. is fine.=C2=A0 I didn't meant to i= mply that
> contracts should be mentioned with this, but rather that users were > aware and they might take that step because the security consideration=
> was noted.
>

So this is like saying "if you send an email, somebody might fo= rward
it". I'm not trying to be facetious but I'm struggling to unde= rstand
why this is a particular feature of SCIM...

=
I'd say this is pretty different from email, but even with that it= 's well documented that email goes through relays and could be copied a= t any point along the way... when in a mail queue on a server where it'= s not protected by transport encryption.=C2=A0

... or maybe we just decided to up the stakes a bit on privacy. I would
be totally fine with that answer!

It do= esn't concern you that your info could be forwarded legitimately using = the protocol and that isn't mentioned explicitly?=C2=A0 I'm putting= my hat back on as a former CISO, head of security, etc. where I evaluated = such services and I would need to know this bit of information for the hand= ling of sensitive and privacy related information.=C2=A0 I know I was a PIT= A to the service providers and vendors I worked with, but this is exactly t= he kind of thing I'd want to know - where are all the places my data co= uld flow to and how does it flow there (you've answered the latter alre= ady- all TLS protected).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif





--

Best regards,
Kath= leen
--001a11c2432a219d3e0515e76918-- From nobody Tue May 12 12:23:58 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5F1ACEA2; Tue, 12 May 2015 12:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugDKS0teD54r; Tue, 12 May 2015 12:23:51 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2901A894C; Tue, 12 May 2015 12:23:51 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so13654309lbb.0; Tue, 12 May 2015 12:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5Mt+Nd0X3uf2/t/JSXDM0LZKVxqFE4fm355WZ4YaR0=; b=XIpJOwP4Yh4B6VxjvrN8NGDF9T19+THCTBohykbxWqcYIFB2BdAxj3YPJnm/07xWDx Pid4Lpz72vxaFwvO1oefuUZJJmgy4ULLVp5keCcQFh7NP0OaesDs8ukHDPVrV5wKiT9B ey0ireQFfSLKTgu16YbEdz9qEjDVyp59WK7FSgsP0HBks7mdkFgCowuAYfJ7Bm9540Xj HG634kuA+8d2XcRIlWFT1VojXm8O/9wK21LX3E1gn7hsM2IlP1gvkYzo58JfGwXx6IU6 h09+a1qP3cWB7Ttgl8nn8MSLCC9SHmWZR/MuQPUunPMG8T9XHgIVtbgtE4zQ/DMQgT8H zKUg== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr12945468lbb.75.1431458629856; Tue, 12 May 2015 12:23:49 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 12:23:49 -0700 (PDT) In-Reply-To: References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> Date: Tue, 12 May 2015 15:23:49 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c382d024b4650515e76f52 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , scim-chairs@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:23:53 -0000 --001a11c382d024b4650515e76f52 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 3:21 PM, Barry Leiba wrote: > >> I'm thinking more along the lines of a security warning, since the data > >> might go beyond where a customer thinks it is going. It would be good > >> for users to be aware of this possibility so they know if they need to > >> take precautions. An N.B. is fine. I didn't meant to imply that > >> contracts should be mentioned with this, but rather that users were > >> aware and they might take that step because the security consideration > >> was noted. > > > > So this is like saying "if you send an email, somebody might forward > > it". I'm not trying to be facetious but I'm struggling to understand > > why this is a particular feature of SCIM... > > Yes, this is what I was thinking, before Leif responded. We might be > getting into a situation where, in order to make things privacy-aware, > we're going beyond the reasonable realm of protocol specifications. > We should be putting things in our protocol documentation to encourage > good practices and to raise awareness of privacy concerns. But we > shouldn't be sticking something into every protocol that says that > information you give to another part might go places you didn't > anticipate -- unless that protocol has specific aspects that make > dissemination more likely. > > It's already the case that any information you give when you sign up > for any service (whether it be your ISP, Google, or LL Bean) can be > passed on to advertisers, bad guys, or whomever. We, as a community, > need to raise awareness of that, but the place to do it isn't in every > protocol document we write. > > Is there more to this request than that? > If the scope of SCIM is to allow this data to be transferred between customers and their service providers, and from your service provider to another one, why is there opposition to stating that clearly? Thanks, Kathleen > > Barry > -- Best regards, Kathleen --001a11c382d024b4650515e76f52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 3:21 PM, Barry Leiba <barryleiba@compute= r.org> wrote:
>> I'm thinking more along the lines of a security warning,= since the data
>> might go beyond where a customer thinks it is going.=C2=A0 It woul= d be good
>> for users to be aware of this possibility so they know if they nee= d to
>> take precautions.=C2=A0 An N.B. is fine.=C2=A0 I didn't meant = to imply that
>> contracts should be mentioned with this, but rather that users wer= e
>> aware and they might take that step because the security considera= tion
>> was noted.
>
> So this is like saying "if you send an email, somebody might forw= ard
> it". I'm not trying to be facetious but I'm struggling to= understand
> why this is a particular feature of SCIM...

Yes, this is what I was thinking, before Leif responded.=C2=A0 We mi= ght be
getting into a situation where, in order to make things privacy-aware,
we're going beyond the reasonable realm of protocol specifications.
We should be putting things in our protocol documentation to encourage
good practices and to raise awareness of privacy concerns.=C2=A0 But we
shouldn't be sticking something into every protocol that says that
information you give to another part might go places you didn't
anticipate -- unless that protocol has specific aspects that make
dissemination more likely.

It's already the case that any information you give when you sign up for any service (whether it be your ISP, Google, or LL Bean) can be
passed on to advertisers, bad guys, or whomever.=C2=A0 We, as a community,<= br> need to raise awareness of that, but the place to do it isn't in every<= br> protocol document we write.

Is there more to this request than that?

If the scope of SCIM is to allow this data to be transferred between cust= omers and their service providers, and from your service provider to anothe= r one, why is there opposition to stating that clearly?

Thanks,
Kathleen=C2=A0

Barry



--

Best regards,
Kathleen
--001a11c382d024b4650515e76f52-- From nobody Tue May 12 12:35:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11A51A8851; Tue, 12 May 2015 12:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9SSagmcCu2s; Tue, 12 May 2015 12:35:26 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C0B1A87E0; Tue, 12 May 2015 12:35:25 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CJZLOw007844 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2015 21:35:21 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4CJZHwf010519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 21:35:19 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431459321; bh=eSznG3Hltu5avXlWSQvrlHaSWw6JGZpT3ljEOoJ03/c=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=VrWPcw0LwTwtyW11XNahgAvr2jUFLKq3/ry/zS4vA4nqwYQ00B6N+I5aeVA04XhkV +u5mcje3xq8zchX73bvBOnlHllVtxchYdQ5pKasdhics1y8dTECUFUZ4eW94ugp3xe LzpZquVBoincGnPLM70LI0+c9HQh33w5LACmf6vc= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 12 May 2015 21:35:15 +0200 Message-ID: <555255F0.6060409@sunet.se> Date: Tue, 12 May 2015 21:35:12 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Or7zlEk - 9abbcaa4c7cc - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:35:27 -0000 > It doesn't concern you that your info could be forwarded legitimately It would concern me a lot more if the intended user of SCIM was the end-user - i.e if SCIM was more like OpenSocial (something that was discussed and rejected by the WG btw: there is no @me in SCIM). Had this been the case the implementer of SCIM could be advised to display warnings etc... > using the protocol and that isn't mentioned explicitly? I'm putting my > hat back on as a former CISO, head of security, etc. where I evaluated > such services and I would need to know this bit of information for the > handling of sensitive and privacy related information. I know I was a > PITA to the service providers and vendors I worked with, but this is > exactly the kind of thing I'd want to know - where are all the places my > data could flow to and how does it flow there (you've answered the > latter already- all TLS protected). ... and if I was CISO and was reviewing a deployment of SCIM for provisioning my company employee data to LL Bean then I'd make sure to have controls to cover that in the contracts. My point is that I'm going to do that regardless of what it sais in the SCIM protocol spec, right? Cheers Leif From nobody Tue May 12 12:36:33 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31411A885C; Tue, 12 May 2015 12:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy2mEqzWK1il; Tue, 12 May 2015 12:36:31 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3AE1A8853; Tue, 12 May 2015 12:36:30 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CJaSsk009512 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2015 21:36:28 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4CJaN5I029933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 21:36:25 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431459387; bh=reA65owBi0cS4Hk36wnYffyTNFEQ/xgNG4vTuuSKVnQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=qLKthZKUCVnP0H+NMgVNiXKTKlqnY8q+Bnatp+8Uj7BhY+JGMILnzvNuusOuYL36u ii7tK1XuSwfnBq95BokdxVtj3r4/Y1tMQ8ebEg4ygQ/5j+9UmhNkynmpJleHdg1pRV 4vLmvsbMuzHP2/u3UXw+VRgOmaW5zPm6lNMgAKyA= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 12 May 2015 21:36:22 +0200 Message-ID: <55525636.2010300@sunet.se> Date: Tue, 12 May 2015 21:36:22 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Or7AsO4 - a51894bd2964 - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:36:31 -0000 > > If the scope of SCIM is to allow this data to be transferred between > customers and their service providers, and from your service provider to > another one, why is there opposition to stating that clearly? fwiw - I don't feel very strongly about this either way and I'm pretty sure the authors don't either. I just thought it an interesting point to discuss. From nobody Tue May 12 12:41:30 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827DF1A886F; Tue, 12 May 2015 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0SC4slT2iDM; Tue, 12 May 2015 12:41:24 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD001A1BC0; Tue, 12 May 2015 12:41:23 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so13890903lbb.2; Tue, 12 May 2015 12:41:22 -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=DxHgN7wkuOLNMC+qes630tXR6SRcxyKwd+Y4lO1vj5s=; b=bCOiVCCn8XXDB13Uf6m9WVRT/ZZgdjDbC9SrLVH7E09hxNVW7eeOI9LhVIv4nMQ+qW r3Jr7NQ9Ql67ch0dkTXsnYQ0yvrcuyjsspUZohEDO/ls9XWxxot2C16UuUyI/IAsRE0F u9O594+NsCkxbSzSwMdqlN9BXPu5zBY2Lu5i315Yf5n1TNgyjKZDsTFiQUCKUDcpmqh0 EzTlNYkoxFKn4O7o1mXHaZOhGSoDTaTm44bfCtCK3fDDsiY4jJBpCu1c+n080R2kZPPJ u/25gAbS669l7AqRH6xIcbKkiFS0WOdp2nmA0BICWUcWhaBopOR5PAinBGjxNex4OLiR 5Kig== MIME-Version: 1.0 X-Received: by 10.152.4.72 with SMTP id i8mr13655703lai.32.1431459682289; Tue, 12 May 2015 12:41:22 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 12:41:22 -0700 (PDT) In-Reply-To: <55525636.2010300@sunet.se> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <55525636.2010300@sunet.se> Date: Tue, 12 May 2015 15:41:22 -0400 Message-ID: From: Kathleen Moriarty To: Leif Johansson Content-Type: multipart/alternative; boundary=089e01494248df8fc20515e7add4 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , Barry Leiba , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:41:25 -0000 --089e01494248df8fc20515e7add4 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 3:36 PM, Leif Johansson wrote: > > > > > If the scope of SCIM is to allow this data to be transferred between > > customers and their service providers, and from your service provider to > > another one, why is there opposition to stating that clearly? > > fwiw - I don't feel very strongly about this either way and I'm pretty > sure the authors don't either. I just thought it an interesting point to > discuss. > It's something I would want pointed out if I were evaluating the use of SCIM and would want to know what security considerations I should think about - where could my data go and how? Scope is usually stated in the routing drafts that come through, which is great, because it eliminates security concerns in most cases (within a closed environment). I think this is an important security consideration and is easy enough to address by clearly stating the scope of use by altering a sentence in the introduction to state it more clearly. I think the scope here rises above just a comment as the impact could be big if the security consideration were not realized. Thanks, -- Best regards, Kathleen --089e01494248df8fc20515e7add4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 3:36 PM, Leif Johansson <<= a href=3D"mailto:leifj@sunet.se" target=3D"_blank">leifj@sunet.se> wrote:

>
> If the scope of SCIM is to allow this data to be transferred between > customers and their service providers, and from your service provider = to
> another one, why is there opposition to stating that clearly?

fwiw - I don't feel very strongly about this either way and I= 9;m pretty
sure the authors don't either. I just thought it an interesting point t= o
discuss.

It's something I would wan= t pointed out if I were evaluating the use of SCIM and would want to know w= hat security considerations I should think about - where could my data go a= nd how?=C2=A0 Scope is usually stated in the routing drafts that come throu= gh, which is great, because it eliminates security concerns in most cases (= within a closed environment).=C2=A0 I think this is an important security c= onsideration and is easy enough to address by clearly stating the scope of = use by altering a sentence in the introduction to state it more clearly.=C2= =A0 I think the scope here rises above just a comment as the impact could b= e big if the security consideration were not realized.

Thanks,


-- =

Best regards,<= /div>
Kathleen
--089e01494248df8fc20515e7add4-- From nobody Tue May 12 12:43:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260FD1A886A; Tue, 12 May 2015 12:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nnibKdmy_lI; Tue, 12 May 2015 12:43:49 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DFD1A88A3; Tue, 12 May 2015 12:43:49 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so14022885lbb.0; Tue, 12 May 2015 12:43:47 -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=o0hEAwS4y+Tqv8HjGDEqmKxbenLYbCtkybnktWo0B9w=; b=svObGt/hA186CP7jE4adrzOQHtaGZrJCBCKZzd1Eh7/H2CHgxDjkLINiiiwB4HGyfY 6AoxuFgRYeZqlzGCNUo1sTDEx9fdlHBkdhrxf8qRzZ5OxFFsO5FATD9MP2R6xJaRTZP+ pGankc24eTCR5LGSo5CE035TvsNCMVwBJV7+ZZtWwbs9s/owRSjp7EUZOjw4WwyvwHCR +isWDC+kCIyIntghD35i2C+uXwnVall5T/abF9yTgKlQ2OTD2usW9WnseUbe+HhgOLIQ zWLWiD7ZJP5sIAKOMPdegs4HYbd58mi1/psFEvQSvELlVLk8/LJnpthHeQvCVkQ7RJYF pDRA== MIME-Version: 1.0 X-Received: by 10.112.151.163 with SMTP id ur3mr2316110lbb.0.1431459827712; Tue, 12 May 2015 12:43:47 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 12:43:47 -0700 (PDT) In-Reply-To: <555255F0.6060409@sunet.se> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <555255F0.6060409@sunet.se> Date: Tue, 12 May 2015 15:43:47 -0400 Message-ID: From: Kathleen Moriarty To: Leif Johansson Content-Type: multipart/alternative; boundary=047d7beb9ffe8a8e970515e7b658 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:43:51 -0000 --047d7beb9ffe8a8e970515e7b658 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 3:35 PM, Leif Johansson wrote: > > > It doesn't concern you that your info could be forwarded legitimately > > It would concern me a lot more if the intended user of SCIM was the > end-user - i.e if SCIM was more like OpenSocial (something that was > discussed and rejected by the WG btw: there is no @me in SCIM). Had > this been the case the implementer of SCIM could be advised to > display warnings etc... > > > using the protocol and that isn't mentioned explicitly? I'm putting my > > hat back on as a former CISO, head of security, etc. where I evaluated > > such services and I would need to know this bit of information for the > > handling of sensitive and privacy related information. I know I was a > > PITA to the service providers and vendors I worked with, but this is > > exactly the kind of thing I'd want to know - where are all the places my > > data could flow to and how does it flow there (you've answered the > > latter already- all TLS protected). > > ... and if I was CISO and was reviewing a deployment of SCIM for > provisioning my company employee data to LL Bean then I'd make > sure to have controls to cover that in the contracts. > > My point is that I'm going to do that regardless of what it sais > in the SCIM protocol spec, right? > I would and you would, but not everyone does. Another problem is that often times you wind up talking to sales and it's really hard to get an answer. It's much easier if we do a good job of listing out security considerations. > > Cheers Leif > > > > -- Best regards, Kathleen --047d7beb9ffe8a8e970515e7b658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 3:35 PM, Leif Johansson <<= a href=3D"mailto:leifj@sunet.se" target=3D"_blank">leifj@sunet.se> wrote:

> It doesn't concern you that your info could be forwarded legitimat= ely

It would concern me a lot more if the intended user of SCIM was the<= br> end-user - i.e if SCIM was more like OpenSocial (something that was
discussed and rejected by the WG btw: there is no @me in SCIM). Had
this been the case the implementer of SCIM could be advised to
display warnings etc...

> using the protocol and that isn't mentioned explicitly?=C2=A0 I= 9;m putting my
> hat back on as a former CISO, head of security, etc. where I evaluated=
> such services and I would need to know this bit of information for the=
> handling of sensitive and privacy related information.=C2=A0 I know I = was a
> PITA to the service providers and vendors I worked with, but this is > exactly the kind of thing I'd want to know - where are all the pla= ces my
> data could flow to and how does it flow there (you've answered the=
> latter already- all TLS protected).

... and if I was CISO and was reviewing a deployment of SCIM for
provisioning my company employee data to LL Bean then I'd make
sure to have controls to cover that in the contracts.

My point is that I'm going to do that regardless of what it sais
in the SCIM protocol spec, right?

I wou= ld and you would, but not everyone does.=C2=A0 Another problem is that ofte= n times you wind up talking to sales and it's really hard to get an ans= wer.=C2=A0 It's much easier if we do a good job of listing out security= considerations.=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif






--

Best regards,
Kath= leen
--047d7beb9ffe8a8e970515e7b658-- From nobody Tue May 12 12:46:13 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BCA1A7034; Tue, 12 May 2015 12:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJvEdJgjt6bM; Tue, 12 May 2015 12:46:06 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10541A894C; Tue, 12 May 2015 12:46:06 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 12 May 2015 12:46:06 -0700 From: Michael Hammer To: "leifj@sunet.se" , "kathleen.moriarty.ietf@gmail.com" Thread-Topic: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) Thread-Index: AQHQjEz7yQeZWmoQ/U2x5A4grzHiqp14qNmMgAB/D4CAAAGLAIAAAeYA//+UBJA= Date: Tue, 12 May 2015 19:46:05 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BC0AF1ED@sc9-ex2k10mb1.corp.yaanatech.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> In-Reply-To: <55525022.6040701@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.124] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0263_01D08CCA.C0D150D0" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-scim-core-schema.ad@ietf.org" , "phil.hunt@yahoo.com" , "draft-ietf-scim-core-schema@ietf.org" , "draft-ietf-scim-core-schema.shepherd@ietf.org" , "iesg@ietf.org" , "scim-chairs@ietf.org" , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:46:08 -0000 ------=_NextPart_000_0263_01D08CCA.C0D150D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That sounds like another WG's tagging to let partners know which communities you can share with, outside of which you are violating some policy rule. Versus an note to say: if you share, it is public. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Tuesday, May 12, 2015 3:10 PM To: Kathleen Moriarty Cc: draft-ietf-scim-core-schema.ad@ietf.org; Phil Hunt; draft-ietf-scim-core-schema@ietf.org; draft-ietf-scim-core-schema.shepherd@ietf.org; The IESG; scim-chairs@ietf.org; scim@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) On 05/12/2015 09:03 PM, Kathleen Moriarty wrote: > > > On Tue, May 12, 2015 at 2:58 PM, Leif Johansson > wrote: > > > > > > This text is good and helpful, my concern is that it doesn't say > > anywhere that data could be transferred from a customer, to their > > service provider, then to another service provider (except with the > > cross-domain sentence). How does one track where their data went and > > would that type of scenario be negotiated in contracts or could that > > happen without the customer's knowledge? > > To me it sounds like we've ventured away from the realm of protocol > design and into the realm of contracts and SLAs. I'm not sure I see > how we could put anything other than a "nota bene" about this in > the text. > > > I'm thinking more along the lines of a security warning, since the > data might go beyond where a customer thinks it is going. It would be > good for users to be aware of this possibility so they know if they > need to take precautions. An N.B. is fine. I didn't meant to imply > that contracts should be mentioned with this, but rather that users > were aware and they might take that step because the security > consideration was noted. > So this is like saying "if you send an email, somebody might forward it". I'm not trying to be facetious but I'm struggling to understand why this is a particular feature of SCIM... ... or maybe we just decided to up the stakes a bit on privacy. I would be totally fine with that answer! Cheers Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0263_01D08CCA.C0D150D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNTEyMTk0NjAzWjAjBgkqhkiG 9w0BCQQxFgQUdQgKogfvy8E/saqN83x4BpvbhAAwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwDQYJKoZIhvcNAQEBBQAEggEA fLJkZaQe6AEzprMiY90I3exwrtTA/ck9Sy6HccVDNMRloN++576aE4Cd/eDtI9UyPLbtUhmGsqyi iOfOo0X2HZbfHiYyKRS+o/RKrGjv1DYRwx/fkC33DneMSJIaptFK/sLmVE5yXK89o0XITa8EuMha zPSJF0YwuFCUAcoAaUVj/1WSin8X01abGqfcrCzf9QtlOIqD6QxTKHfQMIRRCHshhsirPqGxWRzD rRfFDFAmLexqEHDXojxV+FMJh4NCkUxt5igIc1jX5NVx/V+c2fKNMuUknadIyr8gIBWn4rDWnYOM 3b5RatIXitnarMlG7eGT1xobpvPOs9dwm9QdjwAAAAAAAA== ------=_NextPart_000_0263_01D08CCA.C0D150D0-- From nobody Tue May 12 12:52:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FD51A8912; Tue, 12 May 2015 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVRDOPZfGjj6; Tue, 12 May 2015 12:52:27 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8551A87D2; Tue, 12 May 2015 12:52:27 -0700 (PDT) Received: by wgnd10 with SMTP id d10so19285772wgn.2; Tue, 12 May 2015 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LIzH94fzCSf/ata5NQHhRAHevdLTuonPIA6LbC0qgB8=; b=lB0gSQaVa4idpMUOCjnwua5icheqK7GXqRTqU43DrKaRdJktLgOHz2atHstgyh0Z8v 3X+HvJHClu6USviRoFbedaa9HSGOM7+KDzVlsrPIXQ/Z7HYCU3v2lL6VObABodvibQr7 BJHm4/kLALjyaTCh072y1FbXJtwUB3JcuI3tgC35nQi6Z9Y0UQKcHjkrJxwq2s/EchwN yehFEN99mhLc+KojMGZqB2MAkY0tD6IfVfE+bIUmjNOsfZ5qXv8pXG440NmZxcI6r+g1 NrHySDKBqy8x6d6heFnWGGgsa5Kayqg0tSoiIOd2ZCUEYjR8BEDuShy4PAPUd1+Dbba/ wT/Q== MIME-Version: 1.0 X-Received: by 10.180.84.65 with SMTP id w1mr32342241wiy.20.1431460346012; Tue, 12 May 2015 12:52:26 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.194.237.234 with HTTP; Tue, 12 May 2015 12:52:25 -0700 (PDT) In-Reply-To: References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> Date: Tue, 12 May 2015 20:52:25 +0100 X-Google-Sender-Auth: 2VPTvcMKoRw3Xfs9NwQobfvCQro Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , Leif Johansson , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:52:28 -0000 > If the scope of SCIM is to allow this data to be transferred between > customers and their service providers, and from your service provider to > another one, why is there opposition to stating that clearly? If that's all you want said, there's no opposition. b From nobody Tue May 12 13:13:44 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094E21ACF24; Tue, 12 May 2015 13:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdPmHaog-Rby; Tue, 12 May 2015 13:13:39 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD4C1A8904; Tue, 12 May 2015 13:13:39 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CKDaft032139 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 May 2015 22:13:36 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4CKDV2E009634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 22:13:33 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431461615; bh=L7Q1s75D3fDPrdeKoEHUWTKDiR5UVOB6Pl8KCXT5Bz8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=gWYugICBvNkgMt6dLCZuCwa/ewVgbmAEooYv6F7sbJvrM8jF8gz4WzSHd7ev+bi0t UpKhwwFPRSJ33WlMoSJACaD4R9pBQggPBFFBRuCExTy6jMDW4SCveFPGZUvIkGrxHV ATc8jcWEXZFW3yY7DAZmQLye4/AhHaiSEKq9PErI= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 12 May 2015 22:13:29 +0200 Message-ID: <55525EE9.2040707@sunet.se> Date: Tue, 12 May 2015 22:13:29 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Barry Leiba , Kathleen Moriarty References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Or8dABK - 848a354ce46b - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Phil Hunt , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:13:42 -0000 On 05/12/2015 09:52 PM, Barry Leiba wrote: >> If the scope of SCIM is to allow this data to be transferred between >> customers and their service providers, and from your service provider to >> another one, why is there opposition to stating that clearly? > > If that's all you want said, there's no opposition. > > b > +1 From nobody Tue May 12 13:51:30 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AC1AD060; Tue, 12 May 2015 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxBeiX1XirMe; Tue, 12 May 2015 13:51:23 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1321A8AA7; Tue, 12 May 2015 13:51:22 -0700 (PDT) Received: by layy10 with SMTP id y10so15231998lay.0; Tue, 12 May 2015 13:51:21 -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=HiWOi1JsNOm/7u8/f22jKw6EFIyApY7dxGLrN6XgCCk=; b=nUdZqPQeWmo/eVhmjCHeEWul2qQb+tlS4f4O5SEwvUCfP2pU6CeIOwwwmZooWM9EjU 4q7/xXX+XWBa7ADKHSJEXOqWeaeJLHPjlveyOlTbUw1reDUK2w/AGiWFMX/DEz2Uoyy+ LJNhctnq0DCuMQQFGSWuIEKE1oPOaUc6SOGwpN6tsUjd7NrYhsUHaTnB0fqYuumv6vvP 4dOi3ptGlq+3y93Tdq2psRPX3zcEHtxXScbBkmFVAdyHZMo42IlO5opFxNNsQuP+AmDE 5/I4AsiXBFlxdFP3n9cydLnlpAQVVz6qZSLHC3ryrTT3PZ/pgiNs7r1JeSUPMLLYxZud CLXg== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr13182257lbb.75.1431463881015; Tue, 12 May 2015 13:51:21 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 13:51:20 -0700 (PDT) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BC0AF1ED@sc9-ex2k10mb1.corp.yaanatech.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <00C069FD01E0324C9FFCADF539701DB3BC0AF1ED@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 12 May 2015 16:51:20 -0400 Message-ID: From: Kathleen Moriarty To: Michael Hammer Content-Type: multipart/alternative; boundary=001a11c382d02309970515e8a8a0 Archived-At: Cc: "draft-ietf-scim-core-schema.ad@ietf.org" , "phil.hunt@yahoo.com" , "scim-chairs@ietf.org" , "draft-ietf-scim-core-schema@ietf.org" , "draft-ietf-scim-core-schema.shepherd@ietf.org" , "iesg@ietf.org" , "leifj@sunet.se" , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:51:25 -0000 --001a11c382d02309970515e8a8a0 Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 3:46 PM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > That sounds like another WG's tagging to let partners know > which communities you can share with, outside of which > you are violating some policy rule. > Sure, that's what the info sharing communities do and my request doesn't go near that... just really to state the scope of SCIM, so folks know it could go from their SP to another SP. > > Versus an note to say: if you share, it is public. > This is at least a bit more controlled than that, I hope ;-) Kathleen > > ________________________________ > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408 202 9291 > 542 Gibraltar Drive > Milpitas, CA 95035 USA > www.yaanatech.com > > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson > Sent: Tuesday, May 12, 2015 3:10 PM > To: Kathleen Moriarty > Cc: draft-ietf-scim-core-schema.ad@ietf.org; Phil Hunt; > draft-ietf-scim-core-schema@ietf.org; > draft-ietf-scim-core-schema.shepherd@ietf.org; The IESG; > scim-chairs@ietf.org; scim@ietf.org > Subject: Re: [scim] Kathleen Moriarty's Discuss on > draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) > > On 05/12/2015 09:03 PM, Kathleen Moriarty wrote: > > > > > > On Tue, May 12, 2015 at 2:58 PM, Leif Johansson > > wrote: > > > > > > > > > > This text is good and helpful, my concern is that it doesn't say > > > anywhere that data could be transferred from a customer, to their > > > service provider, then to another service provider (except with the > > > cross-domain sentence). How does one track where their data went > and > > > would that type of scenario be negotiated in contracts or could > that > > > happen without the customer's knowledge? > > > > To me it sounds like we've ventured away from the realm of protocol > > design and into the realm of contracts and SLAs. I'm not sure I see > > how we could put anything other than a "nota bene" about this in > > the text. > > > > > > I'm thinking more along the lines of a security warning, since the > > data might go beyond where a customer thinks it is going. It would be > > good for users to be aware of this possibility so they know if they > > need to take precautions. An N.B. is fine. I didn't meant to imply > > that contracts should be mentioned with this, but rather that users > > were aware and they might take that step because the security > > consideration was noted. > > > > So this is like saying "if you send an email, somebody might forward it". > I'm not trying to be facetious but I'm struggling to understand why this is > a particular feature of SCIM... > > ... or maybe we just decided to up the stakes a bit on privacy. I would be > totally fine with that answer! > > Cheers Leif > > > _______________________________________________ > 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 > > -- Best regards, Kathleen --001a11c382d02309970515e8a8a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 3:46 PM, Michael Hammer <<= a href=3D"mailto:michael.hammer@yaanatech.com" target=3D"_blank">michael.ha= mmer@yaanatech.com> wrote:
= That sounds like another WG's tagging to let partners know
which communities you can share with, outside of which
you are violating some policy rule.

Sur= e, that's what the info sharing communities do and my request doesn'= ;t go near that... just really to state the scope of SCIM, so folks know it= could go from their SP to another SP.=C2=A0

Versus an note to say:=C2=A0 if you share, it is public.

This is at least a bit more controlled than that, I hope = ;-)

Kathleen=C2=A0

________________________________
Michael Hammer
Principal Engineer
michael.hammer@yaanatech.co= m
Mobile: +1 4= 08 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: scim [mailto:scim-bounces@ie= tf.org] On Behalf Of Leif Johansson
Sent: Tuesday, May 12, 2015 3:10 PM
To: Kathleen Moriarty
Cc: draft-ietf-s= cim-core-schema.ad@ietf.org; Phil Hunt;
draft-ietf-scim-cor= e-schema@ietf.org;
draft-ietf= -scim-core-schema.shepherd@ietf.org; The IESG;
scim-chairs@ietf.org; scim@ietf.org
Subject: Re: [scim] Kathleen Moriarty's Discuss on
draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT)

On 05/12/2015 09:03 PM, Kathleen Moriarty wrote:
>
>
> On Tue, May 12, 2015 at 2:58 PM, Leif Johansson <leifj@sunet.se
> <mailto:leifj@sunet.se>>= ; wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This text is good and helpful, my concern is t= hat it doesn't say
>=C2=A0 =C2=A0 =C2=A0> anywhere that data could be transferred from a= customer, to their
>=C2=A0 =C2=A0 =C2=A0> service provider, then to another service prov= ider (except with the
>=C2=A0 =C2=A0 =C2=A0> cross-domain sentence).=C2=A0 How does one tra= ck where their data went
and
>=C2=A0 =C2=A0 =C2=A0> would that type of scenario be negotiated in c= ontracts or could that
>=C2=A0 =C2=A0 =C2=A0> happen without the customer's knowledge? >
>=C2=A0 =C2=A0 =C2=A0To me it sounds like we've ventured away from t= he realm of protocol
>=C2=A0 =C2=A0 =C2=A0design and into the realm of contracts and SLAs. I&= #39;m not sure I see
>=C2=A0 =C2=A0 =C2=A0how we could put anything other than a "nota b= ene" about this in
>=C2=A0 =C2=A0 =C2=A0the text.
>
>
> I'm thinking more along the lines of a security warning, since the=
> data might go beyond where a customer thinks it is going.=C2=A0 It wou= ld be
> good for users to be aware of this possibility so they know if they > need to take precautions.=C2=A0 An N.B. is fine.=C2=A0 I didn't me= ant to imply
> that contracts should be mentioned with this, but rather that users > were aware and they might take that step because the security
> consideration was noted.
>

So this is like saying "if you send an email, somebody might forward i= t".
I'm not trying to be facetious but I'm struggling to understand why= this is
a particular feature of SCIM...

... or maybe we just decided to up the stakes a bit on privacy. I would be<= br> totally fine with that answer!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif


_______________________= ________________________
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




--

Best regards,
Ka= thleen
--001a11c382d02309970515e8a8a0-- From nobody Tue May 12 13:52:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06511AD160; Tue, 12 May 2015 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvOx5FMvvERJ; Tue, 12 May 2015 13:52:25 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC281AD094; Tue, 12 May 2015 13:52:05 -0700 (PDT) Received: by laat2 with SMTP id t2so15233614laa.1; Tue, 12 May 2015 13:52:04 -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=udO9//n+QxuJjcl1MLKJ3RO7hPtGTxTjecj5NG1W0Hc=; b=1Fpk2dtWtV+/zyaRy51qjZuGUqX2ZI7wW4o76fDUB5QNElweuiVhx17Z0tCGswwmPh XCQ0fcD9h1DL37Vng3P5qsxKnbU/XCtNL/n1pS7sq+lso2IDcW58IUej0ux2d6/t2aB+ iviuhfOg20lDKv0cgYsPTAtIWnUZ0QztRaDkDBc5/Z0L9KME/wUKi3bv8bptvPz/krRa FI4lemU9/tPFzHBZhfU3tAE7B9Rh0lOo+szkABEDieTb2dOR+qqxWbQpYU2sH4FXDLt5 uSdcyEOvHSOgO/tApqg6BwY41pVD2lWVtSnsZMTdoxdZ57l291AK0l6EOHD9BscRjYaE LvBg== MIME-Version: 1.0 X-Received: by 10.112.167.228 with SMTP id zr4mr13232968lbb.113.1431463924144; Tue, 12 May 2015 13:52:04 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 12 May 2015 13:52:04 -0700 (PDT) In-Reply-To: <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> Date: Tue, 12 May 2015 16:52:04 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c2432ab51df50515e8aaef Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , Barry Leiba , Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:52:27 -0000 --001a11c2432ab51df50515e8aaef Content-Type: text/plain; charset=UTF-8 On Tue, May 12, 2015 at 4:05 PM, Phil Hunt wrote: > I agree. > > Maybe what we want is an addition qualifier to the SLA statement that says > parties should also consider whether sharing with 3rd parties (e.g. > cloud-provider to partner or competing cloud-provider) is appropriate and > permissible? > That sounds great or just altering the scope statement in the intro. Thank you! Kathleen > > Phil > > phil.hunt@yahoo.com > > > On May 12, 2015, at 12:52 PM, Barry Leiba > wrote: > > > >> If the scope of SCIM is to allow this data to be transferred between > >> customers and their service providers, and from your service provider to > >> another one, why is there opposition to stating that clearly? > > > > If that's all you want said, there's no opposition. > > > > b > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > > -- Best regards, Kathleen --001a11c2432ab51df50515e8aaef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <phil.hunt@yahoo.com&= gt; wrote:
I agree.

Maybe what we want is an addition qualifier to the SLA statement that says = parties should also consider whether sharing with 3rd parties (e.g. cloud-p= rovider to partner or competing cloud-provider) is appropriate and permissi= ble?

That sounds great or just altering= the scope statement in the intro.

Thank you!
Kathleen=C2=A0

Phil

phil.hunt@yahoo.com

> On May 12, 2015, at 12:52 PM, Barry Leiba <barryleiba@computer.org> wrote:
>
>> If the scope of SCIM is to allow this data to be transferred betwe= en
>> customers and their service providers, and from your service provi= der to
>> another one, why is there opposition to stating that clearly?
>
> If that's all you want said, there's no opposition.
>
> b
>
> __________________= _____________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim




--
=

Best regards,
Kathleen
--001a11c2432ab51df50515e8aaef-- From nobody Tue May 12 15:30:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658221AD35B; Tue, 12 May 2015 15:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qC6WE_r6TH8; Tue, 12 May 2015 15:30:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328AE1A9092; Tue, 12 May 2015 15:30:33 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4CMUPt4018298 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 May 2015 22:30:25 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4CMUPcV025890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2015 22:30:25 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4CMUOFL023199; Tue, 12 May 2015 22:30:24 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 May 2015 15:30:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_CBECD6F7-3ED1-47A4-B380-05F77CD96B11" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Tue, 12 May 2015 15:30:19 -0700 Message-Id: <4A68153C-E0F2-45A2-8A04-0D0A6810F79F@oracle.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, Leif Johansson , draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , Barry Leiba , scim-chairs@ietf.org, "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:30:38 -0000 --Apple-Mail=_CBECD6F7-3ED1-47A4-B380-05F77CD96B11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Proposed additional text for the introduction: While the SCIM protocol and core schema specifications are intended to = cover point-to-point scenarios, implementers and deployers should = consider multi-hop and multi-party scenarios such as a service provider = acting as a general profile service for in-domain applications; as well = as, scenarios where a service provider in turn passes information to a = 3rd party service provider either by acting as a SCIM client or as a = SCIM service provider. Implementers and deployers should consider = carefully their service level agreements and privacy agreements when = distributing or propagating personal information (see also Section 9.3 = Privacy Considerations). Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 12, 2015, at 1:52 PM, Kathleen Moriarty = wrote: >=20 >=20 >=20 > On Tue, May 12, 2015 at 4:05 PM, Phil Hunt > wrote: > I agree. >=20 > Maybe what we want is an addition qualifier to the SLA statement that = says parties should also consider whether sharing with 3rd parties (e.g. = cloud-provider to partner or competing cloud-provider) is appropriate = and permissible? >=20 > That sounds great or just altering the scope statement in the intro. >=20 > Thank you! > Kathleen=20 >=20 > Phil >=20 > phil.hunt@yahoo.com >=20 > > On May 12, 2015, at 12:52 PM, Barry Leiba > wrote: > > > >> If the scope of SCIM is to allow this data to be transferred = between > >> customers and their service providers, and from your service = provider to > >> another one, why is there opposition to stating that clearly? > > > > If that's all you want said, there's no opposition. > > > > b > > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_CBECD6F7-3ED1-47A4-B380-05F77CD96B11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Proposed additional text for the = introduction:

While the = SCIM protocol and core schema specifications are intended to cover = point-to-point scenarios, implementers and deployers should consider = multi-hop and multi-party scenarios such as a service provider acting as = a general profile service for in-domain applications; as well as, = scenarios where a service provider in turn passes information to a 3rd = party service provider either by acting as a SCIM client or as a SCIM = service provider. Implementers and deployers should consider carefully = their service level agreements and privacy agreements when distributing = or propagating personal information (see also Section 9.3 Privacy = Considerations).


On May 12, 2015, at 1:52 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <phil.hunt@yahoo.com> = wrote:
I agree.

Maybe what we want is an addition qualifier to the SLA statement that = says parties should also consider whether sharing with 3rd parties (e.g. = cloud-provider to partner or competing cloud-provider) is appropriate = and permissible?

That sounds great or just altering the = scope statement in the intro.

Thank you!
Kathleen 

Phil

phil.hunt@yahoo.com

> On May 12, 2015, at 12:52 PM, Barry Leiba <barryleiba@computer.org> wrote:
>
>> If the scope of SCIM is to allow this data to be transferred = between
>> customers and their service providers, and from your service = provider to
>> another one, why is there opposition to stating that = clearly?
>
> If that's all you want said, there's no opposition.
>
> b
>
> = _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim




--

Best regards,
Kathleen
_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_CBECD6F7-3ED1-47A4-B380-05F77CD96B11-- From nobody Tue May 12 17:32:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B86C1A886E; Tue, 12 May 2015 17:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QUV7x65lDoD; Tue, 12 May 2015 17:32:02 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B691A885E; Tue, 12 May 2015 17:32:02 -0700 (PDT) Received: by qgej70 with SMTP id j70so13697042qge.2; Tue, 12 May 2015 17:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZUk+yzjXspNT8vDYV3vbMXILntC+EV39BtnXS8B1zYE=; b=i/Wk9bmU42tFPuKXClgOGCuIcHfUURJF0BVC3RCaASDU84oCd/jpTvf7p7iZEfWFaT rdkl+bV9DzI90+N97JxEa32NabkVIuaMcdElmLghGQozP38fHowF97unG/AGThXInIBq HRZ5Up6eFwEJli8cSmMsmRidOGOVnoxTYF+PsAEOPqlUF7wGZB697xTWVwAJnhFjOFlC 6kSLP50ZLf9WtZwa55eOh6IhPjwxpBe0BtnQIISLEV21AUBjYgMb8Q6Yhrm471YQ9Qzs c3isZvSM1Qxhy2iTJW/cv33ZgKklFPQWJWdNwH2U5g17YGpuKmuOKRFXgJra7v36pluU z3Vg== X-Received: by 10.55.20.159 with SMTP id 31mr38529939qku.64.1431477121837; Tue, 12 May 2015 17:32:01 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id i14sm14446068qkh.5.2015.05.12.17.32.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 17:32:00 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-E7772E13-CE81-4B73-BFC4-01BC0BD30246 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <4A68153C-E0F2-45A2-8A04-0D0A6810F79F@oracle.com> Date: Tue, 12 May 2015 20:31:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5B398707-2046-4D74-B036-6F17989798B6@gmail.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> <4A68153C-E0F2-45A2-8A04-0D0A6810F79F@oracle.com> To: Phil Hunt Archived-At: Cc: "draft-ietf-scim-core-schema.ad@ietf.org" , Leif Johansson , "draft-ietf-scim-core-schema@ietf.org" , "draft-ietf-scim-core-schema.shepherd@ietf.org" , The IESG , Barry Leiba , "scim-chairs@ietf.org" , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:32:04 -0000 --Apple-Mail-E7772E13-CE81-4B73-BFC4-01BC0BD30246 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That's great, thank you! Kathleen=20 Sent from my iPhone > On May 12, 2015, at 6:30 PM, Phil Hunt wrote: >=20 > Proposed additional text for the introduction: >=20 > While the SCIM protocol and core schema specifications are intended to cov= er point-to-point scenarios, implementers and deployers should consider mult= i-hop and multi-party scenarios such as a service provider acting as a gener= al profile service for in-domain applications; as well as, scenarios where a= service provider in turn passes information to a 3rd party service provider= either by acting as a SCIM client or as a SCIM service provider. Implemente= rs and deployers should consider carefully their service level agreements an= d privacy agreements when distributing or propagating personal information (= see also Section 9.3 Privacy Considerations). >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On May 12, 2015, at 1:52 PM, Kathleen Moriarty wrote: >>=20 >>=20 >>=20 >> On Tue, May 12, 2015 at 4:05 PM, Phil Hunt wrote: >>> I agree. >>>=20 >>> Maybe what we want is an addition qualifier to the SLA statement that sa= ys parties should also consider whether sharing with 3rd parties (e.g. cloud= -provider to partner or competing cloud-provider) is appropriate and permiss= ible? >>=20 >> That sounds great or just altering the scope statement in the intro. >>=20 >> Thank you! >> Kathleen=20 >>>=20 >>> Phil >>>=20 >>> phil.hunt@yahoo.com >>>=20 >>> > On May 12, 2015, at 12:52 PM, Barry Leiba wr= ote: >>> > >>> >> If the scope of SCIM is to allow this data to be transferred between >>> >> customers and their service providers, and from your service provider= to >>> >> another one, why is there opposition to stating that clearly? >>> > >>> > If that's all you want said, there's no opposition. >>> > >>> > b >>> > >>> > _______________________________________________ >>> > scim mailing list >>> > scim@ietf.org >>> > https://www.ietf.org/mailman/listinfo/scim >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail-E7772E13-CE81-4B73-BFC4-01BC0BD30246 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That's great, thank you!
Kathleen 

Sent from my iPhone

On May 1= 2, 2015, at 6:30 PM, Phil Hunt <p= hil.hunt@oracle.com> wrote:

Proposed additional text for the introduction:

While the SCIM protocol and core schema specifications a= re intended to cover point-to-point scenarios, implementers and deployers sh= ould consider multi-hop and multi-party scenarios such as a service provider= acting as a general profile service for in-domain applications; as well as,= scenarios where a service provider in turn passes information to a 3rd part= y service provider either by acting as a SCIM client or as a SCIM service pr= ovider. Implementers and deployers should consider carefully their service l= evel agreements and privacy agreements when distributing or propagating pers= onal information (see also Section 9.3 Privacy Considerations).
=

=
Phil

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

On M= ay 12, 2015, at 1:52 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> w= rote:



On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <phil.hunt@yahoo.com> wrote:
I agree.

Maybe what we want is an addition qualifier to the SLA statement that says p= arties should also consider whether sharing with 3rd parties (e.g. cloud-pro= vider to partner or competing cloud-provider) is appropriate and permissible= ?

That sounds great or just altering the scope statement in the intro.

Thank you!
Kathleen 

Phil

phil.hunt@yahoo.com

> On May 12, 2015, at 12:52 PM, Barry Leiba <barryleiba@computer.org> wrote:
>
>> If the scope of SCIM is to allow this data to be transferred betwee= n
>> customers and their service providers, and from your service provid= er to
>> another one, why is there opposition to stating that clearly?
>
> If that's all you want said, there's no opposition.
>
> b
>
> ___________________= ____________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim



<= div class=3D"">
--

Best reg= ards,
Kathleen
_______________________________________________
scim mailing l= ist
scim@ietf.org<= /a>
htt= ps://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail-E7772E13-CE81-4B73-BFC4-01BC0BD30246-- From nobody Tue May 12 17:37:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9C91A889A; Tue, 12 May 2015 17:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al6lYw1Jj3Wp; Tue, 12 May 2015 17:37:18 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7168A1A8886; Tue, 12 May 2015 17:37:18 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4D0bG34020339 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 May 2015 00:37:16 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4D0bFQ9012117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2015 00:37:16 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4D0bFMX023052; Wed, 13 May 2015 00:37:15 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 May 2015 17:37:15 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C17C617-0B3D-4BAE-AF85-A23A6615ACBB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <5B398707-2046-4D74-B036-6F17989798B6@gmail.com> Date: Tue, 12 May 2015 17:37:13 -0700 Message-Id: <55008D41-BD7F-4B7D-9EDB-19D5FD62090B@oracle.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> <4A68153C-E0F2-45A2-8A04-0D0A6810F79F@oracle.com> <5B398707-2046-4D74-B036-6F17989798B6@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "draft-ietf-scim-core-schema.ad@ietf.org" , Leif Johansson , "draft-ietf-scim-core-schema@ietf.org" , "draft-ietf-scim-core-schema.shepherd@ietf.org" , The IESG , Barry Leiba , "scim-chairs@ietf.org" , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:37:21 -0000 --Apple-Mail=_7C17C617-0B3D-4BAE-AF85-A23A6615ACBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Great! I will post tonight (pacific time) unless I see any -1s or other = proposed refinements. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 12, 2015, at 5:31 PM, Kathleen Moriarty = wrote: >=20 > That's great, thank you! >=20 > Kathleen=20 >=20 > Sent from my iPhone >=20 > On May 12, 2015, at 6:30 PM, Phil Hunt > wrote: >=20 >> Proposed additional text for the introduction: >>=20 >> While the SCIM protocol and core schema specifications are intended = to cover point-to-point scenarios, implementers and deployers should = consider multi-hop and multi-party scenarios such as a service provider = acting as a general profile service for in-domain applications; as well = as, scenarios where a service provider in turn passes information to a = 3rd party service provider either by acting as a SCIM client or as a = SCIM service provider. Implementers and deployers should consider = carefully their service level agreements and privacy agreements when = distributing or propagating personal information (see also Section 9.3 = Privacy Considerations). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On May 12, 2015, at 1:52 PM, Kathleen Moriarty = > wrote: >>>=20 >>>=20 >>>=20 >>> On Tue, May 12, 2015 at 4:05 PM, Phil Hunt > wrote: >>> I agree. >>>=20 >>> Maybe what we want is an addition qualifier to the SLA statement = that says parties should also consider whether sharing with 3rd parties = (e.g. cloud-provider to partner or competing cloud-provider) is = appropriate and permissible? >>>=20 >>> That sounds great or just altering the scope statement in the intro. >>>=20 >>> Thank you! >>> Kathleen=20 >>>=20 >>> Phil >>>=20 >>> phil.hunt@yahoo.com >>>=20 >>> > On May 12, 2015, at 12:52 PM, Barry Leiba > wrote: >>> > >>> >> If the scope of SCIM is to allow this data to be transferred = between >>> >> customers and their service providers, and from your service = provider to >>> >> another one, why is there opposition to stating that clearly? >>> > >>> > If that's all you want said, there's no opposition. >>> > >>> > b >>> > >>> > _______________________________________________ >>> > scim mailing list >>> > scim@ietf.org >>> > https://www.ietf.org/mailman/listinfo/scim = >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim = >>=20 --Apple-Mail=_7C17C617-0B3D-4BAE-AF85-A23A6615ACBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Great! I will post tonight (pacific time) unless I see any = -1s or other proposed refinements.


On May 12, 2015, at 5:31 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

That's great, = thank you!

Kathleen 

Sent from my = iPhone

On May 12, 2015, at 6:30 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Proposed additional text = for the introduction:

While the = SCIM protocol and core schema specifications are intended to cover = point-to-point scenarios, implementers and deployers should consider = multi-hop and multi-party scenarios such as a service provider acting as = a general profile service for in-domain applications; as well as, = scenarios where a service provider in turn passes information to a 3rd = party service provider either by acting as a SCIM client or as a SCIM = service provider. Implementers and deployers should consider carefully = their service level agreements and privacy agreements when distributing = or propagating personal information (see also Section 9.3 Privacy = Considerations).


On May 12, 2015, at 1:52 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <phil.hunt@yahoo.com> = wrote:
I agree.

Maybe what we want is an addition qualifier to the SLA statement that = says parties should also consider whether sharing with 3rd parties (e.g. = cloud-provider to partner or competing cloud-provider) is appropriate = and permissible?

That sounds great or just altering the = scope statement in the intro.

Thank you!
Kathleen 

Phil

phil.hunt@yahoo.com

> On May 12, 2015, at 12:52 PM, Barry Leiba <barryleiba@computer.org> wrote:
>
>> If the scope of SCIM is to allow this data to be transferred = between
>> customers and their service providers, and from your service = provider to
>> another one, why is there opposition to stating that = clearly?
>
> If that's all you want said, there's no opposition.
>
> b
>
> = _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim




--

Best regards,
Kathleen
_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


= --Apple-Mail=_7C17C617-0B3D-4BAE-AF85-A23A6615ACBB-- From nobody Tue May 12 21:54:06 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9851B1AC3AC; Tue, 12 May 2015 21:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JubKsotoihh; Tue, 12 May 2015 21:54:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 812CF1A0110; Tue, 12 May 2015 21:54:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513045400.17596.82085.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 21:54:00 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-20.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 04:54:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Phil Hunt Kelly Grizzle Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-20.txt Pages : 93 Date : 2015-05-12 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-core-schema-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 12 22:01:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA091AC3C7 for ; Tue, 12 May 2015 22:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otPm1AmUV9wD for ; Tue, 12 May 2015 22:01:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC3B1AC3B1 for ; Tue, 12 May 2015 22:01:37 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4D51aue014073 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 May 2015 05:01:36 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4D51Zk4004879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 May 2015 05:01:35 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4D51Zkf001723 for ; Wed, 13 May 2015 05:01:35 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 May 2015 22:01:35 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150513045400.17596.82085.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 22:01:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150513045400.17596.82085.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-20.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 05:01:39 -0000 This draft includes a new introductory paragraph that was requested = during the IESG review process. While the SCIM protocol and core schema specifications are intended to cover point-to-point scenarios, implementers and deployers should consider multi-hop and multi-party scenarios such as a service provider acting as a general profile service for in-domain applications; as well as, scenarios where a service provider in turn passes information to a 3rd party service provider either by acting as a SCIM client or as a SCIM service provider. Implementers and deployers should consider carefully their service level agreements and privacy agreements when distributing or propagating personal information (see also Privacy Considerations, Section 9.3). Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 12, 2015, at 9:54 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Phil Hunt > Kelly Grizzle > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-20.txt > Pages : 93 > Date : 2015-05-12 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) = specifications > are designed to make identity management in cloud based applications > and services easier. The specification suite builds upon experience > with existing schemas and deployments, placing specific emphasis on > simplicity of development and integration, while applying existing > authentication, authorization, and privacy models. Its intent is to > reduce the cost and complexity of user management operations by > providing a common user schema and extension model, as well as > binding documents to provide patterns for exchanging this schema > using HTTP protocol. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups and other resource types in JSON > format. This schema is intended for exchange and use with cloud > service providers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-scim-core-schema-20 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 13 00:32:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADFB1ACD8E for ; Wed, 29 Apr 2015 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKaep2YPCN0s for ; Wed, 29 Apr 2015 10:13:46 -0700 (PDT) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665991ACDB4 for ; Wed, 29 Apr 2015 10:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430327595; bh=T0rEUMcdS0Ve8Nwi+3Wb8Ow4E8sXkIL12Ml+5yvBlVQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=bR10zmv9fiKX9spjWwSPrwlo7N/hQwuK9jrDoB5RHXANfekUZJ/V7zz+9se74HWJtpQsx4fDNKP+k4ZshTsEltnKBLk24J1XpFb3hxsuX1t9WxruLHrOnaKKj5UE0YVp8knR6YyRCC301KIq7XLlOmvpFLYnhpoWMmMRlKVU834WMmygdZSwJeLUsYDrev1ueLuY91UWBOkhnsRphNdCivwQtcqDEoJU6xbG19ISh/3jnx9V+vtuiFFG9Lec+egVYJbp/3e3t3tvUQ817+5Fj/SiIr6f/ida+uALzTds+rNOoPDegMatfg5FN4JQw8Sv/4yNYDUXikPgJCT4WrJHWw== Received: from [98.138.226.177] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 17:13:15 -0000 Received: from [98.138.104.115] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 17:13:15 -0000 Received: from [127.0.0.1] by smtp224.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 17:13:15 -0000 X-Yahoo-Newman-Id: 100161.64156.bm@smtp224.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: u623B18VM1nNPLiNG5K19Bx14vk5sM2b4EIBlvIbd67ZlU1 5AbzX6LXJMFgQS732rFaC951rhBMeqlVNvlmNwKy_o5CNy0XjTqNAVWou5Hi Oh8QDI1OnTNtDAJ28VCEBa3rdVwSl3qAnx6f94oXDbNalVPuSb.lwuHh6VhF peGMDL67YwYuFKvNFIgIi.ihgktMDOCqCXMQVXjzlFaVpLEZeFhkPtrz2R6w oA1q6L06wU64tICb3b1wa9zerQYPaXgIBz9JTXW1MJkD_AEyYg_A23Pvze5M RFb_MAB6IJGOzKGQXYHYhZs3XU0KPJmIUh4zDYvD2EC_Iqf3cfhz95gZLFGS yEABnAY3oyGHdA30DdRNP5rXg3pxz2zgSV5A6FhxslDUk8tEQnsiQHLa47CH WKt6Q..wiZLK9tZl6ckNP1sLRjTONzApZguexzq2QG9wnkcjSwJm0BNTQh55 Gxi9vCY1qnl81dur_sZB8bRSt4gwAT0yq9xKlktVsmk2p4MCav2xtj2ntYnP 6KoMikoKZckRUxQTSX4MxOt9eCiBCFg-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> Date: Wed, 29 Apr 2015 10:13:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:13:48 -0000 Kathleen, Thanks for your comments. My comments in line=E2=80=A6 General comment. At the end of the day, SCIM is just an HTTP protocol = (an application) and as such can use any of the normal HTTP mechanisms. = In OAuth terms it is just a resource server. I wonder what we can point = to as a general best practice for authentication and authorization.=20 The use of OAuth was in part, a reflection of the growing popularity of = OAuth at the time of writing, and I believe a conscious attempt by the = original authors to discourage the use of simple password authentication = such as RFC2617=E2=80=99s basic authentication. For this reason we did = not want to use Basic in the examples. =20 Phil phil.hunt@yahoo.com > On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-scim-api-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft. I have a few items I'd like to > discuss and have provided suggestions to help the discussion. I think > this should be fairly easy to get through. >=20 > 1. OAuth is used for authorization and is limited to insecure methods = of > authentication via HTTP supported methods and of those, OAuth only has = a > few registered. HTTP Basic authentication is the default, which is > horrible. Later in this draft, SCIM encourages the use of asymmetric > crypto. Can this be the preferred option and there be more details > listed on how to do with (references)? >=20 > What is specified now is really an authorization protocol, so you'll = need > to say if HTTP Basic is what's used for authentication with OAuth > (default) or something else and then the security considerations for > OAuth bearer tokens and HHTP Basic. Here are some links to help: >=20 > A reference to security considerations from this draft will be needed: > see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions > Reference to the HTTP Basic draft will be needed to show the security > issues with this option: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >=20 > OAuth can't use something like HOBA in RFC7486, which was designed to > avoid the need for passwords when using HTTP Authentication. Can SCIM > work directly with other HTTP Auth methods like HOBA? The OAuth folks = are > thinking about this problem, but aren't there yet (non-password auth > methods to then use Oauth authorization tokens).=20 [PH] =20 The text suggests OAuth is recommended but not required reflects what = current implementers have been doing. I am opening to reducing this from = =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use other = equally secure mechanisms and to point out that the text based examples = use bearer tokens to illustrate the use of the authorization header and = are not normative. Regarding OAuth. I don=E2=80=99t see why OAuth can=E2=80=99t use HOBA. = OAuth doesn=E2=80=99t care how authentication happens only that the = parties are authenticated before authorizing. OAuth and for that matter = OIDC both depend on using traditional (and emerging) authentication = schemes to authenticate users. That said, I see no reason why SCIM could not work directly with HOBA. = SCIM does not care, it merely assumes clients are authenticated = (presumably via session cookie or the authorization header). Regarding asymmetric crypto, I believe you are referring to section 7.5. = See comment below... >=20 > 2. The Holder-of-Key Assertions would get you a lot more security than > the bearer token. Why are all the examples bearer token? Or is there = no > support for proof of possession of the key? [PH] SCIM has no specific attachment to any authorization format. We = just had to pick one. =20 Probably the one thing we should avoid is the use of Basic Auth as there = is a strong tendency by deployers to treat SCIM as being the equivalent = of LDAP and perpetuate the mis-use of LDAP Bind as an authentication = protocol as well as promoting the use of single-factor authentication. = I think a better approach is to emphasize that SCIM is just an HTTP = based Protocol (Application) and uses HTTP mechanisms for = authentication. =20 Maybe we need some text indicating the use of =E2=80=9CBearer=E2=80=9D = tokens are illustrative purposes and should not be considered normative. >=20 >=20 > 3. Section 7.1 > I'm guessing the text on TLS versions is old and this was overlooked = in > last call. The minimum version that should be supported is 1.2. TLS = 1.0 > is not considered a good starting point these days and browsers, such = as > Chrome show it as obsolete. The text on implementation information = for > TLS 1.2 is no longer correct, it's widely implemented and is pretty = much > the standard at the moment (1.3 will be soon enough). Referencing the > TLS BCP would be preferred, > https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/. It not only > starts from v1.2, but includes preferred algorithms and other > configuration/implementation details to avoid attacks. It is close to > final publication and is ahead int he queue of this draft. [PH] Agreed, we should update this.=20 >=20 > 4. Section 7.2 > Please review the Privacy Considerations, > https://tools.ietf.org/html/rfc6973. I was expecting to see more > specific guidance as to what needs to be protected and options to = protect > the data since there is quite a bit of personal information passed in > this protocol. We care about this for the protection of user's = privacy, > not just because it is required by laws. You can leave mention of the > laws out, but it would be helpful to be specific on options to protect > the data or options to leave out certain data elements to protect = privacy > (such as, make them optional or provide a way to encrypt/obscure, = etc.).=20 > RFC6973 will help with current guidance and IETF considerations. If = it > is a per element or attribute consideration, a pointer to that text = from > the privacy considerations section to the schema draft may be more > appropriate than covering the options in this draft. Then a better = TLS > option will help as well so the session is less subject to attacks. [PH] The core schema draft does have more information on privacy as it = is in the context of talking about attributes (which often have personal = information) rather than protocol. Would it be appropriate to explicitly call out the core schema security = considerations as foundational to the SCIM Protocol draft? >=20 > I see there is some text on privacy n the schema draft, but it's = probably > not enough. I'll read that within the next few days and give feedback = to > help improve the text. [PH] I will await your comments. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > This is really just here to see if better Authentication options are > possible in current implementations and guidance for SCIM. >=20 > Section 7.5 > While I like this bullet: > o Avoid passwords and consider use of asymmetric cryptography based > credentials. > Earlier in this draft the use of OAuth is specified, and the default = for > that is passwords via HTTP basic. If asymmetric crypto is an option, > can that be the preferred option? If it's possible, more detail on = how > to do that would be good as that's not a supported option with OAuth. [PH] The context of that comment was to avoid using =E2=80=9Cpassword=E2=80= =9D based authentication and instead use other approaches such as = asymmetric crypto approaches. Again this was an attempt to discourage = use of Basic Auth in favour of any other mechanism that uses crypto. For = example, Mutual-auth TLS would fit. There are many ways to fulfill = this, including TLS, HOBA, OAuth POP tokens and so on. BTW=E2=80=A6I know of nothing in OAuth that suggests HTTP Basic is the = default. I think the point of using OAuth is to keep SCIM specifically = out of doing authentication as per the charter. That said, there are = many other mechanisms equally workable. > Thanks! >=20 >=20 From nobody Wed May 13 00:32:28 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9E1A1A3D for ; Wed, 29 Apr 2015 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIRNN6GH76Nv for ; Wed, 29 Apr 2015 13:15:59 -0700 (PDT) Received: from nm18.bullet.mail.ne1.yahoo.com (nm18.bullet.mail.ne1.yahoo.com [98.138.90.81]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8433E1A1A3E for ; Wed, 29 Apr 2015 13:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430338555; bh=YcMVZCrobWeu/4d+jjwFuA0vMoMRDVbu/9jHhDwkwwk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=IFJoaSZ13qfhURbLDLbIn9gHEg51pqfAnf6dAL9PjDWn0gVKwb2Rs0aC4dh1OE/gFXQ5BfwyExRzp70rCy3qDXF145R4vPhTJRcTZFADT2Wd/NnPIpgml1gSygc74SWLv1NZg/MqYXOK1K9vuUY7fW+V8QbvN3A7bAPz3qvr6niiL3bHoSXCanySodFAMrHrwrkfyjn1BSFKxl5rOaDyoZrmBjL2u5i5NW4/WIy8jOhJypKZ1D4ExRPyN3LHJcLbGlxc/HIVg0brZPPOBpCiSB7Uchlo4FF3DntgEthMyovFx8wGdpWHp1l2mGol22AqKz42raSm2zvKcs7lpDpQGA== Received: from [98.138.226.176] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:15:55 -0000 Received: from [98.138.84.44] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:15:55 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:15:55 -0000 X-Yahoo-Newman-Id: 440473.33484.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zkEkpHkVM1kk0xZ0ZKsdrM1qgvOQd96ZOOeD6Ips7m6fknS Jx4FEyA6eZ21i0mzOieJ1R2hMf0.9K0XbNawFnw4JqodEiDSPQVnym3Jy95D _VRS7U_4CVHyHysj7J4TYYEoyAkeJaePM90VqcRKpa_9fQr.Ho6XYvbVbd0t rYuCWCe_hwA.l9W0.PBfrBGDDIpPEfeYhBZ2bl0ESzcL7whlKq0ubFL4rsy7 EoxxVJ3oNLFajRMJCI40KETphj6omgLk4UtDWO3y_2cBOdWSvT6RLiXw1Taf SJq6WXiqpi2GBtkuyGx.AXxV6q2WSiB40btxykhH.edBjpr0u_VHpnL10jyd n5ayma5GQ2IciTriMHtk7iMRd2GOHk2eLS.SRERPBfmDNuAxlym3n4k6cJFa cvkyUmismP4KorMt5VIRcUKd1AaUiGaR7JFlzIkC3oRi4wK81quFDeB_SlF0 aTETgS3hGQzj9aUokCfX07AUkmBDossE0j8sIXvAldTR53hYrF1my_V59OK1 f7eYAyOOVtEFqKXbhgogm1wtj7M54qg-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 29 Apr 2015 13:15:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> To: Kathleen Moriarty Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: "draft-ietf-scim-api.ad@ietf.org" , "scim@ietf.org" , "draft-ietf-scim-api.shepherd@ietf.org" , The IESG , "draft-ietf-scim-api@ietf.org" , "scim-chairs@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 20:16:01 -0000 Am I correct in assuming authentication is specifically excluded per the ch= arter. The assumption was/is SCIM uses typical http authen/authz schemes and= does not provide or mandate a method.=20 That said we have reservations about using 2617 mechanisms and prefer strong= er options.=20 Is this is the approach we are looking for?=20 Thanks, Phil > On Apr 29, 2015, at 13:08, Kathleen Moriarty wrote: >=20 > Phil and I chatted a bit and he is working up some text with specific > authentication options. I said I would look up some more references and a= m > providing them inline here. >=20 > On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: >=20 >> Hi Phil, >>=20 >> Just a quick response for now and more later. I'll find the specific >> references and registry for authentication used with OAuth. I'm the AD a= nd >> have been reading their drafts carefully. >>=20 >> Thanks, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >>> On Apr 29, 2015, at 1:13 PM, Phil Hunt wrote: >>>=20 >>> Kathleen, >>>=20 >>> Thanks for your comments. My comments in line=E2=80=A6 >>>=20 >>> General comment. At the end of the day, SCIM is just an HTTP protocol >> (an application) and as such can use any of the normal HTTP mechanisms. I= n >> OAuth terms it is just a resource server. I wonder what we can point to a= s >> a general best practice for authentication and authorization. >=20 > Yes, the issue I hit was that the text of this draft said that OAuth is th= e > authentication protocol, when it's only an authorization protocol. As > such, a reader might jump to a conclusion that HTTP Basic is the way to go= > since it's the first method (and default) for OAuth in the OAuth 2.0 > framework. Recent drafts that mention the same registry where the > supported authentication protocols from the client to the AS have not > updated that short list. If you could rewrite the text to specify > recommended authentication types, that would be good. >=20 > See section 2.3 of https://tools.ietf.org/html/rfc6749 > and the 3 methods defined are stated again in the dyn registry draft( > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically > saying to authenticate to use a token, these methods are available: >=20 > token_endpoint_auth_method > String indicator of the requested authentication method for the > token endpoint. Values defined by this specification are: >=20 > * "none": The client is a public client as defined in OAuth 2.0 > and does not have a client secret. > * "client_secret_post": The client uses the HTTP POST parameters > defined in OAuth 2.0 section 2.3.1. > * "client_secret_basic": the client uses HTTP Basic defined in > OAuth 2.0 section 2.3.1 >=20 > Additional values can be defined via the IANA OAuth Token Endpoint > Authentication Methods Registry established in Section 4.2. > Absolute URIs can also be used as values for this parameter > without being registered. If unspecified or omitted, the default > is "client_secret_basic", denoting HTTP Basic Authentication > Scheme as specified in Section 2.3.1 of OAuth 2.0. >=20 >=20 >=20 >=20 >>=20 >>> The use of OAuth was in part, a reflection of the growing popularity of >> OAuth at the time of writing, and I believe a conscious attempt by the >> original authors to discourage the use of simple password authentication >> such as RFC2617=E2=80=99s basic authentication. For this reason we did n= ot want to >> use Basic in the examples. >=20 > It's specified as the default in OAuth 2.0 when using a token. see above.= >=20 > Phil and I already chatted and he's planning to specify recommendations > that are more secure since SCIM can use other authentication methods. >=20 > Please take a look at the reference I gave that spells out the security > considerations for bearer tokens. They are not secure in of themselves an= d > require the use of TLS 1.2 to prevent attacks. This needs to be clearly > stated as well with a reference included to the draft I provided that > already details the risks with bearer tokens. >=20 > Thanks, > Kathleen >=20 >=20 >>>=20 >>> Phil >>>=20 >>> phil.hunt@yahoo.com >>>=20 >>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty < >> Kathleen.Moriarty.ietf@gmail.com> wrote: >>>>=20 >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-scim-api-17: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this= >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> Thanks for your work on this draft. I have a few items I'd like to >>>> discuss and have provided suggestions to help the discussion. I think >>>> this should be fairly easy to get through. >>>>=20 >>>> 1. OAuth is used for authorization and is limited to insecure methods o= f >>>> authentication via HTTP supported methods and of those, OAuth only has a= >>>> few registered. HTTP Basic authentication is the default, which is >>>> horrible. Later in this draft, SCIM encourages the use of asymmetric >>>> crypto. Can this be the preferred option and there be more details >>>> listed on how to do with (references)? >>>>=20 >>>> What is specified now is really an authorization protocol, so you'll >> need >>>> to say if HTTP Basic is what's used for authentication with OAuth >>>> (default) or something else and then the security considerations for >>>> OAuth bearer tokens and HHTP Basic. Here are some links to help: >>>>=20 >>>> A reference to security considerations from this draft will be needed: >>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions >>>> Reference to the HTTP Basic draft will be needed to show the security >>>> issues with this option: >>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >>>>=20 >>>> OAuth can't use something like HOBA in RFC7486, which was designed to >>>> avoid the need for passwords when using HTTP Authentication. Can SCIM >>>> work directly with other HTTP Auth methods like HOBA? The OAuth folks >> are >>>> thinking about this problem, but aren't there yet (non-password auth >>>> methods to then use Oauth authorization tokens). >>> [PH] >>>=20 >>> The text suggests OAuth is recommended but not required reflects what >> current implementers have been doing. I am opening to reducing this from >> =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use other equally= secure mechanisms >> and to point out that the text based examples use bearer tokens to >> illustrate the use of the authorization header and are not normative. >>>=20 >>> Regarding OAuth. I don=E2=80=99t see why OAuth can=E2=80=99t use HOBA. = OAuth doesn=E2=80=99t >> care how authentication happens only that the parties are authenticated >> before authorizing. OAuth and for that matter OIDC both depend on using >> traditional (and emerging) authentication schemes to authenticate users. >>>=20 >>> That said, I see no reason why SCIM could not work directly with HOBA. >> SCIM does not care, it merely assumes clients are authenticated (presumab= ly >> via session cookie or the authorization header). >>>=20 >>> Regarding asymmetric crypto, I believe you are referring to section 7.5=3D= From nobody Wed May 13 00:32:29 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B41A1ACF1A for ; Tue, 12 May 2015 13:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfGlXuAnCb6w for ; Tue, 12 May 2015 13:05:50 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8201AD05D for ; Tue, 12 May 2015 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431461135; bh=OSMTw2YxTheTl2JXiEII7MxQ3db3++VdPSmt3t4+z1g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=NOrmIiOYeibbTGrAdQur80rphg9emes9q3RllthrzM3BUD1Mqoub1Bxx6bkFHMJtAKpPWOeRi4aXoXTvUD7twQWQx3mPi6aCzrwt6CUxCc/rIvJP9j9G1KxSTPd6bpRto8kB/q0dMJ8ovQbfeEVn2jGNNkjeYo4/fDfMUnhZLGm3dEFxVVqEbB9mv6iW6HI81rVL2ZAb2hf+BBt9zP5cVDsN4qp8OFfNXJndnk5SapLepxhrzJlAFAXPjx0bwpUAR2cZ0kTZRBVSEi6bU4RJzqOF13P9+Bljn3vzolfSvu7fbLVm2OUiIkf4IU5rlL7i6ltFKiwpeI853a5GUOoMjA== Received: from [98.138.101.130] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2015 20:05:35 -0000 Received: from [98.138.226.132] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2015 20:05:35 -0000 Received: from [127.0.0.1] by smtp219.mail.ne1.yahoo.com with NNFMP; 12 May 2015 20:05:35 -0000 X-Yahoo-Newman-Id: 666973.22524.bm@smtp219.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mQ7n9I4VM1mkEES6dfi2Ep4LQjlk4Qd1eMCFWNQLOMHpgzO YI6DcLHgScn0ZF3riBhYkl_xcRnlz5iXsPUuPSoOlZOPufLq_qZGvnykbqC7 ox4PMGlHgWzNtre7.arEByc0smhyC1_HuPasELgGJaCkXW0K.bHb7Lf3Wpji zrvNeOTILuakeRlivR2TD1.XAO4wCx4omZMeG.3jrbd0GNDzTe4FDiz0.Vug 8v0jHp.RDT.37tFHBHDAJSTFobvBs9mze7.UPPg8kjWKmREtGeoZE5oU0hSi gFCVzOsjqnQHPpTGeTn7mQ6dw_WO5nqnJlNvnYXpnN_lB.TjTxA6vcOVLgWE Yl_z2HThR9JRdIuuMjbEoqaS_4vOxpfASompItHC.po1B3A3TZOr24JmOIa2 VeDBjKNhnIrrgmUccN2uF0D0uqYwpm61W5jNfJINSIP4iW4iwuc72dUwSTfU aqU.EWSzlVtzd6X9IU9mRIADppfsP3hDPISJ..RloHAta7eycnrGGf1rAHFS _5L5sqTKmFfqQ2Vs.WBZKR3D9xLdZi1ibRg-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Tue, 12 May 2015 13:05:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D639E01-67FC-48C7-9CD9-B2E9592447AC@yahoo.com> References: <20150512004539.18327.91294.idtracker@ietfa.amsl.com> <55524D3F.40802@sunet.se> <55525022.6040701@sunet.se> To: Barry Leiba X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: draft-ietf-scim-core-schema.ad@ietf.org, scim-chairs@ietf.org, draft-ietf-scim-core-schema@ietf.org, Kathleen Moriarty , draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:05:51 -0000 I agree.=20 Maybe what we want is an addition qualifier to the SLA statement that = says parties should also consider whether sharing with 3rd parties (e.g. = cloud-provider to partner or competing cloud-provider) is appropriate = and permissible? =20 Phil phil.hunt@yahoo.com > On May 12, 2015, at 12:52 PM, Barry Leiba = wrote: >=20 >> If the scope of SCIM is to allow this data to be transferred between >> customers and their service providers, and from your service provider = to >> another one, why is there opposition to stating that clearly? >=20 > If that's all you want said, there's no opposition. >=20 > b >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 13 00:32:30 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AE21A9050; Tue, 12 May 2015 19:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYYjSA9adAOs; Tue, 12 May 2015 19:35:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5789E1A9028; Tue, 12 May 2015 19:35:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 19:35:01 -0700 Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: draft-ietf-scim-api.ad@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org, scim@ietf.org Subject: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 02:35:02 -0000 Ben Campbell has entered the following ballot position for draft-ietf-scim-api-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -- 3.4.2: "SHOULD ignore any query parameters they do not understand" I'm curious why this is not a MUST. What are the alternatives--that is, can you envision situations where it might be reasonable to _not_ ignore parameters you don't understand? -- 3.4.2.2, reference to [Order-Operations] As written, that needs to be a normative reference. That's problematic for a reference to wikipedia, since articles are extremely changeable. Furthermore, the referenced article doesn鈥檛 indicate one true operator precedence for programming languages. If the rest of the paragraph fully defines the precedence, I suggest saying 鈥淢UST鈥 according to the following鈥, and making the reference truly informational (or even dropping it entirely.) -- 3.8: The first paragraph says servers MUST respond with JSON in UTF-8. But the following paragraphs talk about how the client may request different response formats. This seems contradictory. -- 3.13: It's optional (MAY) to include the API version. If the version is missing, the service provider SHOULD perform the operation using the most recent supported version. This seems to allow the client and service provider to disagree on the version being used. Does this cause an interop problem if the later version is not backwards compatible? (Are all new versions expected to be backwards compatible with old versions?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- General: There seems to be a pervasive use of 2119 keywords in ways that seem like statements of fact, rather than normative requirements. This is especially true with MAY, where it seems like people may have gotten into the habit of capitalizing every occurrence of the word. I've called out a number of instances below, but probably didn't catch them all. -- 1.3, 3rd paragraph: The paragraph is indented as if part of the definition of "Base URI". I suspect that is not the intent. "It is expected that SCIM servers MAY...": Is the normative MAY intentional? It's odd to see a 2119 keyword following a phrase like "It is expected..." -- 2, Basic Authentication: "Implementers SHOULD combine the use of basic authentication with other factors": Do you mean that they SHOULD NOT use basic _without_ combining it with other factors? If so, that is subtly different than the text as written. -- 2.1, last paragraph: Just SHOULD? Do you invision situations where it might be reasonable _not_ to take the threats into account? Also, the reference to oath-assertions needs to be normative -- 2.2, "... it MAY be acceptable" This seems more a statement of fact than a normative assertion. -- 3.1, 2nd paragraph "... a JSON object that MAY be created...", "in cases where SCIM MAY be used...", "reasonable to expect that some service providers MAY only support" s/MAY/may -- 3.1, 3rd paragraph: "... implementations MAY vary": Should not be normative. "... techniques such as document validation...are not recommended.": Maybe that one _should_ be normative. "... a SCIM client SHOULD NOT expect...": Probably should not be normative. (But if it really is intended as normative, when might a client reasonably choose to violate it?) -- 3.3, 3rd bullet: How does a service provider know which attributes a client understands? -- 3.4.2, totalResults: "... SHALL NOT be equal..." Never? Is it never possible that all results fit into one "page"? Perhaps this should have been a non-normative "might not be equal"? -- 3.4.1.2, paragraph starting with "A query against a server root..." What is the significance of "ALL" in caps? -- 3.4.2.2, "... the the resource MUST match if any of the instances of the given attribute match the specified criterion..." That seems like a statement of fact. (e.g. "the resource matches if..." -- 3.4.2.4, 1st paragraph: "clients SHOULD never assume repeatable results" That seems like a statement of fact, not a normative assertion. -- 3.5.1, 1st paragraph: "Clients that MAY have..." : s/MAY/may -- table 8, tooMany: "... MAY not be acceptable..." As worded, that sounds like a statement of fact. -- 7.3: That needs to be a normative reference. Also, why is this a SHOULD? Can you envision scenarios where it might be reasonable for implementors NOT to take the countermeasures into account? -- 7.4: Reference to oauth-assertions needs to be normative. -- 7.6, 2nd bullet s/MAY/may -- editorial -- 2, HOBA paragraph: Is this intended as part of the TLS Client Authentication entry? It doesn't seem so, but the paragraph lacks its own heading. 3.2, 1st paragraph, sentence starting with "Given there are cases..." Sentence fragment. -- 3.3, first two bullet list entries The "For" at the beginning of both entries does not fit the rest of the sentence structure. From nobody Wed May 13 00:32:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208681A00F9 for ; Tue, 12 May 2015 21:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzgQtz93t5wh for ; Tue, 12 May 2015 21:46:03 -0700 (PDT) Received: from nm22-vm2.bullet.mail.ne1.yahoo.com (nm22-vm2.bullet.mail.ne1.yahoo.com [98.138.91.210]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927F41A0100 for ; Tue, 12 May 2015 21:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431492358; bh=e7LVqnnAeEmPZ/dyjAZ5JCuB2G7XTmRfYK7lqrHgXuo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=XXmgzwsDMLgDiYyOVIv6+wf/sVupfssUklntm9PZ+mKYWkUs5Q4P11/aRq63tvt1TvV5WZ4apgYeI1v5/ViCCI6GCjaZXM/x0z69l1CO5CXaRjn28SkpvItIke9NF6T4CT37aYY19iCjoP/iRsNkXanykG/AXH0lL7YaFayAX+7ZnFXZjH4RXVkTBZCKVC1YLmjPoz+koCcW5t1Oo9JGiE/SfTbkFnQafTiTibU7+mK6YNFLE6kBqPALEQOdZf/nm44q3T9eV+Btnifc/oEPl4QswwvjCJtKhfG9YBO7yzqCxXe89yQVgs3qPefMesw5OBKAoKA8/IrspMqM5FH60A== Received: from [98.138.226.178] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 13 May 2015 04:45:58 -0000 Received: from [98.138.84.44] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 May 2015 04:45:58 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 13 May 2015 04:45:58 -0000 X-Yahoo-Newman-Id: 135739.73133.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ly81IMoVM1nadfWVvrUnp3NLC7Ttzbgg4S7Nz951cnezMFQ teX2Bm2hW_TGbL1PkKElnm8bcJnqjWV5coetCPuTKPx02sM94b8NQIvrNQ4X kHTmTBPi3D_CdTlmvxJJ3uWKsaDP9GenGMQ6JUwhCmYjxrXtaKe5Y_0dLQ_z 3HXgQfsNne4rhrDr8Fy0ghNWq6jlCzNR9jhvu34x2yK.LS.gbeoO7o78sym8 S76uON_DiwSQ8osoZI9XsI70XLFnCsjgBNlxlK0OMOEY9oq4JEaIscSdlUKI yxw9rDa59OTGNSHgxUNXD0Dt7sAJgGAKzi9jf4WWWAiWPNLwWAXtt6AVhC4c Wf1RRu2kua60I7o1vw6h6xlR5kxhPu2fLTneppfLxVtIF72IEGkBcFVg9r6D juTp3gpgx5IO_7jp8m8oq9U7JD9Hq7GSwHhI_XutkHdgfd0bZSE66xbAZC8H HdZw0ididM7Jt56g3TEujhzv_1F5bsHOd7.9pguQp1WkirxcTJfVkfXU64I. JPjsiUyIf5X9s.X76gckxRw-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 21:45:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 04:46:05 -0000 Ben, Thanks for the extensive comments. If I have not commented below, = please assume I am agreeing and will make the change. Phil phil.hunt@yahoo.com > On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-scim-api-18: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > -- 3.4.2: "SHOULD ignore any query parameters they do not understand" >=20 > I'm curious why this is not a MUST. What are the alternatives--that = is, > can you envision situations where it might be reasonable to _not_ = ignore > parameters you don't understand? The currently unstated opposite is that a server might choose to reject = the request. I believe the preference is for servers to ignore what they = do not understand for upward compatibility reasons. MUST ignore seems = to harsh. >=20 > -- 3.4.2.2, reference to [Order-Operations] >=20 > As written, that needs to be a normative reference. That's problematic > for a reference to wikipedia, since articles are extremely changeable. > Furthermore, the referenced article doesn=E2=80=99t indicate one true = operator > precedence for programming languages. If the rest of the paragraph = fully > defines the precedence, I suggest saying =E2=80=9CMUST=E2=80=A6 = according to the > following=E2=80=9D, and making the reference truly informational (or = even > dropping it entirely.) >=20 > -- 3.8: >=20 > The first paragraph says servers MUST respond with JSON in UTF-8. But = the > following paragraphs talk about how the client may request different > response formats. This seems contradictory. I will adjust. I think some service providers may wish to support other = formats. I don=E2=80=99t think it is our intent to limit here, just that = other formats are beyond scope. >=20 > -- 3.13: >=20 > It's optional (MAY) to include the API version. If the version is > missing, the service provider SHOULD perform the operation using the = most > recent supported version. This seems to allow the client and service > provider to disagree on the version being used. Does this cause an > interop problem if the later version is not backwards compatible? (Are > all new versions expected to be backwards compatible with old = versions?) See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > -- General: There seems to be a pervasive use of 2119 keywords in ways > that seem like statements of fact, rather than normative requirements. > This is especially true with MAY, where it seems like people may have > gotten into the habit of capitalizing every occurrence of the word. = I've > called out a number of instances below, but probably didn't catch them > all. >=20 > -- 1.3, 3rd paragraph: >=20 > The paragraph is indented as if part of the definition of "Base URI". = I > suspect that is not the intent. This one could go either way. I will set it outside the list. >=20 > "It is expected that SCIM servers MAY...": Is the normative MAY > intentional? It's odd to see a 2119 keyword following a phrase like = "It > is expected=E2=80=A6" >=20 > -- 2, Basic Authentication: >=20 > "Implementers SHOULD combine the use of basic authentication with = other > factors": Do you mean that they SHOULD NOT use basic _without_ = combining > it with other factors? If so, that is subtly different than the text = as > written. >=20 > -- 2.1, last paragraph: >=20 > Just SHOULD? Do you invision situations where it might be reasonable > _not_ to take the threats into account? >=20 > Also, the reference to oath-assertions needs to be normative I=E2=80=99m not sure what you are referring to. paragraph 1 of 2.1 = refers to section 6 of the OAuth Assertions Draft. The last paragraph = does not refer to it. >=20 > -- 2.2, "... it MAY be acceptable" >=20 > This seems more a statement of fact than a normative assertion. >=20 > -- 3.1, 2nd paragraph "... a JSON object that MAY be created...", "in > cases where SCIM MAY be used...", "reasonable to expect that some = service > providers MAY only support" >=20 > s/MAY/may >=20 > -- 3.1, 3rd paragraph: >=20 > "... implementations MAY vary": Should not be normative. > "... techniques such as document validation...are not recommended.": > Maybe that one _should_ be normative. > "... a SCIM client SHOULD NOT expect...": Probably should not be > normative. (But if it really is intended as normative, when might a > client reasonably choose to violate it?) >=20 >=20 > -- 3.3, 3rd bullet: >=20 > How does a service provider know which attributes a client = understands? This was a compromise resolution to a problem in REST that the WG ran = into. What does it mean when a client does not assert a value? Is it the = intention that the client wants the value cleared (by not asserting it), = is the client saying nothing, or does the client expect it to be = defaulted. Then there is the issue that access control might be filtering what the = client can set or in the response, what can be returned to the client. = In other words, the client may not be intending to clear a value because = it may not even know about the attribute. I=E2=80=99ve never been happy with the proposed paragraph and would = invite alternate proposals. >=20 > -- 3.4.2, totalResults: "... SHALL NOT be equal..." >=20 > Never? Is it never possible that all results fit into one "page"? = Perhaps > this should have been a non-normative "might not be equal=E2=80=9D? Agreed >=20 > -- 3.4.1.2, paragraph starting with "A query against a server root=E2=80= =A6" >=20 > What is the significance of "ALL" in caps? We really really mean all. :-) Will make it lower case. =20 >=20 > -- 3.4.2.2, "... the the resource MUST match if any of the instances = of > the given attribute match the specified criterion..." >=20 > That seems like a statement of fact. (e.g. "the resource matches = if=E2=80=A6" Agreed. It is awkward. I will rephrase. >=20 > -- 3.4.2.4, 1st paragraph: "clients SHOULD never > assume repeatable results" >=20 > That seems like a statement of fact, not a normative assertion. Not sure I agree. It is normative in that clients must be prepared to = handle inconsistent results during paging. Maybe we can rephrase around = the issue? >=20 > -- 3.5.1, 1st paragraph: >=20 > "Clients that MAY have..." : s/MAY/may >=20 > -- table 8, tooMany: "... MAY not be acceptable..." >=20 > As worded, that sounds like a statement of fact. >=20 > -- 7.3: >=20 > That needs to be a normative reference. Also, why is this a SHOULD? = Can > you envision scenarios where it might be reasonable for implementors = NOT > to take the countermeasures into account? Well they might not be using OAuth tokens. My understanding since OAuth is optional, it should not be a normative = reference. Also, the assertions draft is a work in progress. >=20 > -- 7.4: >=20 > Reference to oauth-assertions needs to be normative. Again, OAuth is optional.=20 Regarding all of the authentication methods described, since they are = all optional I have made them all informative unless every = implementation MUST support it (e.g. because SCIM depends on it). Correct me if this is editorially incorrect. >=20 > -- 7.6, 2nd bullet >=20 > s/MAY/may >=20 > -- editorial >=20 > -- 2, HOBA paragraph: >=20 > Is this intended as part of the TLS Client Authentication entry? It > doesn't seem so, but the paragraph lacks its own heading. My thinking was it is a profile/variation of TLS client authentication. = IOW the only thing that is different is how the keys are = managed/distributed. I am open to calling it out as a separate item. >=20 >=20 > 3.2, 1st paragraph, sentence starting with "Given there are cases..." >=20 > Sentence fragment. Agreed. Will rephrase. >=20 > -- 3.3, first two bullet list entries >=20 > The "For" at the beginning of both entries does not fit the rest of = the > sentence structure. Will rephrase. >=20 >=20 From nobody Wed May 13 00:32:33 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5444D1AC3C7; Tue, 12 May 2015 22:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzAeLbUjBCmU; Tue, 12 May 2015 22:22:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2671A0222; Tue, 12 May 2015 22:22:29 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4D5MHOF086608 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 00:22:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Phil Hunt" Date: Wed, 13 May 2015 00:22:17 -0500 Message-ID: <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> In-Reply-To: <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 00:32:24 -0700 Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 05:22:32 -0000 Thanks for the quick response. I am okay with your responses to all the DISCUSS points save the last, and I am only holding that one for a bit more discussion. (That is, I will probably clear regardless of your response.) Details inline. I deleted sections that did not appear to need further discussion. On 12 May 2015, at 23:45, Phil Hunt wrote: > Ben, > > Thanks for the extensive comments. If I have not commented below, > please assume I am agreeing and will make the change. > > Phil > > phil.hunt@yahoo.com > >> On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-scim-api-18: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> -- 3.4.2: "SHOULD ignore any query parameters they do not understand" >> >> I'm curious why this is not a MUST. What are the alternatives--that >> is, >> can you envision situations where it might be reasonable to _not_ >> ignore >> parameters you don't understand? > > The currently unstated opposite is that a server might choose to > reject the request. I believe the preference is for servers to ignore > what they do not understand for upward compatibility reasons. MUST > ignore seems to harsh. Okay, that makes sense. Some guidance to that effect would be helpful, but I won't hold the discuss on that. > [...] >> >> -- 3.8: >> >> The first paragraph says servers MUST respond with JSON in UTF-8. But >> the >> following paragraphs talk about how the client may request different >> response formats. This seems contradictory. > > I will adjust. I think some service providers may wish to support > other formats. I don鈥檛 think it is our intent to limit here, just > that other formats are beyond scope. Okay >> >> -- 3.13: >> >> It's optional (MAY) to include the API version. If the version is >> missing, the service provider SHOULD perform the operation using the >> most >> recent supported version. This seems to allow the client and service >> provider to disagree on the version being used. Does this cause an >> interop problem if the later version is not backwards compatible? >> (Are >> all new versions expected to be backwards compatible with old >> versions?) > > See previous comment on ignoring what is not understood. My > understanding this is one of those common practices that goes > underspecified. Happy to take suggestions here. I think this is different than in the previous comment. If a certain combination of method and attributes means something different in version N and version N+1, and the client and server leaves out the version, thinks could break. My suggestion would be to always include the version--but I understand there might be other reasons not to. An alternative would be to give guidance about backwards compatibility. (Even non-normative guidance in the form of "if you do this things might break" would help.) >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> [...] >> >> -- 2.1, last paragraph: >> >> Just SHOULD? Do you invision situations where it might be reasonable >> _not_ to take the threats into account? >> >> Also, the reference to oath-assertions needs to be normative > I鈥檓 not sure what you are referring to. paragraph 1 of 2.1 refers > to section 6 of the OAuth Assertions Draft. The last paragraph does > not refer to it. >> Are we looking at the same version (18)? I see the last paragraph of 2.1 as the following: "Implementers SHOULD take into account the threats and countermeasuresdocumented in the security considerations for the use of clientauthorizations see Section 8 of [I-D.ietf-oauth-assertions]." [...] >> -- 3.3, 3rd bullet: >> >> How does a service provider know which attributes a client >> understands? > > This was a compromise resolution to a problem in REST that the WG ran > into. What does it mean when a client does not assert a value? Is it > the intention that the client wants the value cleared (by not > asserting it), is the client saying nothing, or does the client expect > it to be defaulted. > > Then there is the issue that access control might be filtering what > the client can set or in the response, what can be returned to the > client. In other words, the client may not be intending to clear a > value because it may not even know about the attribute. > > I鈥檝e never been happy with the proposed paragraph and would invite > alternate proposals. The "client has access to" part is easier to understand, since the service provider presumably knows what attributes it sent, or will send, to the client. Would it make sense to just delete the phrase ", or understands,"? [...] >> >> -- 3.4.2.4, 1st paragraph: "clients SHOULD never >> assume repeatable results" >> >> That seems like a statement of fact, not a normative assertion. > > Not sure I agree. It is normative in that clients must be prepared to > handle inconsistent results during paging. Maybe we can rephrase > around the issue? > How about "clients MUST be prepared to handle inconsistent results..." :-) [...] >> >> -- 7.3: >> >> That needs to be a normative reference. Also, why is this a SHOULD? >> Can >> you envision scenarios where it might be reasonable for implementors >> NOT >> to take the countermeasures into account? > > Well they might not be using OAuth tokens. > > My understanding since OAuth is optional, it should not be a normative > reference. Even if a feature is optional, a reference that is needed to understand and/or implement the feature should still be normative. > Also, the assertions draft is a work in progress. I understand that is an issue, but it's not appropriate (or even beneficial) to avoid a normative reference due to a dependency block. The whole point of that bit of inconvenience is to make sure an RFC doesn't depend on a moving target in order for a feature to be understood or implemented. >> >> -- 7.4: >> >> Reference to oauth-assertions needs to be normative. > > Again, OAuth is optional. > > Regarding all of the authentication methods described, since they are > all optional I have made them all informative unless every > implementation MUST support it (e.g. because SCIM depends on it). > > Correct me if this is editorially incorrect. IMHO, it is editorially incorrect. Please see my previous comments on 7.3. But in any case, I am not holding a discuss on these points--I will leave it to Barry to decide how to proceed. > >> >> -- 7.6, 2nd bullet >> >> s/MAY/may >> >> -- editorial >> >> -- 2, HOBA paragraph: >> >> Is this intended as part of the TLS Client Authentication entry? It >> doesn't seem so, but the paragraph lacks its own heading. > > My thinking was it is a profile/variation of TLS client > authentication. IOW the only thing that is different is how the keys > are managed/distributed. > > I am open to calling it out as a separate item. That's okay with me if it was the intent. [...] From nobody Wed May 13 09:03:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26381B2FEB; Wed, 13 May 2015 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-cQvsCZqQxB; Wed, 13 May 2015 09:03:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1171B3030; Wed, 13 May 2015 09:03:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513160321.8743.58528.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 09:03:21 -0700 Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org, scim@ietf.org Subject: [scim] Stephen Farrell's No Objection on draft-ietf-scim-api-18: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:03:23 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-scim-api-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Feel free to ignore any of these that overlap with earlier comments, I've not been following all discussion on this one. - section 2 says that bearer tokens based on no authenticaton may be used (as the exception to the "SHOULD NOT be used"). Why is that ok? Maybe s/SHOULD NOT/MUST NOT/ here would be better and justified? - 3.1: seems odd to define schema but then say it's entirely fine to ignore all of that - or am I reading this wrong? - p9, figures and tables should have captions and be numbered and this looks like a table of HTTP methods (not "operations") that has neither. - general: I came across a bunch of places where some forward reference would help (e.g. 3.3 assumes I get what readOnly means; 3.4.2.1 does the same for a "json attribute"). An editing pass to try improve that before the RFC editor would be good I think. - 3.4.2 says: "This SHALL NOT be equal to the number of elements in the resources attribute of the list response if pagination (Section 3.4.2.4) is requested. " What if I ask for pagination with 10 per page and there are a total of 10 matching results? That SHALL NOT seems broken. - 3.4.2.2: Is "pr()" true when a client didn't send a value to the server at creation time but the server included the default value in the response to the PUT? (And what happens to pr() and eq() when the default value changes?) - 3.4.2.2, p21: eq() is case insensitive? I think you badly need a fwd ref to sections 3.8 and 5. - 7.4, para 2 looks truncated From nobody Wed May 13 09:37:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CDE1B2FFC; Wed, 13 May 2015 09:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExKVu_bplsrb; Wed, 13 May 2015 09:37:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB671B2EA9; Wed, 13 May 2015 09:37:26 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4DGbH3i022440 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 May 2015 16:37:17 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4DGbGI6022114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2015 16:37:17 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4DGbGJV007833; Wed, 13 May 2015 16:37:16 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 May 2015 09:37:14 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150513160321.8743.58528.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 09:37:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150513160321.8743.58528.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Stephen Farrell's No Objection on draft-ietf-scim-api-18: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:37:36 -0000 Stephen, Thanks for your comments. Replies in line. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 13, 2015, at 9:03 AM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-scim-api-18: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Feel free to ignore any of these that overlap with earlier > comments, I've not been following all discussion on this one. >=20 > - section 2 says that bearer tokens based on no authenticaton > may be used (as the exception to the "SHOULD NOT be used"). > Why is that ok? Maybe s/SHOULD NOT/MUST NOT/ here would be > better and justified? >=20 > - 3.1: seems odd to define schema but then say it's entirely > fine to ignore all of that - or am I reading this wrong? I am always afraid of saying never in these cases as scenarios always = change. For example, as denial-of-service protection mechanism, an = authorization server might issue a single-use token that marks a session = with an anonymous client. That might then be used by the client to = perform what would otherwise be an anonymous self-registration. The problem hear is the common confusion of authentication of users as a = separate thing from session authentication. This example might not be correct or incorrect depending on how you = define authentication. Regardless, it just felt that limiting without = reason was inappropriate. That said, I am open to changing this wording to something better. >=20 > - p9, figures and tables should have captions and be numbered > and this looks like a table of HTTP methods (not > "operations") that has neither. I could convert this to a table. Right now it is merely a >=20 > - general: I came across a bunch of places where some forward > reference would help (e.g. 3.3 assumes I get what readOnly > means; 3.4.2.1 does the same for a "json attribute"). An > editing pass to try improve that before the RFC editor would > be good I think. Sounds good. >=20 > - 3.4.2 says: "This SHALL NOT be equal to the number of > elements in the resources attribute of the list response if > pagination (Section 3.4.2.4) is requested. " What if I ask > for pagination with 10 per page and there are a total of 10 > matching results? That SHALL NOT seems broken. I=E2=80=99ve got this on my list from Ben=E2=80=99s review/discuss. >=20 > - 3.4.2.2: Is "pr()" true when a client didn't send a value > to the server at creation time but the server included the > default value in the response to the PUT? (And what happens > to pr() and eq() when the default value changes?) Not sure if we need an additional note.=20 But I would assume defaulted values are applied and fixed when a server = updates its stateful representation of the entity. Thus a subsequent = search would involve testing the attribute's state which may be actual = or defaulted. =46rom an inter-operability perspective, I wonder if this matters. If = SCIM is in front of an application (e.g. CRM), then would it be ok for = the data mapping to apply its own rules in the context of the = application? >=20 > - 3.4.2.2, p21: eq() is case insensitive? I think you badly > need a fwd ref to sections 3.8 and 5. Sure. >=20 > - 7.4, para 2 looks truncated Looks like para 2 needs to be snipped. >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 13 14:19:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942081ACE2E; Wed, 13 May 2015 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id necfQpMUiOKX; Wed, 13 May 2015 14:19:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE161ACE56; Wed, 13 May 2015 14:19:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513211921.24391.24472.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 14:19:21 -0700 Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, scim-chairs@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org Subject: [scim] Ben Campbell's Discuss on draft-ietf-scim-core-schema-20: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:19:37 -0000 Ben Campbell has entered the following ballot position for draft-ietf-scim-core-schema-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hopefully this one will be easy to address: Section 4.1.1, under "password", says that passwords SHOULD be hashed or encrypted. But the security considerations say that passwords MUST NOT be stored in clear-text. These seem to be in conflict. (I prefer the MUST NOT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- General: As in the API draft, there's quite a bit of misuse of the 2119 "MAY" keyword (details below.) -- 1.1, 3rd paragraph: "... all figures MAY contain spaces." s/MAY/may -- 2.1, 2nd paragraph : "MAY be camel-case" Seems like if they are case insensitive, they can be any case. -- 2.1, last paragraph: "... MAY need to be escaped..." s/MAY/may -- 2.2, 2nd bullet: I assume this refers to the value/content of the attribute, since the previous section said the attribute name is always case insensitive. -- 2.3.4: integer is defined as a _decimal_ number that MUST NOT contain fractional or exponent parts. But the definition of 鈥淒ecimal鈥 says it has to have at least one digit to the right of the period. Do these conflict? Do Integers always need a trailing zero after a period? (I suspect the answer is that you didn鈥檛 mean to say Integer was derived from Decimal, but if so, the use of 鈥渄ecimal鈥 is confusing.) -- 2.3.7, 2nd to last paragraph, first sentence: To whom does this requirement apply? It sounds like an attempt to apply a MUST to whatever service a reference happens to refer to. I gather that could be any arbitrary service addressable with a URL. -- 2.4, paragraph after bullet list : "The pre-defined set of sub-attributes for a multi-valued attribute" I鈥檓 not sure what that means. These are the only sub-attrs that can be used? All multi-valued attributes have these sub-attributes? -- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED attribute that MUST be present" The REQUIRED and MUST are redundant. -- 3.1, first paragraph, last sentence: "SHALL NOT be considered schema extensions." Should this really be normative? Does 鈥渃onsidering them a schema extension鈥 involve observable implementation behavior differences? -- 3.1, meta/resourceType: "The attribute is REQUIRED when provided by the service provider." I鈥檓 not sure I understand鈥攖his seems to say the attribute is REQUIRED when it is present. (Same wording occurs for multiple attributes) -- 4.1.1, "name" This is defined as components of the user's "real" name. That sounds like an assertion of a real-name policy. Does the schema really require real names? -- 4.1.2, "groups" : "... which MAY influence indirect memberships.: s/MAY/may -- same section, "entitlements": "An entitlement MAY be an additional right" s/MAY/may -- 9.3. 2nd paragraph s/MAY/may (both occurrences) -- 10.3.1: Is there a reason not to use one or more of the well known registration policies from RFC 5226? Editorial Comments -- 4.1.1, "active" s/infers/implies From nobody Wed May 13 16:22:17 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276DF1B3204; Wed, 13 May 2015 16:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9DimkinaMQH; Wed, 13 May 2015 16:22:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4E21B31FF; Wed, 13 May 2015 16:22:11 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4DNMA67022332 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 May 2015 23:22:10 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4DNM99B012701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2015 23:22:09 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4DNM9L6004163; Wed, 13 May 2015 23:22:09 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 May 2015 16:22:09 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150513211921.24391.24472.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 16:22:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9412635D-CF41-405E-A2E8-F5D98A6AFD2E@oracle.com> References: <20150513211921.24391.24472.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-core-schema-20: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 23:22:13 -0000 Ben, Thanks again for another review!=20 Regarding the discuss item, I think you are correct, we should change = password storage from SHOULD NOT to MUST NOT be clear text. Regarding the other nits, I will apply them to the next edit along with = the above discuss item. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 13, 2015, at 2:19 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-scim-core-schema-20: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hopefully this one will be easy to address: >=20 > Section 4.1.1, under "password", says that passwords SHOULD be hashed = or > encrypted. But the security considerations say that passwords MUST NOT = be > stored in clear-text. These seem to be in conflict. (I prefer the MUST > NOT). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > -- General: >=20 > As in the API draft, there's quite a bit of misuse of the 2119 "MAY" > keyword (details below.) >=20 > -- 1.1, 3rd paragraph: "... all figures MAY contain spaces." >=20 > s/MAY/may >=20 > -- 2.1, 2nd paragraph : "MAY be camel-case" >=20 > Seems like if they are case insensitive, they can be any case. >=20 > -- 2.1, last paragraph: "... MAY need to be escaped..." >=20 > s/MAY/may >=20 > -- 2.2, 2nd bullet: >=20 > I assume this refers to the value/content of the attribute, since the > previous section said the attribute name is always case insensitive. >=20 > -- 2.3.4: >=20 > integer is defined as a _decimal_ number that MUST NOT contain = fractional > or exponent parts. But the definition of =E2=80=9CDecimal=E2=80=9D = says it has to have at > least one digit to the right of the period. Do these conflict? Do > Integers always need a trailing zero after a period? (I suspect the > answer is that you didn=E2=80=99t mean to say Integer was derived from = Decimal, > but if so, the use of =E2=80=9Cdecimal=E2=80=9D is confusing.) >=20 > -- 2.3.7, 2nd to last paragraph, first sentence: >=20 > To whom does this requirement apply? It sounds like an attempt to = apply a > MUST to whatever service a reference happens to refer to. I gather = that > could be any arbitrary service addressable with a URL. >=20 > -- 2.4, paragraph after bullet list : "The pre-defined set of > sub-attributes for a multi-valued attribute" >=20 > I=E2=80=99m not sure what that means. These are the only sub-attrs = that can be > used? All multi-valued attributes have these sub-attributes? >=20 > -- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED > attribute that MUST be > present" >=20 > The REQUIRED and MUST are redundant. >=20 > -- 3.1, first paragraph, last sentence: "SHALL NOT be considered = schema > extensions." >=20 > Should this really be normative? Does =E2=80=9Cconsidering them a = schema > extension=E2=80=9D involve observable implementation behavior = differences? >=20 > -- 3.1, meta/resourceType: "The attribute is REQUIRED when provided by > the service > provider." >=20 > I=E2=80=99m not sure I understand=E2=80=94this seems to say the = attribute is REQUIRED > when it is present. (Same wording occurs for multiple attributes) >=20 > -- 4.1.1, "name" >=20 > This is defined as components of the user's "real" name. That sounds = like > an assertion of a real-name policy. Does the schema really require = real > names? >=20 > -- 4.1.2, "groups" : "... which MAY influence > indirect memberships.: >=20 > s/MAY/may >=20 > -- same section, "entitlements": "An entitlement MAY be an additional > right" >=20 > s/MAY/may >=20 > -- 9.3. 2nd paragraph >=20 > s/MAY/may (both occurrences) >=20 > -- 10.3.1: >=20 > Is there a reason not to use one or more of the well known = registration > policies from RFC 5226? >=20 > Editorial Comments >=20 > -- 4.1.1, "active" > s/infers/implies >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 13 19:26:47 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10F31A8998; Wed, 13 May 2015 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEFn777XSSez; Wed, 13 May 2015 19:26:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC0C1A89A0; Wed, 13 May 2015 19:26:41 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4E2QTuD010877 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 21:26:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Phil Hunt" Date: Wed, 13 May 2015 21:26:29 -0500 Message-ID: In-Reply-To: <9412635D-CF41-405E-A2E8-F5D98A6AFD2E@oracle.com> References: <20150513211921.24391.24472.idtracker@ietfa.amsl.com> <9412635D-CF41-405E-A2E8-F5D98A6AFD2E@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-core-schema-20: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 02:26:43 -0000 Thanks, clearing the discuss now. On 13 May 2015, at 18:22, Phil Hunt wrote: > Ben, > > Thanks again for another review! > > Regarding the discuss item, I think you are correct, we should change > password storage from SHOULD NOT to MUST NOT be clear text. > > Regarding the other nits, I will apply them to the next edit along > with the above discuss item. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On May 13, 2015, at 2:19 PM, Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-scim-core-schema-20: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Hopefully this one will be easy to address: >> >> Section 4.1.1, under "password", says that passwords SHOULD be hashed >> or >> encrypted. But the security considerations say that passwords MUST >> NOT be >> stored in clear-text. These seem to be in conflict. (I prefer the >> MUST >> NOT). >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> -- General: >> >> As in the API draft, there's quite a bit of misuse of the 2119 "MAY" >> keyword (details below.) >> >> -- 1.1, 3rd paragraph: "... all figures MAY contain spaces." >> >> s/MAY/may >> >> -- 2.1, 2nd paragraph : "MAY be camel-case" >> >> Seems like if they are case insensitive, they can be any case. >> >> -- 2.1, last paragraph: "... MAY need to be escaped..." >> >> s/MAY/may >> >> -- 2.2, 2nd bullet: >> >> I assume this refers to the value/content of the attribute, since the >> previous section said the attribute name is always case insensitive. >> >> -- 2.3.4: >> >> integer is defined as a _decimal_ number that MUST NOT contain >> fractional >> or exponent parts. But the definition of 鈥淒ecimal鈥 says it has to >> have at >> least one digit to the right of the period. Do these conflict? Do >> Integers always need a trailing zero after a period? (I suspect the >> answer is that you didn鈥檛 mean to say Integer was derived from >> Decimal, >> but if so, the use of 鈥渄ecimal鈥 is confusing.) >> >> -- 2.3.7, 2nd to last paragraph, first sentence: >> >> To whom does this requirement apply? It sounds like an attempt to >> apply a >> MUST to whatever service a reference happens to refer to. I gather >> that >> could be any arbitrary service addressable with a URL. >> >> -- 2.4, paragraph after bullet list : "The pre-defined set of >> sub-attributes for a multi-valued attribute" >> >> I鈥檓 not sure what that means. These are the only sub-attrs that can >> be >> used? All multi-valued attributes have these sub-attributes? >> >> -- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED >> attribute that MUST be >> present" >> >> The REQUIRED and MUST are redundant. >> >> -- 3.1, first paragraph, last sentence: "SHALL NOT be considered >> schema >> extensions." >> >> Should this really be normative? Does 鈥渃onsidering them a schema >> extension鈥 involve observable implementation behavior differences? >> >> -- 3.1, meta/resourceType: "The attribute is REQUIRED when provided >> by >> the service >> provider." >> >> I鈥檓 not sure I understand鈥攖his seems to say the attribute is >> REQUIRED >> when it is present. (Same wording occurs for multiple attributes) >> >> -- 4.1.1, "name" >> >> This is defined as components of the user's "real" name. That sounds >> like >> an assertion of a real-name policy. Does the schema really require >> real >> names? >> >> -- 4.1.2, "groups" : "... which MAY influence >> indirect memberships.: >> >> s/MAY/may >> >> -- same section, "entitlements": "An entitlement MAY be an additional >> right" >> >> s/MAY/may >> >> -- 9.3. 2nd paragraph >> >> s/MAY/may (both occurrences) >> >> -- 10.3.1: >> >> Is there a reason not to use one or more of the well known >> registration >> policies from RFC 5226? >> >> Editorial Comments >> >> -- 4.1.1, "active" >> s/infers/implies >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 14 01:42:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D431B353F; Thu, 14 May 2015 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SEX=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEOzuUwzDZOW; Thu, 14 May 2015 01:42:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0EE1B353B; Thu, 14 May 2015 01:42:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514084221.1560.60262.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 01:42:21 -0700 Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, scim-chairs@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org Subject: [scim] Stephen Farrell's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:42:22 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-scim-core-schema-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - intro: I've no idea what "a general profile service for in-domain applications" might be. - intro: hmm, the pass-info-to-3rd-party is a bit unsettling all right. I think some earlier discussion resuled in a suggested addition that should help, so I'd just like to add more backing to the idea that such warnings can be useful. Maybe there ought also be a way to annotate elements to say that such "sharing" is not allowed? (As a future extension, if that can be done.) - 2.3.5: I didn't have time to chase the references here but is the TZ always clear in this encoding? And does 2015-01-01 mean all 24 hours of Jan 1 this year or just the first second of that day? - 3.1: lastModified - this is sometimes used as a secondary thing to authenticate the system to a user and so in some cases could be somewhat sensitive if it were world readable, or easily readable by someone who wanted to spoof as a server to a valid user. Not sure if that's worth a note here. Probably not. - 4.1.1: password, I agree with Ben's ex-DISCUSS. Section 8.7.1 also says that the password element contains the cleartext password which definitely needs fixing. - 4.1: why only x509Certificates? I think you should also allow PGP keys in some form or else generalise to "public key containers" that would allow both plus "bare" public keys maybe of varying forms. This is not a discuss because it could be fixed later, but the current design is IMO wrong in this respect and would be better fixed now. - 4.1: if you do keep an element named x509Certificates then it may be worth adding a negative bit of guideance such as 'Each value here contains exactly one (base64) encoding of a DER encoding of a Certificate data structure. A single value MUST NOT contain multiple certificates and so does not contain the encoding of a "SEQUENCE OF Certificate" in any guise.' It has been a while since it's been done afresh but I've seen that mistake in the past and it causes interop problems. - 8.x: Nice that Olson gets a hat-tip in the TZ definition! - 8.x: I hope someone has carefully read the schema stuff recently - it's long and detailed and I didn't have time. - Thanks for section 9.3! From nobody Thu May 14 01:47:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EBC1B3548; Thu, 14 May 2015 01:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFmooc1bf860; Thu, 14 May 2015 01:47:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3051B3542; Thu, 14 May 2015 01:47:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514084750.1519.73097.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 01:47:50 -0700 Archived-At: Cc: draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, scim-chairs@ietf.org, scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org Subject: [scim] Benoit Claise's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:47:52 -0000 Benoit Claise has entered the following ballot position for draft-ietf-scim-core-schema-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Qin's OPS DIR review: I think this draft is ready for publication. Here are a few editorial comments: 1. Section 1.1 鈥淩equirements Notation and Conventions鈥 I am wondering how RFC2119 languages are applied to this document, In Section 4.1.1, 鈥淩ECOMMENDED鈥 is applied to the attribute 鈥渦serName鈥 by adding 鈥淩ECOMMENDED鈥 at the end of attribute 鈥渦serName鈥 description. In section 7, 鈥淒EFAULT鈥漣s applied to subattibute 鈥渞eadwrite鈥 by adding 鈥淒EFAULT鈥 at the end of 鈥渞eadwrite鈥 sub-attribute description. 鈥淒EFAULT鈥 seems not RFC2119 language. Therefore RFC2119 language used to apply to some attribute seems not consistent with other language(e.g., DEFAULT) applied to some other attributes. Or the language used at the end of each attribute is not totally RFC2119 language. Please distinct where RFC2119 language is used from where other language(e.g.,鈥滵EFAULT鈥 ) is used in the draft. 2. Section 2.2 said: 鈥 2.2. Attribute Data Types Attribute data types are derived from JSON [RFC7159] and unless otherwise specified have the following characteristics (see Section 7 for attribute characteristic definitions): 鈥 Who has the following characteristics, attribute data types or attributes? If it is the former,I am not sure all the attribute data types listed here have the following characteristics(e.g., mutability, and returnability, uniqueness), For example. Boolean and Integer, Decimal are not of type string. Attribute data type 鈥淩eference鈥 is not case insensitive. Can you give an example to explain the attribute data types are modifiable? Or attributes corresponding to attribute data type listed here are modifiable? How to understand attribute data type are returned in response to queries? Are you saying attribute corresponding to attribute data types listed here are usually returned in response to queries? 3. Section 3.1 said: 鈥 For backwards compatibility reasons, some existing schema MAY list common attributes as part of the schema. The attribute characteristics listed here SHALL take precedence. 鈥 Where the attribute characteristics are listed here? Section 7? It looks what is listed here are a list of common attributes? What am I missing? Also please clarify how to understand 鈥渢ake precedence of these attribute characteristics 鈥? 4. Section 3.2 said 鈥 In order to offer new types of resources, a service provider defines the new resource type as specified in Section 6and defines a schema representation (see Section 8.7). 鈥 Miss a blank space between 鈥渟ection 6鈥 and 鈥渁nd鈥 in this sentence. 5. Section 6 said: 鈥 The following Singular Attributes are defined: id The resource type's server unique id. Often this is the same value as the "name" attribute. OPTIONAL name The resource type name. When applicable service providers MUST specify the name specified in the core schema specification; e.g., "User" or "Group". This name is referenced by the "meta.resourceType" attribute in all resources. 鈥 It looks not all the attributes are suffixed with 鈥淩ECOMMEND鈥,鈥漅EQUIRED鈥,鈥漁PTIONAL鈥,鈥滵EFAULT鈥. So what is the default characteristics pertaining to the attribute if it is not suffixed with 鈥淩ECOMMEND鈥, 鈥漅EQUIRED鈥,鈥漁PTIONAL鈥,鈥滵EFAULT鈥? If there is no default characteristics associated with the attribute, For consistency, I think each attribute should add a suffix like 鈥淒EFAULT鈥,鈥漅ECOMMENDED鈥,鈥漅EQUIRED鈥. 6. Section 7 said: 鈥 "Schema" resources have mutability of "readOnly" and are identified using the following schema URI: 鈥 Is SCIM Resources 鈥渟hema鈥漴esource? If they are the same thing, please use consistent terminology. 7. Section 7 also said: 鈥 id The unique URI of the schema. When applicable service providers MUST specify the URI specified in the core schema specification; e.g., "urn:ietf:params:scim:schemas:core:2.0:User". Unlike most other schemas, which use some sort of a GUID for the "id", the schema "id" is a URI so that it can be registered and is portable between different service providers and clients. 鈥 Does attribute 鈥渋d鈥 has the attribute characteristics described in section 2.2? i.e., 鈥 o are OPTIONAL (is not required). o are case insensitive ("caseExact" is "false"), o are modifiable ("mutability" is "readWrite"), o are returned in response to queries (returned by default), o have no canonical values (e.g. type is "home" or "work"), o are not unique ("uniqueness" is "none"), and, o of type string (Section 2.2.1). 鈥 8. Section 8.6 said: 鈥 The following is a non-normative example of the SCIM resource types in JSON format. 鈥 Section 7 said, A SCIM resource type can be 鈥渦ser鈥 or 鈥済roup鈥. I am wondering how represented using JSON format in the example of section 8.6? Using schema attribute 鈥 "schema": "urn:ietf:params:scim:schemas:core:2.0:User" 鈥 Or using combination of several attribute, e.g., 鈥渋d鈥,鈥漬ame鈥,etc. From nobody Thu May 14 07:49:28 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D644C1A007C for ; Thu, 14 May 2015 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPTtLLLurlrA for ; Thu, 14 May 2015 07:49:26 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DEE1A0163 for ; Thu, 14 May 2015 07:48:24 -0700 (PDT) Received: by labbd9 with SMTP id bd9so71299260lab.2 for ; Thu, 14 May 2015 07:48:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=3wfrZvqaGJTCFEEyOnl8dhj7cwhozyhHF1N/VQSHUy4=; b=hCBReh6BBdh2CdveWorTEV70dGoab5Wmkqi7By6KWb+rQRFzMM++Kj8YjQbv4gJs0+ SYvwaDyGYvq0FZ9G1mUIDwgmPJwitHltv04StG4f96dd8prw/tnodBVC4b8AgPu3AvCK LMD3S43/IA2dHq1ahtdCT0XMkz/CZ00/xX49NAXcJ4WPIxQaZuRFIPOuj2KWf3quv7yN DYxbdvxKNXvPeGJz0ib1R+0gwjh/MsPNthZtlhcKZ0CNaKF8pPfmk4OoxWxVmISEKUZf WkpxPSbN4HgJWSqDJx26V5brRZuZVCTjeJUphx2ZBoVGHHWm9gkezAQqptekuQCCxNGg 3MwQ== X-Gm-Message-State: ALoCoQnjAJk349yV95pIqGsOHFx6WtF0U1OVdSIjmodkn74IgpwneXQWduPpgEoLL6BKh5ugJBE7 X-Received: by 10.152.45.40 with SMTP id j8mr3512953lam.79.1431614902784; Thu, 14 May 2015 07:48:22 -0700 (PDT) Received: from [10.0.0.107] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id z1sm6188710laz.48.2015.05.14.07.48.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 07:48:21 -0700 (PDT) Message-ID: <5554B5B5.2000805@mnt.se> Date: Thu, 14 May 2015 16:48:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:49:28 -0000 We sorta talked about this in Dallas but... do we need to meet in Prague? From nobody Thu May 14 07:56:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3939E1A0275 for ; Thu, 14 May 2015 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F3fLmID1GzR for ; Thu, 14 May 2015 07:56:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163FF1A0277 for ; Thu, 14 May 2015 07:56:03 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (10.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 14:56:02 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0160.009; Thu, 14 May 2015 14:56:02 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUxWwUOLcN7Zk62zK2tbTzRgZ17jzrA Date: Thu, 14 May 2015 14:56:02 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> In-Reply-To: <5554B5B5.2000805@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mnt.se; dkim=none (message not signed) header.d=none; x-originating-ip: [185.32.153.182] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 3:ByFw1gVcLZDKXehAJPNzJA10iR7CZqMlzu9X4QIsrr5+Q0gxptTdp06Db1fdO4mvbXHDk+SQtRp1p6ROImP+CT/hbV00D1r3J+o8o8BCMkse8Uuh9i3X3/Hto0WUsjBPH/AyKjQxAUmdrWAvvQcACw==; 10:Xjd5NtgYv7iWLR6ZKggdeoLaVh0FmGU04YZPaRirShs46YtPfjeNbkygDj4atBm/LGL4+TeGQKTN1nlfqxarLvBGtS6PDcg74x4VZjsgo2g=; 6:LwWiVAbqR3QN83xUOA9AJ8/9MB1sqx3ntWgKOblTX47EDPFFqSp32eg8m5FcoF7S x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(57704003)(40100003)(122556002)(189998001)(107886002)(19580395003)(5001960100002)(19580405001)(99286002)(74316001)(77096005)(102836002)(15975445007)(86612001)(76576001)(2501003)(106116001)(87936001)(2950100001)(2900100001)(2656002)(76176999)(54356999)(46102003)(50986999)(92566002)(33656002)(62966003)(77156002)(5001770100001)(86362001)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 14:56:02.2204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:56:35 -0000 We agreed we would meet late in the day and then migrate to a bar where you= would buy us beer -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Thursday, May 14, 2015 7:48 AM To: scim@ietf.org Subject: [scim] Prague? We sorta talked about this in Dallas but... do we need to meet in Prague? _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 14 07:59:01 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999E31A049A for ; Thu, 14 May 2015 07:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-COKUGkN61x for ; Thu, 14 May 2015 07:58:58 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED241A004C for ; Thu, 14 May 2015 07:58:56 -0700 (PDT) Received: by labbd9 with SMTP id bd9so71835421lab.2 for ; Thu, 14 May 2015 07:58:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ah8CX+a11391TQbgIEYKlfjmHmQdkl9Hm6O+9c2tEkE=; b=EFsF5R+NpD1wiANLmgysX70XWTAQHFXey0qewRYoundZKAd2FpnzcgmwTmfwwMBRmG gjZiivbAV5MG7a7PsUsKcoIplLUJ4na0XPP95jZcNP5GJ7u0aYdTA+uivNUBFf5kE+db rtGRLz+tSIHuYfVs5LvqyHvNfMMVjOfXbHa+uWzr/6HUtU5IHtA2uJ1YHkNCDJf+GPdk GXQaVATuMGqI1B/rQ3+JAjouEMnNrPajRNSes89RwbdZbCbpelfNEvNkE3p/HHwI2V2g yf6jaZlpLGpRvcQP88YZkEzYI/Vfcw3pMrYA0rupENmvRcy0/yvHXwWu2WLKZK9HDoKT W8aA== X-Gm-Message-State: ALoCoQmFE8L/Lf6xmckvPO1D8r6y665FrkWwyFpD1BpFUbx0v+YsjL7s/Qa4fO0ZB1fSdRHDQc7R X-Received: by 10.112.129.132 with SMTP id nw4mr3630429lbb.122.1431615532262; Thu, 14 May 2015 07:58:52 -0700 (PDT) Received: from [10.0.0.107] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id at2sm6211404lbc.12.2015.05.14.07.58.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 07:58:51 -0700 (PDT) Message-ID: <5554B82B.9020109@mnt.se> Date: Thu, 14 May 2015 16:58:51 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anthony Nadalin , "scim@ietf.org" References: <5554B5B5.2000805@mnt.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:58:59 -0000 On 05/14/2015 04:56 PM, Anthony Nadalin wrote: > We agreed we would meet late in the day and then migrate to a bar where you would buy us beer > So who is planning to be in Prague? From nobody Thu May 14 08:33:08 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFD71A1DBC for ; Thu, 14 May 2015 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE0p8p4qbDHW for ; Thu, 14 May 2015 08:33:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941911A6F2F for ; Thu, 14 May 2015 08:33:05 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.160.19; Thu, 14 May 2015 15:33:04 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) with mapi id 15.01.0160.009; Thu, 14 May 2015 15:33:03 +0000 From: Kelly Grizzle To: Leif Johansson , Anthony Nadalin , "scim@ietf.org" Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUxHkquqX2E906MLSImptnSUZ17j4YAgAAAyYCAAAl2gA== Date: Thu, 14 May 2015 15:33:03 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> In-Reply-To: <5554B82B.9020109@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 7E214E16009D0E7E214F63 authentication-results: mnt.se; dkim=none (message not signed) header.d=none; x-originating-ip: [70.114.158.171] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB389; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(13464003)(24454002)(1511001)(2421001)(40100003)(122556002)(189998001)(107886002)(2561002)(19580395003)(5001960100002)(19580405001)(99286002)(74316001)(102836002)(15975445007)(76576001)(2501003)(106116001)(87936001)(2950100001)(2900100001)(2656002)(76176999)(54356999)(46102003)(50986999)(92566002)(33656002)(62966003)(77156002)(5001770100001)(86362001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 15:33:03.2616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 Archived-At: Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:33:07 -0000 I will not, but will attend remotely if there is a meeting. -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Thursday, May 14, 2015 9:59 AM To: Anthony Nadalin; scim@ietf.org Subject: Re: [scim] Prague? On 05/14/2015 04:56 PM, Anthony Nadalin wrote: > We agreed we would meet late in the day and then migrate to a bar where y= ou would buy us beer >=20 So who is planning to be in Prague? _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 14 08:33:47 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AFF1A6FF1 for ; Thu, 14 May 2015 08:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtHFyrF1dsJw for ; Thu, 14 May 2015 08:33:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2622D1A3B9D for ; Thu, 14 May 2015 08:33:45 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4EFXh7i018135 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 May 2015 15:33:44 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4EFXh6K010512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2015 15:33:43 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4EFXhpF017241; Thu, 14 May 2015 15:33:43 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 May 2015 08:33:43 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: <5554B82B.9020109@mnt.se> Date: Thu, 14 May 2015 08:33:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> To: Leif Johansson X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Anthony Nadalin , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:33:46 -0000 I will be there.=20 It would be nice to have an informal meeting to 'white-board' ideas on crede= ntial mgmt. Kind of a scim credential bof.=20 There are many account state issues in common and many things that aren't et= c.=20 Basically we need a rough design position (what docs do we need etc) in orde= r to potentially structure passwords and other credential types.=20 I think a small room would be appropriate.=20 Phil > On May 14, 2015, at 07:58, Leif Johansson wrote: >=20 >> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >> We agreed we would meet late in the day and then migrate to a bar where y= ou would buy us beer >=20 > So who is planning to be in Prague? >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 14 09:05:10 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CA1A87EC for ; Thu, 14 May 2015 09:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPoEMGfHmP8W for ; Thu, 14 May 2015 09:05:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6071A87BC for ; Thu, 14 May 2015 09:04:59 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4EG4xl8029947 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 May 2015 16:04:59 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4EG4w9p015374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2015 16:04:58 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4EG4wfu030631; Thu, 14 May 2015 16:04:58 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 May 2015 09:04:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> Date: Thu, 14 May 2015 09:04:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> To: Leif Johansson X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Anthony Nadalin , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:05:09 -0000 Also Stephen raised a couple of good points in his No Objection comments on p= ublic keys. This should be part of that discussion.=20 Slightly different topic might be an extension regarding information origin a= nd propagation meta data. This was raised by both Kathleen and Stephen durin= g their reviews of SCIM. =20 Phil > On May 14, 2015, at 08:33, Phil Hunt wrote: >=20 > I will be there.=20 >=20 > It would be nice to have an informal meeting to 'white-board' ideas on cre= dential mgmt. Kind of a scim credential bof.=20 >=20 > There are many account state issues in common and many things that aren't e= tc.=20 >=20 > Basically we need a rough design position (what docs do we need etc) in or= der to potentially structure passwords and other credential types.=20 >=20 > I think a small room would be appropriate.=20 >=20 > Phil >=20 >>> On May 14, 2015, at 07:58, Leif Johansson wrote: >>>=20 >>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>> We agreed we would meet late in the day and then migrate to a bar where y= ou would buy us beer >>=20 >> So who is planning to be in Prague? >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu May 14 11:37:24 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB171B2E0C for ; Thu, 14 May 2015 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJNJ3QXhQ3eb for ; Thu, 14 May 2015 11:37:19 -0700 (PDT) Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (nm5-vm2.bullet.mail.ne1.yahoo.com [98.138.90.153]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1679E1B2E1A for ; Thu, 14 May 2015 11:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431628633; bh=wJE14+MYPAyYQd6rClbh/uJ8tJC7lQZsFPsL19lJfuk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=U8FL6lG8XDuiqk8ch5yCR9q1gDYDLPb0HnZYnuWXA8nA8Ty5Bq57v2+3Xm/MpWXXC97rB4dKdJ+L5PeQxVC/hujmDOC5e0vN93YY8XRkVIUDGnCGRAUpQcT9KBxakAcOlbucqiIqFD1tDXvXgwKIPEwal9m1QWuC+ghrbDfUrCT+tfoxoXYoyDuZglNF/cs1Lh5OSWbcVE+3xXwRtcTpBiZzmEukh3/euzEVVXbmIcvb6a6R/hrnx9SJ8YM4sh2BX7y0VEzJnsB0Kxp2RtQ/mrg46Vr3WOqCpAsMm5+t/KllliK4a/tY9RLiTLH4RVpH8xk1pA2gY52mC4k9Q+IrUQ== Received: from [98.138.100.114] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2015 18:37:13 -0000 Received: from [98.138.226.58] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2015 18:37:13 -0000 Received: from [127.0.0.1] by smtp209.mail.ne1.yahoo.com with NNFMP; 14 May 2015 18:37:13 -0000 X-Yahoo-Newman-Id: 493355.2725.bm@smtp209.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jhbZqF4VM1lSvpqiqymJ7VzkmWZ7Exu0Q7QITgeAPrT.T2j WgFfwYqVtE8Y6EyYqO2_6m.x8xZkdih_ASZqTqrAujPsUiL3zpTddnDHZpng moMtjvzLV2YZxrw.dSaYUbsr.LV0gjQECoxbbRf2YZPEAYzKYxPja3EteP9t mCzGRe1GQfAsN0jkUkCSLC6dKhxa9.aHMi7ylnON16rL7p9QpoDv2cU84cKf _B_0jUfF4Mpx6bYArU7rMizMabssyzL9cRzf.M6bn8XkNH__bNCbu8kdFE_v 92hGV11owm26QyCCqt3zpWio1bTHr.3FybO13IBnmRMcl18SyJ_lX2cr8JpM uD06jTMmSAT8BcLJcaNNBxIIt4WTEd9WZHDAit0EWMlpcbBRzQ5dYkMi145A gL0uNj6skI004WfuMaE1drGLC10kmUHHwYGbLksxWzJ.ai7.XAaeBYrMJShF LS9pcant0WkaBz0a0tWT0znRvJ6kYMGeKHiCjIwCwPRpEJFWHsj2dufMbHia rJIdIHc.ohfIt5x6YUq5hQQ-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> Date: Thu, 14 May 2015 11:37:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 18:37:21 -0000 Regarding Ben=E2=80=99s items below on versioning, I think we need more = discussion: >>>=20 >>>=20 >>> -- 3.13: >>>=20 >>> It's optional (MAY) to include the API version. If the version is >>> missing, the service provider SHOULD perform the operation using the = most >>> recent supported version. This seems to allow the client and service >>> provider to disagree on the version being used. Does this cause an >>> interop problem if the later version is not backwards compatible? = (Are >>> all new versions expected to be backwards compatible with old = versions?) >>=20 >> See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >=20 > I think this is different than in the previous comment. If a certain = combination of method and attributes means something different in = version N and version N+1, and the client and server leaves out the = version, thinks could break. My suggestion would be to always include = the version--but I understand there might be other reasons not to. An = alternative would be to give guidance about backwards compatibility. = (Even non-normative guidance in the form of "if you do this things might = break" would help.) I do agree that this section is covering the issue of versioning = somewhat superficially.=20 The text for this section is fairly old and my understanding is it = represents some of the original SCIM 1 consensus.=20 My personal worry is I would not want to discourage updates by = encouraging lock-in to specific versions. Better to =E2=80=9Cbreak=E2=80=9D= clients and have them update or re-configure for a specific version. I = think this is mediated by the fact that most cloud providers all have = methodologies capable of delivering rapid and frequent client updates. =46rom a protocol perspective, the WG has used =E2=80=9Crobust=E2=80=9D = processing principles that require implementations to more be flexible = in what is accepted while strict on fundamentals (e.g. JSON must be = valid). For example, in an earlier thread we talked about how servers = SHOULD ignore search parameters they do not understand. Further, errors = are not supposed to be thrown due to attributes that are not defined - = they are merely ignored.=20 I think SCIM's design principles should aid implementers in avoiding = many of the backwards compatibility issues we might otherwise = experience. Never-the-less, maybe we need some cautionary text that deployers need = to consider ramification of breaking changes in the default version? = They need to have an appropriate method for co-ordinating breaking = updates and transition where possible. Thanks, Phil phil.hunt@yahoo.com > On May 12, 2015, at 10:22 PM, Ben Campbell wrote: >=20 > Thanks for the quick response. I am okay with your responses to all = the DISCUSS points save the last, and I am only holding that one for a = bit more discussion. (That is, I will probably clear regardless of your = response.) >=20 > Details inline. I deleted sections that did not appear to need further = discussion. >=20 > On 12 May 2015, at 23:45, Phil Hunt wrote: >=20 >> Ben, >>=20 >> Thanks for the extensive comments. If I have not commented below, = please assume I am agreeing and will make the change. >>=20 >> Phil >>=20 >> phil.hunt@yahoo.com >>=20 >>> On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >>>=20 >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-scim-api-18: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> -- 3.4.2: "SHOULD ignore any query parameters they do not = understand" >>>=20 >>> I'm curious why this is not a MUST. What are the alternatives--that = is, >>> can you envision situations where it might be reasonable to _not_ = ignore >>> parameters you don't understand? >>=20 >> The currently unstated opposite is that a server might choose to = reject the request. I believe the preference is for servers to ignore = what they do not understand for upward compatibility reasons. MUST = ignore seems to harsh. >=20 > Okay, that makes sense. Some guidance to that effect would be helpful, = but I won't hold the discuss on that. >>=20 >=20 > [...] >=20 >>>=20 >>> -- 3.8: >>>=20 >>> The first paragraph says servers MUST respond with JSON in UTF-8. = But the >>> following paragraphs talk about how the client may request different >>> response formats. This seems contradictory. >>=20 >> I will adjust. I think some service providers may wish to support = other formats. I don=E2=80=99t think it is our intent to limit here, = just that other formats are beyond scope. >=20 > Okay >=20 >>>=20 >>> -- 3.13: >>>=20 >>> It's optional (MAY) to include the API version. If the version is >>> missing, the service provider SHOULD perform the operation using the = most >>> recent supported version. This seems to allow the client and service >>> provider to disagree on the version being used. Does this cause an >>> interop problem if the later version is not backwards compatible? = (Are >>> all new versions expected to be backwards compatible with old = versions?) >>=20 >> See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >=20 > I think this is different than in the previous comment. If a certain = combination of method and attributes means something different in = version N and version N+1, and the client and server leaves out the = version, thinks could break. My suggestion would be to always include = the version--but I understand there might be other reasons not to. An = alternative would be to give guidance about backwards compatibility. = (Even non-normative guidance in the form of "if you do this things might = break" would help.) >=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >=20 > [...] >=20 >>>=20 >>> -- 2.1, last paragraph: >>>=20 >>> Just SHOULD? Do you invision situations where it might be reasonable >>> _not_ to take the threats into account? >>>=20 >>> Also, the reference to oath-assertions needs to be normative >> I=E2=80=99m not sure what you are referring to. paragraph 1 of 2.1 = refers to section 6 of the OAuth Assertions Draft. The last paragraph = does not refer to it. >>>=20 >=20 > Are we looking at the same version (18)? I see the last paragraph of = 2.1 as the following: >=20 > "Implementers SHOULD take into account the threats and = countermeasuresdocumented in the security considerations for the use of = clientauthorizations see Section 8 of [I-D.ietf-oauth-assertions]." >=20 >=20 > [...] >=20 >>> -- 3.3, 3rd bullet: >>>=20 >>> How does a service provider know which attributes a client = understands? >>=20 >> This was a compromise resolution to a problem in REST that the WG ran = into. What does it mean when a client does not assert a value? Is it the = intention that the client wants the value cleared (by not asserting it), = is the client saying nothing, or does the client expect it to be = defaulted. >>=20 >> Then there is the issue that access control might be filtering what = the client can set or in the response, what can be returned to the = client. In other words, the client may not be intending to clear a value = because it may not even know about the attribute. >>=20 >> I=E2=80=99ve never been happy with the proposed paragraph and would = invite alternate proposals. >=20 > The "client has access to" part is easier to understand, since the = service provider presumably knows what attributes it sent, or will send, = to the client. Would it make sense to just delete the phrase ", or = understands,"? >=20 > [...] >>>=20 >>> -- 3.4.2.4, 1st paragraph: "clients SHOULD never >>> assume repeatable results" >>>=20 >>> That seems like a statement of fact, not a normative assertion. >>=20 >> Not sure I agree. It is normative in that clients must be prepared = to handle inconsistent results during paging. Maybe we can rephrase = around the issue? >>=20 >=20 > How about "clients MUST be prepared to handle inconsistent results..." = :-) >=20 > [...] >=20 >>>=20 >>> -- 7.3: >>>=20 >>> That needs to be a normative reference. Also, why is this a SHOULD? = Can >>> you envision scenarios where it might be reasonable for implementors = NOT >>> to take the countermeasures into account? >>=20 >> Well they might not be using OAuth tokens. >>=20 >> My understanding since OAuth is optional, it should not be a = normative reference. >=20 > Even if a feature is optional, a reference that is needed to = understand and/or implement the feature should still be normative. >=20 >> Also, the assertions draft is a work in progress. >=20 > I understand that is an issue, but it's not appropriate (or even = beneficial) to avoid a normative reference due to a dependency block. = The whole point of that bit of inconvenience is to make sure an RFC = doesn't depend on a moving target in order for a feature to be = understood or implemented. >=20 >>>=20 >>> -- 7.4: >>>=20 >>> Reference to oauth-assertions needs to be normative. >>=20 >> Again, OAuth is optional. >>=20 >> Regarding all of the authentication methods described, since they are = all optional I have made them all informative unless every = implementation MUST support it (e.g. because SCIM depends on it). >>=20 >> Correct me if this is editorially incorrect. >=20 > IMHO, it is editorially incorrect. Please see my previous comments on = 7.3. But in any case, I am not holding a discuss on these points--I will = leave it to Barry to decide how to proceed. >=20 >>=20 >>>=20 >>> -- 7.6, 2nd bullet >>>=20 >>> s/MAY/may >>>=20 >>> -- editorial >>>=20 >>> -- 2, HOBA paragraph: >>>=20 >>> Is this intended as part of the TLS Client Authentication entry? It >>> doesn't seem so, but the paragraph lacks its own heading. >>=20 >> My thinking was it is a profile/variation of TLS client = authentication. IOW the only thing that is different is how the keys are = managed/distributed. >>=20 >> I am open to calling it out as a separate item. >=20 > That's okay with me if it was the intent. >=20 > [...] From nobody Thu May 14 11:54:10 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B21B2E74; Thu, 14 May 2015 11:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiwJy2HYLkNN; Thu, 14 May 2015 11:54:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADD51ACD78; Thu, 14 May 2015 11:54:05 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4EIs2TL023799 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 May 2015 18:54:03 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4EIs2o1023746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2015 18:54:02 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4EIs10q001351; Thu, 14 May 2015 18:54:01 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 May 2015 11:54:01 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> Date: Thu, 14 May 2015 11:53:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <313FE69B-CC08-42C4-8029-ED1F03DDA50F@oracle.com> References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 18:54:08 -0000 Barry, Following up on more of Ben=E2=80=99s comments. Ben has suggested many = of the authentication references need to be normative. Many of these = references are works-in-progress and I wouldn=E2=80=99t want to hold = SCIM up with so many references pending. My feeling is that these were added to the specification as = supplementary information on how clients can be authenticated and these = are really just part of best practices around HTTP. While arguably = version useful, very little of the authentication section is SCIM = specific (that would not apply to any other HTTP app).=20 We might choose to make certain references normative if SCIM has a = normative requirement of a specific method. For example, for OAuth = Bearer tokens we say: > Bearer tokens [RFC6750] MAY be used when combined with TLS and a > token framework such as OAuth 2.0 [RFC6749]. Tokens that are > issued based on weak or no authentication of authorizing users > and/or OAuth clients SHOULD NOT be used. Even so in this text, we are talking about an operational security = consideration and not a protocol or implementation requirement. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 12, 2015, at 10:22 PM, Ben Campbell wrote: >=20 > Thanks for the quick response. I am okay with your responses to all = the DISCUSS points save the last, and I am only holding that one for a = bit more discussion. (That is, I will probably clear regardless of your = response.) >=20 > Details inline. I deleted sections that did not appear to need further = discussion. >=20 > On 12 May 2015, at 23:45, Phil Hunt wrote: >=20 >> Ben, >>=20 >> Thanks for the extensive comments. If I have not commented below, = please assume I am agreeing and will make the change. >>=20 >> Phil >>=20 >> phil.hunt@yahoo.com >>=20 >>> On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >>>=20 >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-scim-api-18: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> -- 3.4.2: "SHOULD ignore any query parameters they do not = understand" >>>=20 >>> I'm curious why this is not a MUST. What are the alternatives--that = is, >>> can you envision situations where it might be reasonable to _not_ = ignore >>> parameters you don't understand? >>=20 >> The currently unstated opposite is that a server might choose to = reject the request. I believe the preference is for servers to ignore = what they do not understand for upward compatibility reasons. MUST = ignore seems to harsh. >=20 > Okay, that makes sense. Some guidance to that effect would be helpful, = but I won't hold the discuss on that. >>=20 >=20 > [...] >=20 >>>=20 >>> -- 3.8: >>>=20 >>> The first paragraph says servers MUST respond with JSON in UTF-8. = But the >>> following paragraphs talk about how the client may request different >>> response formats. This seems contradictory. >>=20 >> I will adjust. I think some service providers may wish to support = other formats. I don=E2=80=99t think it is our intent to limit here, = just that other formats are beyond scope. >=20 > Okay >=20 >>>=20 >>> -- 3.13: >>>=20 >>> It's optional (MAY) to include the API version. If the version is >>> missing, the service provider SHOULD perform the operation using the = most >>> recent supported version. This seems to allow the client and service >>> provider to disagree on the version being used. Does this cause an >>> interop problem if the later version is not backwards compatible? = (Are >>> all new versions expected to be backwards compatible with old = versions?) >>=20 >> See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >=20 > I think this is different than in the previous comment. If a certain = combination of method and attributes means something different in = version N and version N+1, and the client and server leaves out the = version, thinks could break. My suggestion would be to always include = the version--but I understand there might be other reasons not to. An = alternative would be to give guidance about backwards compatibility. = (Even non-normative guidance in the form of "if you do this things might = break" would help.) >=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >=20 > [...] >=20 >>>=20 >>> -- 2.1, last paragraph: >>>=20 >>> Just SHOULD? Do you invision situations where it might be reasonable >>> _not_ to take the threats into account? >>>=20 >>> Also, the reference to oath-assertions needs to be normative >> I=E2=80=99m not sure what you are referring to. paragraph 1 of 2.1 = refers to section 6 of the OAuth Assertions Draft. The last paragraph = does not refer to it. >>>=20 >=20 > Are we looking at the same version (18)? I see the last paragraph of = 2.1 as the following: >=20 > "Implementers SHOULD take into account the threats and = countermeasuresdocumented in the security considerations for the use of = clientauthorizations see Section 8 of [I-D.ietf-oauth-assertions]." >=20 >=20 > [...] >=20 >>> -- 3.3, 3rd bullet: >>>=20 >>> How does a service provider know which attributes a client = understands? >>=20 >> This was a compromise resolution to a problem in REST that the WG ran = into. What does it mean when a client does not assert a value? Is it the = intention that the client wants the value cleared (by not asserting it), = is the client saying nothing, or does the client expect it to be = defaulted. >>=20 >> Then there is the issue that access control might be filtering what = the client can set or in the response, what can be returned to the = client. In other words, the client may not be intending to clear a value = because it may not even know about the attribute. >>=20 >> I=E2=80=99ve never been happy with the proposed paragraph and would = invite alternate proposals. >=20 > The "client has access to" part is easier to understand, since the = service provider presumably knows what attributes it sent, or will send, = to the client. Would it make sense to just delete the phrase ", or = understands,"? >=20 > [...] >>>=20 >>> -- 3.4.2.4, 1st paragraph: "clients SHOULD never >>> assume repeatable results" >>>=20 >>> That seems like a statement of fact, not a normative assertion. >>=20 >> Not sure I agree. It is normative in that clients must be prepared = to handle inconsistent results during paging. Maybe we can rephrase = around the issue? >>=20 >=20 > How about "clients MUST be prepared to handle inconsistent results..." = :-) >=20 > [...] >=20 >>>=20 >>> -- 7.3: >>>=20 >>> That needs to be a normative reference. Also, why is this a SHOULD? = Can >>> you envision scenarios where it might be reasonable for implementors = NOT >>> to take the countermeasures into account? >>=20 >> Well they might not be using OAuth tokens. >>=20 >> My understanding since OAuth is optional, it should not be a = normative reference. >=20 > Even if a feature is optional, a reference that is needed to = understand and/or implement the feature should still be normative. >=20 >> Also, the assertions draft is a work in progress. >=20 > I understand that is an issue, but it's not appropriate (or even = beneficial) to avoid a normative reference due to a dependency block. = The whole point of that bit of inconvenience is to make sure an RFC = doesn't depend on a moving target in order for a feature to be = understood or implemented. >=20 >>>=20 >>> -- 7.4: >>>=20 >>> Reference to oauth-assertions needs to be normative. >>=20 >> Again, OAuth is optional. >>=20 >> Regarding all of the authentication methods described, since they are = all optional I have made them all informative unless every = implementation MUST support it (e.g. because SCIM depends on it). >>=20 >> Correct me if this is editorially incorrect. >=20 > IMHO, it is editorially incorrect. Please see my previous comments on = 7.3. But in any case, I am not holding a discuss on these points--I will = leave it to Barry to decide how to proceed. >=20 >>=20 >>>=20 >>> -- 7.6, 2nd bullet >>>=20 >>> s/MAY/may >>>=20 >>> -- editorial >>>=20 >>> -- 2, HOBA paragraph: >>>=20 >>> Is this intended as part of the TLS Client Authentication entry? It >>> doesn't seem so, but the paragraph lacks its own heading. >>=20 >> My thinking was it is a profile/variation of TLS client = authentication. IOW the only thing that is different is how the keys are = managed/distributed. >>=20 >> I am open to calling it out as a separate item. >=20 > That's okay with me if it was the intent. >=20 > [...] From nobody Thu May 14 13:46:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169971A8968; Thu, 14 May 2015 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72oOvNGJAkAZ; Thu, 14 May 2015 13:45:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6DF1A887D; Thu, 14 May 2015 13:45:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514204559.13359.54568.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 13:45:59 -0700 Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org, scim@ietf.org Subject: [scim] Ben Campbell's No Objection on draft-ietf-scim-api-18: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:46:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-scim-api-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: I've released my DISCUSS on this. All my DISCUSS items have been resolved save the last one that I am moving to a comment. My point was to make sure the concern was discussed--if the authors answer that the working group thought about this want to keep it as is, that's okay with me. Former Discuss Point: It's optional (MAY) to include the API version. If the version is missing, the service provider SHOULD perform the operation using the most recent supported version. This seems to allow the client and service provider to disagree on the version being used. Does this cause an interop problem if the later version is not backwards compatible? (Are all new versions expected to be backwards compatible with old versions?) [ I've removed comments that I think have been addressed.] [...] -- 2.1, last paragraph: Just SHOULD? Do you invision situations where it might be reasonable _not_ to take the threats into account? Also, the reference to oath-assertions needs to be normative -- 2.2, "... it MAY be acceptable" [...] -- 3.3, 3rd bullet: How does a service provider know which attributes a client understands? [...] As worded, that sounds like a statement of fact. -- 7.3: That needs to be a normative reference. Also, why is this a SHOULD? Can you envision scenarios where it might be reasonable for implementors NOT to take the countermeasures into account? -- 7.4: Reference to oauth-assertions needs to be normative. -- 7.6, 2nd bullet [...] From nobody Thu May 14 13:48:28 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745DB1A887D; Thu, 14 May 2015 13:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKBMvEZwjJzw; Thu, 14 May 2015 13:48:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D65D1A89A3; Thu, 14 May 2015 13:48:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4EKm9Pq013214 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 15:48:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Phil Hunt" Date: Thu, 14 May 2015 15:48:09 -0500 Message-ID: In-Reply-To: References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:48:26 -0000 For the record, I'm clearing the DISCUSS on the version question, and moving it to a comment. I only held the discuss to make sure it got discussed, and that appears to be happening. If the answer comes back as "it's right as is", I'm okay with that. Thanks! Ben. On 14 May 2015, at 13:37, Phil Hunt wrote: > Regarding Ben鈥檚 items below on versioning, I think we need more > discussion: >>>> >>>> >>>> -- 3.13: >>>> >>>> It's optional (MAY) to include the API version. If the version is >>>> missing, the service provider SHOULD perform the operation using >>>> the most >>>> recent supported version. This seems to allow the client and >>>> service >>>> provider to disagree on the version being used. Does this cause an >>>> interop problem if the later version is not backwards compatible? >>>> (Are >>>> all new versions expected to be backwards compatible with old >>>> versions?) >>> >>> See previous comment on ignoring what is not understood. My >>> understanding this is one of those common practices that goes >>> underspecified. Happy to take suggestions here. >> >> I think this is different than in the previous comment. If a certain >> combination of method and attributes means something different in >> version N and version N+1, and the client and server leaves out the >> version, thinks could break. My suggestion would be to always include >> the version--but I understand there might be other reasons not to. An >> alternative would be to give guidance about backwards compatibility. >> (Even non-normative guidance in the form of "if you do this things >> might break" would help.) > > I do agree that this section is covering the issue of versioning > somewhat superficially. > > The text for this section is fairly old and my understanding is it > represents some of the original SCIM 1 consensus. > > My personal worry is I would not want to discourage updates by > encouraging lock-in to specific versions. Better to 鈥渂reak鈥 > clients and have them update or re-configure for a specific version. > I think this is mediated by the fact that most cloud providers all > have methodologies capable of delivering rapid and frequent client > updates. > > From a protocol perspective, the WG has used 鈥渞obust鈥 processing > principles that require implementations to more be flexible in what is > accepted while strict on fundamentals (e.g. JSON must be valid). For > example, in an earlier thread we talked about how servers SHOULD > ignore search parameters they do not understand. Further, errors are > not supposed to be thrown due to attributes that are not defined - > they are merely ignored. > > I think SCIM's design principles should aid implementers in avoiding > many of the backwards compatibility issues we might otherwise > experience. > > Never-the-less, maybe we need some cautionary text that deployers need > to consider ramification of breaking changes in the default version? > They need to have an appropriate method for co-ordinating breaking > updates and transition where possible. > > Thanks, > > Phil > > phil.hunt@yahoo.com > >> On May 12, 2015, at 10:22 PM, Ben Campbell wrote: >> >> Thanks for the quick response. I am okay with your responses to all >> the DISCUSS points save the last, and I am only holding that one for >> a bit more discussion. (That is, I will probably clear regardless of >> your response.) >> >> Details inline. I deleted sections that did not appear to need >> further discussion. >> >> On 12 May 2015, at 23:45, Phil Hunt wrote: >> >>> Ben, >>> >>> Thanks for the extensive comments. If I have not commented below, >>> please assume I am agreeing and will make the change. >>> >>> Phil >>> >>> phil.hunt@yahoo.com >>> >>>> On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >>>> >>>> Ben Campbell has entered the following ballot position for >>>> draft-ietf-scim-api-18: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to >>>> all >>>> email addresses included in the To and CC lines. (Feel free to cut >>>> this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> -- 3.4.2: "SHOULD ignore any query parameters they do not >>>> understand" >>>> >>>> I'm curious why this is not a MUST. What are the alternatives--that >>>> is, >>>> can you envision situations where it might be reasonable to _not_ >>>> ignore >>>> parameters you don't understand? >>> >>> The currently unstated opposite is that a server might choose to >>> reject the request. I believe the preference is for servers to >>> ignore what they do not understand for upward compatibility reasons. >>> MUST ignore seems to harsh. >> >> Okay, that makes sense. Some guidance to that effect would be >> helpful, but I won't hold the discuss on that. >>> >> >> [...] >> >>>> >>>> -- 3.8: >>>> >>>> The first paragraph says servers MUST respond with JSON in UTF-8. >>>> But the >>>> following paragraphs talk about how the client may request >>>> different >>>> response formats. This seems contradictory. >>> >>> I will adjust. I think some service providers may wish to support >>> other formats. I don鈥檛 think it is our intent to limit here, just >>> that other formats are beyond scope. >> >> Okay >> >>>> >>>> -- 3.13: >>>> >>>> It's optional (MAY) to include the API version. If the version is >>>> missing, the service provider SHOULD perform the operation using >>>> the most >>>> recent supported version. This seems to allow the client and >>>> service >>>> provider to disagree on the version being used. Does this cause an >>>> interop problem if the later version is not backwards compatible? >>>> (Are >>>> all new versions expected to be backwards compatible with old >>>> versions?) >>> >>> See previous comment on ignoring what is not understood. My >>> understanding this is one of those common practices that goes >>> underspecified. Happy to take suggestions here. >> >> I think this is different than in the previous comment. If a certain >> combination of method and attributes means something different in >> version N and version N+1, and the client and server leaves out the >> version, thinks could break. My suggestion would be to always include >> the version--but I understand there might be other reasons not to. An >> alternative would be to give guidance about backwards compatibility. >> (Even non-normative guidance in the form of "if you do this things >> might break" would help.) >> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >> >> [...] >> >>>> >>>> -- 2.1, last paragraph: >>>> >>>> Just SHOULD? Do you invision situations where it might be >>>> reasonable >>>> _not_ to take the threats into account? >>>> >>>> Also, the reference to oath-assertions needs to be normative >>> I鈥檓 not sure what you are referring to. paragraph 1 of 2.1 refers >>> to section 6 of the OAuth Assertions Draft. The last paragraph does >>> not refer to it. >>>> >> >> Are we looking at the same version (18)? I see the last paragraph of >> 2.1 as the following: >> >> "Implementers SHOULD take into account the threats and >> countermeasuresdocumented in the security considerations for the use >> of clientauthorizations see Section 8 of >> [I-D.ietf-oauth-assertions]." >> >> >> [...] >> >>>> -- 3.3, 3rd bullet: >>>> >>>> How does a service provider know which attributes a client >>>> understands? >>> >>> This was a compromise resolution to a problem in REST that the WG >>> ran into. What does it mean when a client does not assert a value? >>> Is it the intention that the client wants the value cleared (by not >>> asserting it), is the client saying nothing, or does the client >>> expect it to be defaulted. >>> >>> Then there is the issue that access control might be filtering what >>> the client can set or in the response, what can be returned to the >>> client. In other words, the client may not be intending to clear a >>> value because it may not even know about the attribute. >>> >>> I鈥檝e never been happy with the proposed paragraph and would invite >>> alternate proposals. >> >> The "client has access to" part is easier to understand, since the >> service provider presumably knows what attributes it sent, or will >> send, to the client. Would it make sense to just delete the phrase ", >> or understands,"? >> >> [...] >>>> >>>> -- 3.4.2.4, 1st paragraph: "clients SHOULD never >>>> assume repeatable results" >>>> >>>> That seems like a statement of fact, not a normative assertion. >>> >>> Not sure I agree. It is normative in that clients must be prepared >>> to handle inconsistent results during paging. Maybe we can rephrase >>> around the issue? >>> >> >> How about "clients MUST be prepared to handle inconsistent >> results..." :-) >> >> [...] >> >>>> >>>> -- 7.3: >>>> >>>> That needs to be a normative reference. Also, why is this a SHOULD? >>>> Can >>>> you envision scenarios where it might be reasonable for >>>> implementors NOT >>>> to take the countermeasures into account? >>> >>> Well they might not be using OAuth tokens. >>> >>> My understanding since OAuth is optional, it should not be a >>> normative reference. >> >> Even if a feature is optional, a reference that is needed to >> understand and/or implement the feature should still be normative. >> >>> Also, the assertions draft is a work in progress. >> >> I understand that is an issue, but it's not appropriate (or even >> beneficial) to avoid a normative reference due to a dependency block. >> The whole point of that bit of inconvenience is to make sure an RFC >> doesn't depend on a moving target in order for a feature to be >> understood or implemented. >> >>>> >>>> -- 7.4: >>>> >>>> Reference to oauth-assertions needs to be normative. >>> >>> Again, OAuth is optional. >>> >>> Regarding all of the authentication methods described, since they >>> are all optional I have made them all informative unless every >>> implementation MUST support it (e.g. because SCIM depends on it). >>> >>> Correct me if this is editorially incorrect. >> >> IMHO, it is editorially incorrect. Please see my previous comments on >> 7.3. But in any case, I am not holding a discuss on these points--I >> will leave it to Barry to decide how to proceed. >> >>> >>>> >>>> -- 7.6, 2nd bullet >>>> >>>> s/MAY/may >>>> >>>> -- editorial >>>> >>>> -- 2, HOBA paragraph: >>>> >>>> Is this intended as part of the TLS Client Authentication entry? It >>>> doesn't seem so, but the paragraph lacks its own heading. >>> >>> My thinking was it is a profile/variation of TLS client >>> authentication. IOW the only thing that is different is how the keys >>> are managed/distributed. >>> >>> I am open to calling it out as a separate item. >> >> That's okay with me if it was the intent. >> >> [...] From nobody Thu May 14 13:54:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAA1A8A20 for ; Thu, 14 May 2015 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhJXaNXtQcrB for ; Thu, 14 May 2015 13:54:14 -0700 (PDT) Received: from nm25-vm5.bullet.mail.ne1.yahoo.com (nm25-vm5.bullet.mail.ne1.yahoo.com [98.138.91.247]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6731ACD5E for ; Thu, 14 May 2015 13:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431636841; bh=67uR4scPn/e1ascQA7aegG3LvPN+yNmY1cdoSUtgZJQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=SBjeDZo8+uyo7eE49cdY2GxfQAzVF3MQZTbgNnFJ9AzvICSwJy5zTDSveJCLeRtOwn+GiPzkJL2J0fVS3+8J2NpQuApFJwas7juru/JDQsGeREZgWMVYPZoLNSAL6L7MWlp5Jxs5y2EadctYIB7RE+bXSlAPxtxZE5vXfU2ist8esLVWfeMZqQ4BWcKluF/dc2g1vLNuS6MEYO3ZNvLF7afplWYDAufyEYU4AP7pGs2sNePRZtilnSzS6rCRg3lfWqpztlfxCGpWx/5QokN04o0Thu9Xn+2RXzYgM2xg7ufBFLG2m/rNX7Zo1gR3ubQybfpKY6N5WXyPOnVkaxqp6Q== Received: from [98.138.101.131] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2015 20:54:01 -0000 Received: from [98.138.84.39] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 14 May 2015 20:54:00 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 14 May 2015 20:54:00 -0000 X-Yahoo-Newman-Id: 968931.69448.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2Ak_D3MVM1kHPELUpWaLnNAgy7OMp08xJYNuKZFnft2lyGq 8ViBt4VgvuqYMs1CotFtyh090pzbtTmiAa.V1XvAczZcFBaH6pZVCo_AFnC3 tSjbmndTN6J3DyIbukdOaCZ3d3ZsObdozVf9OcrA21UJcgbM6UfsE6vQfA.N sgWT_gHllwpTtVGPUgQE0bJloRxEWjYjGrErgci1mD60kdf4RtXZZQR6beY_ _Oo4FLyEnkYAeKuBbBrkWdYaQzhiTHsDHg6gqP_mHAEOkvLVLrhOJHl7o75X aGX7JukQaraYNwA.YSBxIz4O_NBVOYXoMFaZLkxJMCfqKG1zXJZbVKXUNZXX oohhI2HnGOiBNb7dAZvClPHt61poJnz5D0Y.ESuCUwTomcF_no2RuWjs9Xu_ O0MHui051nh6_PWYx0y_35OPeEVBQ7BFDW2eyFv6KOROBLShmtdlr97xeO14 4hTwo6OnXXZFw.EWa4Ti3iSpvx7fDnRclVckJ4fEC5oNha3SOriEATqTdTym i06HJSiuSu7a378K4PYh8tA-- X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w-- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Thu, 14 May 2015 13:53:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150513023501.18259.11879.idtracker@ietfa.amsl.com> <47161DD8-774D-4518-9752-FE121E526D58@yahoo.com> <12EE2D4E-4F52-4CBB-888C-07E9696C31CC@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-scim-api.ad@ietf.org, scim@ietf.org, draft-ietf-scim-api.shepherd@ietf.org, The IESG , draft-ietf-scim-api@ietf.org, scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-api-18: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:54:17 -0000 Thanks Ben. It was definitely good to bring up.=20 I would like to encourage others to comment if they would like to revise = the versioning section. In the absence of further comment, I will assume we are clear on this = item. Phil phil.hunt@yahoo.com > On May 14, 2015, at 1:48 PM, Ben Campbell wrote: >=20 > For the record, I'm clearing the DISCUSS on the version question, and = moving it to a comment. I only held the discuss to make sure it got = discussed, and that appears to be happening. If the answer comes back as = "it's right as is", I'm okay with that. >=20 > Thanks! >=20 > Ben. >=20 > On 14 May 2015, at 13:37, Phil Hunt wrote: >=20 >> Regarding Ben=E2=80=99s items below on versioning, I think we need = more discussion: >>>>>=20 >>>>>=20 >>>>> -- 3.13: >>>>>=20 >>>>> It's optional (MAY) to include the API version. If the version is >>>>> missing, the service provider SHOULD perform the operation using = the most >>>>> recent supported version. This seems to allow the client and = service >>>>> provider to disagree on the version being used. Does this cause an >>>>> interop problem if the later version is not backwards compatible? = (Are >>>>> all new versions expected to be backwards compatible with old = versions?) >>>>=20 >>>> See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >>>=20 >>> I think this is different than in the previous comment. If a certain = combination of method and attributes means something different in = version N and version N+1, and the client and server leaves out the = version, thinks could break. My suggestion would be to always include = the version--but I understand there might be other reasons not to. An = alternative would be to give guidance about backwards compatibility. = (Even non-normative guidance in the form of "if you do this things might = break" would help.) >>=20 >> I do agree that this section is covering the issue of versioning = somewhat superficially. >>=20 >> The text for this section is fairly old and my understanding is it = represents some of the original SCIM 1 consensus. >>=20 >> My personal worry is I would not want to discourage updates by = encouraging lock-in to specific versions. Better to =E2=80=9Cbreak=E2=80=9D= clients and have them update or re-configure for a specific version. I = think this is mediated by the fact that most cloud providers all have = methodologies capable of delivering rapid and frequent client updates. >>=20 >> =46rom a protocol perspective, the WG has used =E2=80=9Crobust=E2=80=9D= processing principles that require implementations to more be flexible = in what is accepted while strict on fundamentals (e.g. JSON must be = valid). For example, in an earlier thread we talked about how servers = SHOULD ignore search parameters they do not understand. Further, errors = are not supposed to be thrown due to attributes that are not defined - = they are merely ignored. >>=20 >> I think SCIM's design principles should aid implementers in avoiding = many of the backwards compatibility issues we might otherwise = experience. >>=20 >> Never-the-less, maybe we need some cautionary text that deployers = need to consider ramification of breaking changes in the default = version? They need to have an appropriate method for co-ordinating = breaking updates and transition where possible. >>=20 >> Thanks, >>=20 >> Phil >>=20 >> phil.hunt@yahoo.com >>=20 >>> On May 12, 2015, at 10:22 PM, Ben Campbell wrote: >>>=20 >>> Thanks for the quick response. I am okay with your responses to all = the DISCUSS points save the last, and I am only holding that one for a = bit more discussion. (That is, I will probably clear regardless of your = response.) >>>=20 >>> Details inline. I deleted sections that did not appear to need = further discussion. >>>=20 >>> On 12 May 2015, at 23:45, Phil Hunt wrote: >>>=20 >>>> Ben, >>>>=20 >>>> Thanks for the extensive comments. If I have not commented below, = please assume I am agreeing and will make the change. >>>>=20 >>>> Phil >>>>=20 >>>> phil.hunt@yahoo.com >>>>=20 >>>>> On May 12, 2015, at 7:35 PM, Ben Campbell wrote: >>>>>=20 >>>>> Ben Campbell has entered the following ballot position for >>>>> draft-ietf-scim-api-18: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> -- 3.4.2: "SHOULD ignore any query parameters they do not = understand" >>>>>=20 >>>>> I'm curious why this is not a MUST. What are the = alternatives--that is, >>>>> can you envision situations where it might be reasonable to _not_ = ignore >>>>> parameters you don't understand? >>>>=20 >>>> The currently unstated opposite is that a server might choose to = reject the request. I believe the preference is for servers to ignore = what they do not understand for upward compatibility reasons. MUST = ignore seems to harsh. >>>=20 >>> Okay, that makes sense. Some guidance to that effect would be = helpful, but I won't hold the discuss on that. >>>>=20 >>>=20 >>> [...] >>>=20 >>>>>=20 >>>>> -- 3.8: >>>>>=20 >>>>> The first paragraph says servers MUST respond with JSON in UTF-8. = But the >>>>> following paragraphs talk about how the client may request = different >>>>> response formats. This seems contradictory. >>>>=20 >>>> I will adjust. I think some service providers may wish to support = other formats. I don=E2=80=99t think it is our intent to limit here, = just that other formats are beyond scope. >>>=20 >>> Okay >>>=20 >>>>>=20 >>>>> -- 3.13: >>>>>=20 >>>>> It's optional (MAY) to include the API version. If the version is >>>>> missing, the service provider SHOULD perform the operation using = the most >>>>> recent supported version. This seems to allow the client and = service >>>>> provider to disagree on the version being used. Does this cause an >>>>> interop problem if the later version is not backwards compatible? = (Are >>>>> all new versions expected to be backwards compatible with old = versions?) >>>>=20 >>>> See previous comment on ignoring what is not understood. My = understanding this is one of those common practices that goes = underspecified. Happy to take suggestions here. >>>=20 >>> I think this is different than in the previous comment. If a certain = combination of method and attributes means something different in = version N and version N+1, and the client and server leaves out the = version, thinks could break. My suggestion would be to always include = the version--but I understand there might be other reasons not to. An = alternative would be to give guidance about backwards compatibility. = (Even non-normative guidance in the form of "if you do this things might = break" would help.) >>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>=20 >>> [...] >>>=20 >>>>>=20 >>>>> -- 2.1, last paragraph: >>>>>=20 >>>>> Just SHOULD? Do you invision situations where it might be = reasonable >>>>> _not_ to take the threats into account? >>>>>=20 >>>>> Also, the reference to oath-assertions needs to be normative >>>> I=E2=80=99m not sure what you are referring to. paragraph 1 of 2.1 = refers to section 6 of the OAuth Assertions Draft. The last paragraph = does not refer to it. >>>>>=20 >>>=20 >>> Are we looking at the same version (18)? I see the last paragraph of = 2.1 as the following: >>>=20 >>> "Implementers SHOULD take into account the threats and = countermeasuresdocumented in the security considerations for the use of = clientauthorizations see Section 8 of [I-D.ietf-oauth-assertions]." >>>=20 >>>=20 >>> [...] >>>=20 >>>>> -- 3.3, 3rd bullet: >>>>>=20 >>>>> How does a service provider know which attributes a client = understands? >>>>=20 >>>> This was a compromise resolution to a problem in REST that the WG = ran into. What does it mean when a client does not assert a value? Is it = the intention that the client wants the value cleared (by not asserting = it), is the client saying nothing, or does the client expect it to be = defaulted. >>>>=20 >>>> Then there is the issue that access control might be filtering what = the client can set or in the response, what can be returned to the = client. In other words, the client may not be intending to clear a value = because it may not even know about the attribute. >>>>=20 >>>> I=E2=80=99ve never been happy with the proposed paragraph and would = invite alternate proposals. >>>=20 >>> The "client has access to" part is easier to understand, since the = service provider presumably knows what attributes it sent, or will send, = to the client. Would it make sense to just delete the phrase ", or = understands,"? >>>=20 >>> [...] >>>>>=20 >>>>> -- 3.4.2.4, 1st paragraph: "clients SHOULD never >>>>> assume repeatable results" >>>>>=20 >>>>> That seems like a statement of fact, not a normative assertion. >>>>=20 >>>> Not sure I agree. It is normative in that clients must be prepared = to handle inconsistent results during paging. Maybe we can rephrase = around the issue? >>>>=20 >>>=20 >>> How about "clients MUST be prepared to handle inconsistent = results..." :-) >>>=20 >>> [...] >>>=20 >>>>>=20 >>>>> -- 7.3: >>>>>=20 >>>>> That needs to be a normative reference. Also, why is this a = SHOULD? Can >>>>> you envision scenarios where it might be reasonable for = implementors NOT >>>>> to take the countermeasures into account? >>>>=20 >>>> Well they might not be using OAuth tokens. >>>>=20 >>>> My understanding since OAuth is optional, it should not be a = normative reference. >>>=20 >>> Even if a feature is optional, a reference that is needed to = understand and/or implement the feature should still be normative. >>>=20 >>>> Also, the assertions draft is a work in progress. >>>=20 >>> I understand that is an issue, but it's not appropriate (or even = beneficial) to avoid a normative reference due to a dependency block. = The whole point of that bit of inconvenience is to make sure an RFC = doesn't depend on a moving target in order for a feature to be = understood or implemented. >>>=20 >>>>>=20 >>>>> -- 7.4: >>>>>=20 >>>>> Reference to oauth-assertions needs to be normative. >>>>=20 >>>> Again, OAuth is optional. >>>>=20 >>>> Regarding all of the authentication methods described, since they = are all optional I have made them all informative unless every = implementation MUST support it (e.g. because SCIM depends on it). >>>>=20 >>>> Correct me if this is editorially incorrect. >>>=20 >>> IMHO, it is editorially incorrect. Please see my previous comments = on 7.3. But in any case, I am not holding a discuss on these points--I = will leave it to Barry to decide how to proceed. >>>=20 >>>>=20 >>>>>=20 >>>>> -- 7.6, 2nd bullet >>>>>=20 >>>>> s/MAY/may >>>>>=20 >>>>> -- editorial >>>>>=20 >>>>> -- 2, HOBA paragraph: >>>>>=20 >>>>> Is this intended as part of the TLS Client Authentication entry? = It >>>>> doesn't seem so, but the paragraph lacks its own heading. >>>>=20 >>>> My thinking was it is a profile/variation of TLS client = authentication. IOW the only thing that is different is how the keys are = managed/distributed. >>>>=20 >>>> I am open to calling it out as a separate item. >>>=20 >>> That's okay with me if it was the intent. >>>=20 >>> [...] >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Fri May 15 13:03:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1C1A1B40; Fri, 15 May 2015 13:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNCMFJ3hpdDt; Fri, 15 May 2015 13:03:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19391A1B2C; Fri, 15 May 2015 13:03:02 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4FK30QW004160 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 May 2015 20:03:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4FK302c023326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 May 2015 20:03:00 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4FK2xP5028996; Fri, 15 May 2015 20:02:59 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 May 2015 13:02:55 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Fri, 15 May 2015 13:02:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <648E688B-E792-4035-930B-FE5DEBB07D45@oracle.com> References: <20150513211921.24391.24472.idtracker@ietfa.amsl.com> <9412635D-CF41-405E-A2E8-F5D98A6AFD2E@oracle.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: scim@ietf.org, draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org Subject: Re: [scim] Ben Campbell's Discuss on draft-ietf-scim-core-schema-20: (with DISCUSS and COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:03:04 -0000 Please note, I will publish draft 21 in the coming days to handle = Ben=E2=80=99s comments and any other pending comments. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 13, 2015, at 7:26 PM, Ben Campbell wrote: >=20 > Thanks, clearing the discuss now. >=20 > On 13 May 2015, at 18:22, Phil Hunt wrote: >=20 >> Ben, >>=20 >> Thanks again for another review! >>=20 >> Regarding the discuss item, I think you are correct, we should change = password storage from SHOULD NOT to MUST NOT be clear text. >>=20 >> Regarding the other nits, I will apply them to the next edit along = with the above discuss item. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On May 13, 2015, at 2:19 PM, Ben Campbell wrote: >>>=20 >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-scim-core-schema-20: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Hopefully this one will be easy to address: >>>=20 >>> Section 4.1.1, under "password", says that passwords SHOULD be = hashed or >>> encrypted. But the security considerations say that passwords MUST = NOT be >>> stored in clear-text. These seem to be in conflict. (I prefer the = MUST >>> NOT). >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> -- General: >>>=20 >>> As in the API draft, there's quite a bit of misuse of the 2119 "MAY" >>> keyword (details below.) >>>=20 >>> -- 1.1, 3rd paragraph: "... all figures MAY contain spaces." >>>=20 >>> s/MAY/may >>>=20 >>> -- 2.1, 2nd paragraph : "MAY be camel-case" >>>=20 >>> Seems like if they are case insensitive, they can be any case. >>>=20 >>> -- 2.1, last paragraph: "... MAY need to be escaped..." >>>=20 >>> s/MAY/may >>>=20 >>> -- 2.2, 2nd bullet: >>>=20 >>> I assume this refers to the value/content of the attribute, since = the >>> previous section said the attribute name is always case insensitive. >>>=20 >>> -- 2.3.4: >>>=20 >>> integer is defined as a _decimal_ number that MUST NOT contain = fractional >>> or exponent parts. But the definition of =E2=80=9CDecimal=E2=80=9D = says it has to have at >>> least one digit to the right of the period. Do these conflict? Do >>> Integers always need a trailing zero after a period? (I suspect the >>> answer is that you didn=E2=80=99t mean to say Integer was derived = from Decimal, >>> but if so, the use of =E2=80=9Cdecimal=E2=80=9D is confusing.) >>>=20 >>> -- 2.3.7, 2nd to last paragraph, first sentence: >>>=20 >>> To whom does this requirement apply? It sounds like an attempt to = apply a >>> MUST to whatever service a reference happens to refer to. I gather = that >>> could be any arbitrary service addressable with a URL. >>>=20 >>> -- 2.4, paragraph after bullet list : "The pre-defined set of >>> sub-attributes for a multi-valued attribute" >>>=20 >>> I=E2=80=99m not sure what that means. These are the only sub-attrs = that can be >>> used? All multi-valued attributes have these sub-attributes? >>>=20 >>> -- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED >>> attribute that MUST be >>> present" >>>=20 >>> The REQUIRED and MUST are redundant. >>>=20 >>> -- 3.1, first paragraph, last sentence: "SHALL NOT be considered = schema >>> extensions." >>>=20 >>> Should this really be normative? Does =E2=80=9Cconsidering them a = schema >>> extension=E2=80=9D involve observable implementation behavior = differences? >>>=20 >>> -- 3.1, meta/resourceType: "The attribute is REQUIRED when provided = by >>> the service >>> provider." >>>=20 >>> I=E2=80=99m not sure I understand=E2=80=94this seems to say the = attribute is REQUIRED >>> when it is present. (Same wording occurs for multiple attributes) >>>=20 >>> -- 4.1.1, "name" >>>=20 >>> This is defined as components of the user's "real" name. That sounds = like >>> an assertion of a real-name policy. Does the schema really require = real >>> names? >>>=20 >>> -- 4.1.2, "groups" : "... which MAY influence >>> indirect memberships.: >>>=20 >>> s/MAY/may >>>=20 >>> -- same section, "entitlements": "An entitlement MAY be an = additional >>> right" >>>=20 >>> s/MAY/may >>>=20 >>> -- 9.3. 2nd paragraph >>>=20 >>> s/MAY/may (both occurrences) >>>=20 >>> -- 10.3.1: >>>=20 >>> Is there a reason not to use one or more of the well known = registration >>> policies from RFC 5226? >>>=20 >>> Editorial Comments >>>=20 >>> -- 4.1.1, "active" >>> s/infers/implies >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim From nobody Fri May 15 23:04:27 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0A1B2A54; Fri, 15 May 2015 23:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmXg5l5cKFy4; Fri, 15 May 2015 23:04:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B7E1B2A53; Fri, 15 May 2015 23:04:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150516060423.16095.77461.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 23:04:23 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-19.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 06:04:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-api-19.txt Pages : 89 Date : 2015-05-15 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized service. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-api-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 23:11:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCFA1B2A56; Fri, 15 May 2015 23:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m82j2A76r6d; Fri, 15 May 2015 23:11:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FE61B2A59; Fri, 15 May 2015 23:11:00 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4G6AwNw022951 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 May 2015 06:10:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4G6AwUT031162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 16 May 2015 06:10:58 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4G6Awvd005347; Sat, 16 May 2015 06:10:58 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 May 2015 23:10:58 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150516060423.16095.77461.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 23:10:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59C40E6C-0072-44C8-847E-472B7D3C24E0@oracle.com> References: <20150516060423.16095.77461.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: scim@ietf.org, i-d-announce@ietf.org Subject: Re: [scim] I-D Action: draft-ietf-scim-api-19.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 06:11:02 -0000 This draft includes corrections based on feed back from Ben Campbell and = Stephen Farrell on draft 18. For optional features, text describing how a client may discover feature = availability has been added. More reference links have been added as = suggested. Statements of fact using =E2=80=9CMAY=E2=80=9D have been corrected to = non-normative =E2=80=9Cmay=E2=80=9D per 2119. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 15, 2015, at 11:04 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-api-19.txt > Pages : 89 > Date : 2015-05-15 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is an HTTP based protocol that makes managing identities in multi- > domain scenarios easier to support through a standardized service. > Examples include but are not limited to enterprise to cloud service > providers, and inter-cloud based scenarios. The specification suite > seeks to build upon experience with existing schemas and = deployments, > placing specific emphasis on simplicity of development and > integration, while applying existing authentication, authorization, > and privacy models. SCIM's intent is to reduce the cost and > complexity of user management operations by providing a common user > schema, an extension model, and a service protocol defined by this > document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-scim-api-19 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon May 18 08:16:45 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235A1A913E for ; Mon, 18 May 2015 08:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxFFl74TOEFU for ; Mon, 18 May 2015 08:16:38 -0700 (PDT) Received: from mail-wg0-f69.google.com (mail-wg0-f69.google.com [74.125.82.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DA51A913D for ; Mon, 18 May 2015 08:16:20 -0700 (PDT) Received: by wgtl5 with SMTP id l5so55257950wgt.1 for ; Mon, 18 May 2015 08:16:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=psdkPV+dQSozNZcgJtbzDTX2/JsSgy1nzuddS1G/oyQ=; b=VivNhL64GL+H/FAmxDm8iyDv3H3fadrEW8tciJJ1rWkOXI1xG9QbzI++yVboMFwryM OOwmuHiOZIA0nCvZUhw/xhC3I659jKU7gzC0yUK04Em/hKACnE9YRSLCFqZ1mx8eCxG/ UEYaef2uDNPwA6izLrSy/RKTsReQHyZ7lnZJLWoWCMrwMgiDkTWLKzArDTgTlQQm1LJn iCzXQceyLalHdInDyXYgf0Eu7ZXdlDkrTzhyIjRe/fftmEbJaqMqwRGJt6qv7+aGDt0D 8vcEd1dbMj0fUKgt32dVKEpzXC7Jb/ZQxGeThPBo1PaiIFOxu2i75S86RGmtG7QsKSj8 OCKw== X-Gm-Message-State: ALoCoQked+M5GhOLP5RkPYRDzHumR4lNut1+MKCDiUGHWH2mSHbImTpPyHfcuO6CnOTsD/yXBLuI MIME-Version: 1.0 X-Received: by 10.180.19.198 with SMTP id h6mr22963720wie.60.1431962178534; Mon, 18 May 2015 08:16:18 -0700 (PDT) Received: by 10.180.97.10 with HTTP; Mon, 18 May 2015 08:16:18 -0700 (PDT) Date: Mon, 18 May 2015 17:16:18 +0200 Message-ID: From: David Crome To: scim@ietf.org Content-Type: multipart/alternative; boundary=bcaec53d5303fbd61405165caca9 Archived-At: Subject: [scim] How to handle multi-valued attribute elements with none sub-attributes set X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:16:42 -0000 --bcaec53d5303fbd61405165caca9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, If I create a user with an multi-valued attribute e.g. an address and none sub-attributes are set: "addresses": [ { } ] Should the Service Provider ignore means truncated the multi-value attribute or not accepting the user? I don't think the specification makes this clear. What is the definition of an empty multi-valued attribute element? The specification don't mentioned anything about if a multi-valued attribute element is empty and how the Service Provider should handle this. Same for the complex attribute 'name' [1]. If the complex attribute 'name' has no sub-attributes set, what should the Service Provider do with the empty attribute? I think a complex attribute or multi-valued attribute element is empty when none sub-attribute is set, like the example above. The Service Provider should ignore the empty attribute. And if I create a user with an multi-valued attribute e.g. an address with only the 'primary' sub-attribute set: "addresses": [ { "primary": true } ] Should this be accepted? SCIM spec says that all sub-attributes of a multi-valued attribute element (in this case the address) are optional [2]. I think it doesn't makes sense to accept a multi-valued attribute element if only the meta sub-attribute 'primary' is set. I think in this case the user should not be accepted because the attribute is not complete. Another one: In case of the multi-valued attribute 'emails' the sub-attribute 'value' "...SHOULD be specified according to [RFC5321]". But what if the 'value' attribute is missing? Same for the other multi-valued attributes with the possibility to validate the 'value' sub-attribute. What do you think? Greetz, David [1] https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#section-2.3.= 8 [2] https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#section-4.1.= 2 --=20 David Crome Softwareentwicklung tarent solutions GmbH Telefon +49 (0) 30 138803-132 Telefax +49 (0) 30 56829495 d.crome@tarent.de tarent solutions GmbH Niederlassung Berlin Voltastra=C3=9Fe 5, D-13355 Berlin =E2=80=A2 http://www.tarent.de/ Tel: +49 30 138803-0 =E2=80=A2 Fax: +49 30 56829495 Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg --bcaec53d5303fbd61405165caca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

If I create a user with an multi= -valued attribute e.g. an address and none sub-attributes are set:

"addresses": [
=C2=A0 =C2=A0= {

=C2=A0 =C2=A0 }
]

Should the Service Provider ignore means truncated the mu= lti-value attribute or not accepting the user? I don't think the specif= ication makes this clear.
What is the definition of an empty mult= i-valued attribute element? The specification don't mentioned anything = about if a multi-valued attribute element is empty and how the Service Prov= ider should handle this.
Same for the complex attribute 'name= ' [1]. If the complex attribute 'name' has no sub-attributes se= t, what should the Service Provider do with the empty attribute?=C2=A0

I think a complex attribute or multi-valued attribute = element is empty when none sub-attribute is set, like the example above. Th= e Service Provider should ignore the empty attribute.

And if I create a user with an multi-valued attribute e.g. an addre= ss with only the 'primary' sub-attribute set:

"addresses": [
=C2=A0 =C2=A0 {
<= div>=C2=A0 =C2=A0 =C2=A0 "primary": true
=C2=A0 =C2=A0 = }
]

Should this be accepted?= SCIM spec says that all sub-attributes of a multi-valued attribute element= (in this case the address) are optional [2].
I think it doesn= 9;t makes sense to accept a multi-valued attribute element if only the meta= sub-attribute 'primary' is set.

I thi= nk in this case the user should not be accepted because the attribute is no= t complete.

Another one: In case of the multi-= valued attribute 'emails' the sub-attribute 'value' =C2=A0&= quot;...SHOULD be specified according to [RFC5321]". But what if the &= #39;value' attribute is missing? Same for the other multi-valued attrib= utes with the possibility to validate the 'value' sub-attribute.

What do you think?

Greetz,
David

[1]=C2=A0https:= //tools.ietf.org/html/draft-ietf-scim-core-schema-20#section-2.3.8
<= /div>

--
= David Crome
Softwareentwicklung
tarent solutions G= mbH

Telefon +49 (0) 30 138803-132
= Telefax +49 (0) 30 56829495

tarent sol= utions GmbH Niederlassung Berlin
Voltastra=C3=9Fe 5, D-13355 Berl= in =E2=80=A2 http://www= .tarent.de/
Tel: +49 30 138803-0 =E2=80=A2 Fax: +49 30 568294= 95

Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 <= a href=3D"http://www.tarent.de/" target=3D"_blank">http://www.tarent.de/
Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4= ftsf=C3=BChrer:
Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alex= ander Steeg
--bcaec53d5303fbd61405165caca9-- From nobody Mon May 18 09:50:11 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5A1AC44E for ; Mon, 18 May 2015 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSjQtxpX4q5X for ; Mon, 18 May 2015 09:50:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1284F1AD0CA for ; Mon, 18 May 2015 09:50:08 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4IGo6tP007239 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 May 2015 16:50:07 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4IGo6ZM019221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2015 16:50:06 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4IGo5B8029261; Mon, 18 May 2015 16:50:05 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 May 2015 09:50:05 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B965FDA-DC04-4D1E-8D9D-EB1F86A3F0AA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Mon, 18 May 2015 09:50:03 -0700 Message-Id: <3EF0BE6F-56D2-4FA3-B0E0-0799DEC578F3@oracle.com> References: To: David Crome X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: scim@ietf.org Subject: Re: [scim] How to handle multi-valued attribute elements with none sub-attributes set X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:50:11 -0000 --Apple-Mail=_5B965FDA-DC04-4D1E-8D9D-EB1F86A3F0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 David, The service provider some flexibility on what it can choose to do. The = only stipulation is: The spec says that a client asserting null or empty intends that the = attribute be cleared (e.g. no default). The request must be valid JSON. One way that this scenario can be improved, is through configured schema = using attribute =E2=80=9Crequired=E2=80=9D characteristic on parent = attribute vs sub-attributes. You can leave =E2=80=9Caddresses=E2=80=9D = as not required, while making sub-attributes of a complex attribute = required. This way, if an address is specified, certain sub-attributes = must be present. After that the service provider can do what makes sense in the context = of the environment or application it is provisioning to. If it makes = sense to accept partial addresses / or ignore them, thats ok. Whatever = the service provider decides to do, it should return the =E2=80=9Caccepted= =E2=80=9D state back to the client in the response to the request. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 18, 2015, at 8:16 AM, David Crome wrote: >=20 > Hello, >=20 > If I create a user with an multi-valued attribute e.g. an address and = none sub-attributes are set: >=20 > "addresses": [ > { >=20 > } > ] >=20 > Should the Service Provider ignore means truncated the multi-value = attribute or not accepting the user? I don't think the specification = makes this clear. > What is the definition of an empty multi-valued attribute element? The = specification don't mentioned anything about if a multi-valued attribute = element is empty and how the Service Provider should handle this. > Same for the complex attribute 'name' [1]. If the complex attribute = 'name' has no sub-attributes set, what should the Service Provider do = with the empty attribute?=20 >=20 > I think a complex attribute or multi-valued attribute element is empty = when none sub-attribute is set, like the example above. The Service = Provider should ignore the empty attribute. >=20 > And if I create a user with an multi-valued attribute e.g. an address = with only the 'primary' sub-attribute set: >=20 > "addresses": [ > { > "primary": true > } > ] >=20 > Should this be accepted? SCIM spec says that all sub-attributes of a = multi-valued attribute element (in this case the address) are optional = [2]. > I think it doesn't makes sense to accept a multi-valued attribute = element if only the meta sub-attribute 'primary' is set. >=20 > I think in this case the user should not be accepted because the = attribute is not complete. >=20 > Another one: In case of the multi-valued attribute 'emails' the = sub-attribute 'value' "...SHOULD be specified according to [RFC5321]". = But what if the 'value' attribute is missing? Same for the other = multi-valued attributes with the possibility to validate the 'value' = sub-attribute. >=20 > What do you think? >=20 > Greetz, > David >=20 > [1] = https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#section-2.3.8 = = > [2] = https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#section-4.1.2 = = >=20 > --=20 > David Crome > Softwareentwicklung > tarent solutions GmbH >=20 > Telefon +49 (0) 30 138803-132 > Telefax +49 (0) 30 56829495 > d.crome@tarent.de >=20 > tarent solutions GmbH Niederlassung Berlin > Voltastra=C3=9Fe 5, D-13355 Berlin =E2=80=A2 http://www.tarent.de/ = > Tel: +49 30 138803-0 =E2=80=A2 Fax: +49 30 56829495 >=20 > Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/ = > Tel: +49 228 54881-0 =E2=80=A2 Fax: +49 228 54881-235 > HRB AG Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941 > Gesch=C3=A4ftsf=C3=BChrer: > Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_5B965FDA-DC04-4D1E-8D9D-EB1F86A3F0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
David,

The service provider some flexibility = on what it can choose to do. The only stipulation is:

The spec says that a = client asserting null or empty intends that the attribute be cleared = (e.g. no default).

The request must be valid JSON.

One way that this scenario can be = improved, is through configured schema using attribute =E2=80=9Crequired=E2= =80=9D characteristic on parent attribute vs sub-attributes.  You = can leave =E2=80=9Caddresses=E2=80=9D as not required, while making = sub-attributes of a complex attribute required.  This way, if an = address is specified, certain sub-attributes must be present.

After that the service = provider can do what makes sense in the context of the environment or = application it is provisioning to. If it makes sense to accept partial = addresses / or ignore them, thats ok.  Whatever the service = provider decides to do, it should return the =E2=80=9Caccepted=E2=80=9D = state back to the client in the response to the request. =  


On May 18, 2015, at 8:16 AM, David Crome <d.crome@tarent.de> = wrote:

Hello,

If I create a user with an multi-valued attribute e.g. an = address and none sub-attributes are set:

"addresses": [
    {

    = }
]

Should the Service Provider ignore = means truncated the multi-value attribute or not accepting the user? I = don't think the specification makes this clear.
What = is the definition of an empty multi-valued attribute element? The = specification don't mentioned anything about if a multi-valued attribute = element is empty and how the Service Provider should handle = this.
Same for the complex attribute 'name' [1]. If = the complex attribute 'name' has no sub-attributes set, what should the = Service Provider do with the empty attribute? 

I think a complex = attribute or multi-valued attribute element is empty when none = sub-attribute is set, like the example above. The Service Provider = should ignore the empty attribute.
And if I create a user with an = multi-valued attribute e.g. an address with only the 'primary' = sub-attribute set:

"addresses": [
    {
      "primary": true
    }
]

Should this be accepted? = SCIM spec says that all sub-attributes of a multi-valued attribute = element (in this case the address) are optional [2].
I think it doesn't makes sense to accept a multi-valued = attribute element if only the meta sub-attribute 'primary' is set.

I = think in this case the user should not be accepted because the attribute = is not complete.

Another one: In case of the = multi-valued attribute 'emails' the sub-attribute 'value' =  "...SHOULD be specified according to [RFC5321]". But what if the = 'value' attribute is missing? Same for the other multi-valued attributes = with the possibility to validate the 'value' sub-attribute.

What do you think?

Greetz,
David

[1] https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#sect= ion-2.3.8
[2] https://tools.ietf.org/html/draft-ietf-scim-core-schema-20#sect= ion-4.1.2

--
David Crome
Softwareentwicklung
tarent solutions = GmbH

Telefon +49 (0) 30 138803-132
Telefax = +49 (0) 30 56829495
d.crome@tarent.de

tarent solutions GmbH Niederlassung = Berlin
Voltastra=C3=9Fe 5, D-13355 Berlin =E2=80=A2 = http://www.tarent.de/
Tel: +49 30 = 138803-0 =E2=80=A2 Fax: +49 30 56829495

Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80= =A2 http://www.tarent.de/
Tel: +49 228 = 54881-0 =E2=80=A2 Fax: +49 228 54881-235
HRB AG = Bonn 5168 =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer:
Dr. Stefan = Barth, Kai Ebenrett, Boris Esser, Alexander = Steeg
_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_5B965FDA-DC04-4D1E-8D9D-EB1F86A3F0AA-- From nobody Mon May 18 13:42:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15221ACD0C; Mon, 18 May 2015 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SEX=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEDXrkUK-SOn; Mon, 18 May 2015 13:42:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC5A1A1A7F; Mon, 18 May 2015 13:42:30 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4IKgNX9003057 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 May 2015 20:42:23 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4IKgNTR028134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2015 20:42:23 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4IKgMFH028327; Mon, 18 May 2015 20:42:22 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 May 2015 13:42:22 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150514084221.1560.60262.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 13:42:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150514084221.1560.60262.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Stephen Farrell's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 20:42:33 -0000 Stephen, Thanks for your feedback! Comments inline. =20 I plan to post draft 21 including these comments later today. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 14, 2015, at 1:42 AM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-scim-core-schema-20: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - intro: I've no idea what "a general profile service for > in-domain applications" might be. =20 ok. added "(e.g., a directory)=E2=80=9D as an example. >=20 > - intro: hmm, the pass-info-to-3rd-party is a bit unsettling > all right. I think some earlier discussion resuled in a > suggested addition that should help, so I'd just like to add > more backing to the idea that such warnings can be useful. > Maybe there ought also be a way to annotate elements to say > that such "sharing" is not allowed? (As a future extension, if > that can be done.) Agreed. I=E2=80=99m not aware of any current proposals.=20 >=20 > - 2.3.5: I didn't have time to chase the references here but > is the TZ always clear in this encoding? And does 2015-01-01 > mean all 24 hours of Jan 1 this year or just the first second > of that day? The reference in XML-schema says that no properties except = timezoneOffset are permitted to be absent. Therefore time must always = be included. I will add text indicating such in case some don=E2=80=99t = want to chase the reference. >=20 > - 3.1: lastModified - this is sometimes used as a secondary > thing to authenticate the system to a user and so in some > cases could be somewhat sensitive if it were world readable, > or easily readable by someone who wanted to spoof as a server > to a valid user. Not sure if that's worth a note here. > Probably not. >=20 > - 4.1.1: password, I agree with Ben's ex-DISCUSS. Section > 8.7.1 also says that the password element contains the > cleartext password which definitely needs fixing. Should be fixed. Added further clarification for draft 21. Let me know = if this works. >=20 > - 4.1: why only x509Certificates? I think you should also > allow PGP keys in some form or else generalise to "public key > containers" that would allow both plus "bare" public keys > maybe of varying forms. This is not a discuss because it > could be fixed later, but the current design is IMO wrong in > this respect and would be better fixed now. Agreed. However, I think the consensus is to continue with the current = definition due to a desire to follow the LDAP definition. I think a future extension could handle this more generically. This = might fit in as part of the overall discussion around credential = management that has been proposed in the WG. >=20 > - 4.1: if you do keep an element named x509Certificates then > it may be worth adding a negative bit of guideance such as > 'Each value here contains exactly one (base64) encoding of a > DER encoding of a Certificate data structure. A single value > MUST NOT contain multiple certificates and so does not contain > the encoding of a "SEQUENCE OF Certificate" in any guise.' It > has been a while since it's been done afresh but I've seen > that mistake in the past and it causes interop problems. Agreed. I have added this to the definition. >=20 > - 8.x: Nice that Olson gets a hat-tip in the TZ definition! >=20 > - 8.x: I hope someone has carefully read the schema stuff > recently - it's long and detailed and I didn't have time. Yes. We did have to correct a few characteristics that have evolved over = time during WG consensus process. >=20 > - Thanks for section 9.3! >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon May 18 14:43:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09B1A914A; Mon, 18 May 2015 14:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHDvHMWEcOC1; Mon, 18 May 2015 14:43:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198C61A9036; Mon, 18 May 2015 14:43:54 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4ILhpFa007070 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 May 2015 21:43:51 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4ILhoIM031274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2015 21:43:50 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4ILhoNB017691; Mon, 18 May 2015 21:43:50 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 May 2015 14:43:50 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <20150514084750.1519.73097.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 14:43:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150514084750.1519.73097.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Benoit Claise's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:43:56 -0000 Comments inline. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 14, 2015, at 1:47 AM, Benoit Claise wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-scim-core-schema-20: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Here is Qin's OPS DIR review: >=20 > I think this draft is ready for publication. Here are a few editorial > comments: >=20 > 1. Section 1.1 =E2=80=9CRequirements Notation and Conventions=E2=80= =9D >=20 >=20 >=20 > I am wondering how RFC2119 languages are applied to this document, >=20 > In Section 4.1.1, =E2=80=9CRECOMMENDED=E2=80=9D is applied to the = attribute =E2=80=9CuserName=E2=80=9D by > adding >=20 > =E2=80=9CRECOMMENDED=E2=80=9D at the end of attribute =E2=80=9CuserName=E2= =80=9D description. >=20 > In section 7, =E2=80=9CDEFAULT=E2=80=9Dis applied to subattibute = =E2=80=9Creadwrite=E2=80=9D by adding > =E2=80=9CDEFAULT=E2=80=9D >=20 > at the end of =E2=80=9Creadwrite=E2=80=9D sub-attribute description. = =E2=80=9CDEFAULT=E2=80=9D seems not > RFC2119 language. >=20 > Therefore RFC2119 language used to apply to some attribute seems not > consistent with other >=20 > language(e.g., DEFAULT) applied to some other attributes. Or the = language > used at the end of >=20 > each attribute is not totally RFC2119 language. >=20 >=20 >=20 > Please distinct where RFC2119 language is used from where other > language(e.g.,=E2=80=9DDEFAULT=E2=80=9D ) is >=20 > used in the draft. Since we make heavy use of OPTIONAL and REQUIRED, I have added these = keywords to the requirements notations and conventions section. >=20 >=20 >=20 > 2. Section 2.2 said: >=20 > =E2=80=9C >=20 > 2.2. Attribute Data Types >=20 >=20 >=20 > Attribute data types are derived from JSON [RFC7159] and unless >=20 > otherwise specified have the following characteristics (see Section >=20 > 7 for attribute characteristic definitions): >=20 >=20 >=20 > =E2=80=9D >=20 > Who has the following characteristics, attribute data types or > attributes? >=20 > If it is the former,I am not sure all the attribute data types listed > here have >=20 > the following characteristics(e.g., mutability, and returnability, > uniqueness), >=20 > For example. Boolean and Integer, Decimal are not of type string. >=20 > Attribute data type =E2=80=9CReference=E2=80=9D is not case = insensitive. >=20 > Can you give an example to explain the attribute data types are > modifiable? >=20 > Or attributes corresponding to attribute data type listed here are > modifiable? >=20 > How to understand attribute data type are returned in response to > queries? >=20 > Are you saying attribute corresponding to attribute data types listed > here are >=20 > usually returned in response to queries? I=E2=80=99m not sure you were commenting on draft 20. Attribute = characteristics were broken out from data types to make it clear that = characteristics refer to attribute qualities (e.g., mutability, = returnability, etc) and are distinct from data types. >=20 >=20 >=20 > 3. Section 3.1 said: >=20 > =E2=80=9C >=20 > For backwards compatibility reasons, some existing schema MAY list >=20 > common attributes as part of the schema. The attribute >=20 > characteristics listed here SHALL take precedence. >=20 > =E2=80=9D > Where the attribute characteristics are listed here? Section 7? >=20 > It looks what is listed here are a list of common attributes? What am = I > missing? >=20 > Also please clarify how to understand =E2=80=9Ctake precedence of = these attribute > characteristics =E2=80=9D? New text: For backwards compatibility reasons, some existing schema definitions = MAY list common attributes as part of the schema. The attribute characteristics (see Section 2.2) listed here SHALL take precedence over older definitiions that may be included in existing schemas. What we are saying is that having common attributes in actual schemas = are not needed because they can=E2=80=99t change and are present in = every object. However for backwards compatibility reasons, it is = acceptable to still include them. In other words we don=E2=80=99t want a User schema to define an = attribute differently than Group does. >=20 >=20 >=20 > 4. Section 3.2 said >=20 > =E2=80=9C >=20 > In order to offer new types of resources, a >=20 > service provider defines the new resource type as specified in >=20 > Section 6and defines a schema representation (see Section 8.7). >=20 > =E2=80=9D >=20 > Miss a blank space between =E2=80=9Csection 6=E2=80=9D and =E2=80=9Cand=E2= =80=9D in this sentence. >=20 >=20 >=20 > 5. Section 6 said: >=20 > =E2=80=9C >=20 > The following Singular Attributes are defined: >=20 >=20 >=20 > id >=20 > The resource type's server unique id. Often this is the same >=20 > value as the "name" attribute. OPTIONAL >=20 >=20 >=20 > name >=20 > The resource type name. When applicable service providers MUST >=20 > specify the name specified in the core schema specification; = e.g., >=20 > "User" or "Group". This name is referenced by the >=20 > "meta.resourceType" attribute in all resources. >=20 > =E2=80=9D >=20 > It looks not all the attributes are suffixed with > =E2=80=9CRECOMMEND=E2=80=9D,=E2=80=9DREQUIRED=E2=80=9D,=E2=80=9DOPTIONAL= =E2=80=9D,=E2=80=9DDEFAULT=E2=80=9D. >=20 > So what is the default characteristics pertaining to the attribute if = it > is not suffixed with =E2=80=9CRECOMMEND=E2=80=9D, >=20 > =E2=80=9DREQUIRED=E2=80=9D,=E2=80=9DOPTIONAL=E2=80=9D,=E2=80=9DDEFAULT=E2= =80=9D? >=20 > If there is no default characteristics associated with the attribute,=20= > For consistency, I think each attribute >=20 > should add a suffix like = =E2=80=9CDEFAULT=E2=80=9D,=E2=80=9DRECOMMENDED=E2=80=9D,=E2=80=9DREQUIRED=E2= =80=9D. >=20 >=20 >=20 > 6. Section 7 said: >=20 > =E2=80=9C >=20 > "Schema" resources have mutability of "readOnly" >=20 > and are identified using the following schema URI: >=20 > =E2=80=9D >=20 > Is SCIM Resources =E2=80=9Cshema=E2=80=9Dresource? >=20 > If they are the same thing, please use consistent terminology. I=E2=80=99m not sure of the disconnect here. I have added some text that = *might* help. >=20 >=20 >=20 > 7. Section 7 also said: >=20 > =E2=80=9C >=20 > id >=20 > The unique URI of the schema. When applicable service providers >=20 > MUST specify the URI specified in the core schema specification; >=20 > e.g., "urn:ietf:params:scim:schemas:core:2.0:User". Unlike most >=20 > other schemas, which use some sort of a GUID for the "id", the >=20 > schema "id" is a URI so that it can be registered and is portable >=20 > between different service providers and clients. >=20 > =E2=80=9D >=20 > Does attribute =E2=80=9Cid=E2=80=9D has the attribute characteristics = described in > section 2.2? i.e., I have made some clarifications that set defaults and added REQUIRED and = OPTIONAL where missing. >=20 > =E2=80=9C >=20 > o are OPTIONAL (is not required). >=20 >=20 >=20 > o are case insensitive ("caseExact" is "false"), >=20 >=20 >=20 > o are modifiable ("mutability" is "readWrite"), >=20 >=20 >=20 > o are returned in response to queries (returned by default), >=20 >=20 >=20 > o have no canonical values (e.g. type is "home" or "work"), >=20 >=20 >=20 > o are not unique ("uniqueness" is "none"), and, >=20 >=20 >=20 > o of type string (Section 2.2.1). >=20 > =E2=80=9D >=20 > 8. Section 8.6 said: >=20 > =E2=80=9C >=20 >=20 >=20 > The following is a non-normative example of the SCIM resource types >=20 > in JSON format. >=20 > =E2=80=9D >=20 > Section 7 said, A SCIM resource type can be =E2=80=9Cuser=E2=80=9D or = =E2=80=9Cgroup=E2=80=9D. I am > wondering how represented >=20 > using JSON format in the example of section 8.6? >=20 > Using schema attribute >=20 > =E2=80=9C >=20 > "schema": "urn:ietf:params:scim:schemas:core:2.0:User" >=20 > =E2=80=9D >=20 > Or using combination of several attribute, e.g., = =E2=80=9Cid=E2=80=9D,=E2=80=9Dname=E2=80=9D,etc. I think you are referring to Section 6. It mentions that name can be for = example =E2=80=9CUser=E2=80=9D, =E2=80=9CGroup=E2=80=9D. Nothing here = precludes other names. A resource type is most often referred by =E2=80=9Cname=E2=80=9D. = =E2=80=9Cid=E2=80=9D was added for consistency reasons and is usually = the same value as =E2=80=9Cname=E2=80=9D as stated. >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon May 18 15:01:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD81A7113; Mon, 18 May 2015 15:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGdbh0YUYZex; Mon, 18 May 2015 15:01:05 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C61A1A7022; Mon, 18 May 2015 15:01:05 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4IM0wnu022651 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 May 2015 00:00:59 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t4IM0s4e016770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2015 00:00:56 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1431986458; bh=HuVxuonTezYcgdcPjhTqkAzQcFoAyF3Yd+4tY/yeLOw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=a0YpFpMdg9ncWE9q1jWBgYJFzqO1DO8XsKDiMpjclpeYo4p0rJx4onkcjcNmDCFzz UFzk9UJ47+/wR/1CVpc5kek7ZCNbir5jQLI0kvsoJ4fUYN6WeGe3/RSKssltN0iC5x AVacYZcmqhXkV5aiuOcm384aAyS1NyTr4Q9duu10= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Tue, 19 May 2015 00:00:53 +0200 Message-ID: <555A6115.6070802@sunet.se> Date: Tue, 19 May 2015 00:00:53 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt , Stephen Farrell References: <20150514084221.1560.60262.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Oty0XJs - d7b01644d79c - 20150519 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Stephen Farrell's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:01:08 -0000 >> - intro: hmm, the pass-info-to-3rd-party is a bit unsettling >> all right. I think some earlier discussion resuled in a >> suggested addition that should help, so I'd just like to add >> more backing to the idea that such warnings can be useful. >> Maybe there ought also be a way to annotate elements to say >> that such "sharing" is not allowed? (As a future extension, if >> that can be done.) > > Agreed. I鈥檓 not aware of any current proposals. A warning we can do. And it will be ignored (or at best passed to lawyers) but I'm not sure SCIM is the right place to design a privacy-layer for pass-by-value. Cheers Leif From nobody Tue May 19 00:17:07 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC381AC436; Tue, 19 May 2015 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3her-0570oB7; Tue, 19 May 2015 00:17:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755C1ACDB1; Tue, 19 May 2015 00:16:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150519071656.21667.8186.idtracker@ietfa.amsl.com> Date: Tue, 19 May 2015 00:16:56 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-21.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 07:17:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Phil Hunt Kelly Grizzle Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-21.txt Pages : 94 Date : 2015-05-19 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-scim-core-schema-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 19 05:24:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584951B2E67; Tue, 19 May 2015 05:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r_tlBb0IMct; Tue, 19 May 2015 05:24:00 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AE01A90D5; Tue, 19 May 2015 05:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8872; q=dns/txt; s=iport; t=1432038240; x=1433247840; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gLTcWIwPMljVUeCZ6TXK4vlKM8Om3wjB62qF3Bii9Nw=; b=DZGvcW4NUNNwj6i/rj6DGG/0USvWq6XKlMt/WV32lOTDQ/HEAAU/SsLT QSZ6+pu0aETvQ5MWei7fWFfOHNi9bXAlo4n4EfZQk0Yb25nZaQWL/i+d4 Nps3N9Cqd1enqIR4K5N6uI+mb4cVaHI1fL7w7RbKm5eVQhw9Wer2nyK/n E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBAC4KltV/xbLJq1cg2Regx7BdoFPCoV2AoF2EgEBAQEBAQGBCoQjAQEEAQEBIA8BBRElCxAJAhgCAgUhAgIPAhYwBg0BBQIBAYgoDZNynQekPQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoZhCIRAQZLB4JogUUBBIZlhFyLW4JMhAGBJ4NoglyPJCNhgQUkHBWBPzwxAYELgToBAQE X-IronPort-AV: E=Sophos;i="5.13,458,1427760000"; d="scan'208";a="486123731" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 19 May 2015 12:23:56 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4JCNrVO019141; Tue, 19 May 2015 12:23:54 GMT Message-ID: <555B2B59.80700@cisco.com> Date: Tue, 19 May 2015 14:23:53 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt References: <20150514084750.1519.73097.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-scim-core-schema.ad@ietf.org, draft-ietf-scim-core-schema@ietf.org, draft-ietf-scim-core-schema.shepherd@ietf.org, The IESG , scim-chairs@ietf.org, scim@ietf.org Subject: Re: [scim] Benoit Claise's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 12:24:03 -0000 Thank you Phil. We should be good now. Regards, Benoit > Comments inline. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On May 14, 2015, at 1:47 AM, Benoit Claise wrote: >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-scim-core-schema-20: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Here is Qin's OPS DIR review: >> >> I think this draft is ready for publication. Here are a few editorial >> comments: >> >> 1. Section 1.1 鈥淩equirements Notation and Conventions鈥 >> >> >> >> I am wondering how RFC2119 languages are applied to this document, >> >> In Section 4.1.1, 鈥淩ECOMMENDED鈥 is applied to the attribute 鈥渦serName鈥 by >> adding >> >> 鈥淩ECOMMENDED鈥 at the end of attribute 鈥渦serName鈥 description. >> >> In section 7, 鈥淒EFAULT鈥漣s applied to subattibute 鈥渞eadwrite鈥 by adding >> 鈥淒EFAULT鈥 >> >> at the end of 鈥渞eadwrite鈥 sub-attribute description. 鈥淒EFAULT鈥 seems not >> RFC2119 language. >> >> Therefore RFC2119 language used to apply to some attribute seems not >> consistent with other >> >> language(e.g., DEFAULT) applied to some other attributes. Or the language >> used at the end of >> >> each attribute is not totally RFC2119 language. >> >> >> >> Please distinct where RFC2119 language is used from where other >> language(e.g.,鈥滵EFAULT鈥 ) is >> >> used in the draft. > Since we make heavy use of OPTIONAL and REQUIRED, I have added these keywords to the requirements notations and conventions section. >> >> >> 2. Section 2.2 said: >> >> 鈥 >> >> 2.2. Attribute Data Types >> >> >> >> Attribute data types are derived from JSON [RFC7159] and unless >> >> otherwise specified have the following characteristics (see Section >> >> 7 for attribute characteristic definitions): >> >> >> >> 鈥 >> >> Who has the following characteristics, attribute data types or >> attributes? >> >> If it is the former,I am not sure all the attribute data types listed >> here have >> >> the following characteristics(e.g., mutability, and returnability, >> uniqueness), >> >> For example. Boolean and Integer, Decimal are not of type string. >> >> Attribute data type 鈥淩eference鈥 is not case insensitive. >> >> Can you give an example to explain the attribute data types are >> modifiable? >> >> Or attributes corresponding to attribute data type listed here are >> modifiable? >> >> How to understand attribute data type are returned in response to >> queries? >> >> Are you saying attribute corresponding to attribute data types listed >> here are >> >> usually returned in response to queries? > I鈥檓 not sure you were commenting on draft 20. Attribute characteristics were broken out from data types to make it clear that characteristics refer to attribute qualities (e.g., mutability, returnability, etc) and are distinct from data types. >> >> >> 3. Section 3.1 said: >> >> 鈥 >> >> For backwards compatibility reasons, some existing schema MAY list >> >> common attributes as part of the schema. The attribute >> >> characteristics listed here SHALL take precedence. >> >> 鈥 >> Where the attribute characteristics are listed here? Section 7? >> >> It looks what is listed here are a list of common attributes? What am I >> missing? >> >> Also please clarify how to understand 鈥渢ake precedence of these attribute >> characteristics 鈥? > New text: > For backwards compatibility reasons, some existing schema definitions MAY list > common attributes as part of the schema. The attribute > characteristics (see Section 2.2) listed here SHALL take precedence > over older definitiions that may be included in existing schemas. > > What we are saying is that having common attributes in actual schemas are not needed because they can鈥檛 change and are present in every object. However for backwards compatibility reasons, it is acceptable to still include them. > > In other words we don鈥檛 want a User schema to define an attribute differently than Group does. > >> >> >> 4. Section 3.2 said >> >> 鈥 >> >> In order to offer new types of resources, a >> >> service provider defines the new resource type as specified in >> >> Section 6and defines a schema representation (see Section 8.7). >> >> 鈥 >> >> Miss a blank space between 鈥渟ection 6鈥 and 鈥渁nd鈥 in this sentence. >> >> >> >> 5. Section 6 said: >> >> 鈥 >> >> The following Singular Attributes are defined: >> >> >> >> id >> >> The resource type's server unique id. Often this is the same >> >> value as the "name" attribute. OPTIONAL >> >> >> >> name >> >> The resource type name. When applicable service providers MUST >> >> specify the name specified in the core schema specification; e.g., >> >> "User" or "Group". This name is referenced by the >> >> "meta.resourceType" attribute in all resources. >> >> 鈥 >> >> It looks not all the attributes are suffixed with >> 鈥淩ECOMMEND鈥,鈥漅EQUIRED鈥,鈥漁PTIONAL鈥,鈥滵EFAULT鈥. >> >> So what is the default characteristics pertaining to the attribute if it >> is not suffixed with 鈥淩ECOMMEND鈥, >> >> 鈥漅EQUIRED鈥,鈥漁PTIONAL鈥,鈥滵EFAULT鈥? >> >> If there is no default characteristics associated with the attribute, >> For consistency, I think each attribute >> >> should add a suffix like 鈥淒EFAULT鈥,鈥漅ECOMMENDED鈥,鈥漅EQUIRED鈥. >> >> >> >> 6. Section 7 said: >> >> 鈥 >> >> "Schema" resources have mutability of "readOnly" >> >> and are identified using the following schema URI: >> >> 鈥 >> >> Is SCIM Resources 鈥渟hema鈥漴esource? >> >> If they are the same thing, please use consistent terminology. > I鈥檓 not sure of the disconnect here. I have added some text that *might* help. >> >> >> 7. Section 7 also said: >> >> 鈥 >> >> id >> >> The unique URI of the schema. When applicable service providers >> >> MUST specify the URI specified in the core schema specification; >> >> e.g., "urn:ietf:params:scim:schemas:core:2.0:User". Unlike most >> >> other schemas, which use some sort of a GUID for the "id", the >> >> schema "id" is a URI so that it can be registered and is portable >> >> between different service providers and clients. >> >> 鈥 >> >> Does attribute 鈥渋d鈥 has the attribute characteristics described in >> section 2.2? i.e., > I have made some clarifications that set defaults and added REQUIRED and OPTIONAL where missing. > > >> 鈥 >> >> o are OPTIONAL (is not required). >> >> >> >> o are case insensitive ("caseExact" is "false"), >> >> >> >> o are modifiable ("mutability" is "readWrite"), >> >> >> >> o are returned in response to queries (returned by default), >> >> >> >> o have no canonical values (e.g. type is "home" or "work"), >> >> >> >> o are not unique ("uniqueness" is "none"), and, >> >> >> >> o of type string (Section 2.2.1). >> >> 鈥 >> >> 8. Section 8.6 said: >> >> 鈥 >> >> >> >> The following is a non-normative example of the SCIM resource types >> >> in JSON format. >> >> 鈥 >> >> Section 7 said, A SCIM resource type can be 鈥渦ser鈥 or 鈥済roup鈥. I am >> wondering how represented >> >> using JSON format in the example of section 8.6? >> >> Using schema attribute >> >> 鈥 >> >> "schema": "urn:ietf:params:scim:schemas:core:2.0:User" >> >> 鈥 >> >> Or using combination of several attribute, e.g., 鈥渋d鈥,鈥漬ame鈥,etc. > I think you are referring to Section 6. It mentions that name can be for example 鈥淯ser鈥, 鈥淕roup鈥. Nothing here precludes other names. > > A resource type is most often referred by 鈥渘ame鈥. 鈥渋d鈥 was added for consistency reasons and is usually the same value as 鈥渘ame鈥 as stated. > >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > . > From nobody Tue May 19 05:53:24 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D780E1A1F70 for ; Tue, 19 May 2015 05:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vrnoa-STT9e1 for ; Tue, 19 May 2015 05:53:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0768C1A88BF for ; Tue, 19 May 2015 05:53:07 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4JCr61U016367 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 May 2015 12:53:07 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4JCr6nQ030305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 May 2015 12:53:06 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4JCr6OJ011622 for ; Tue, 19 May 2015 12:53:06 GMT Received: from [25.84.207.227] (/24.114.41.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 May 2015 05:53:06 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <63A67C06-C4AC-49AE-BEB4-84DC52F5DE90@oracle.com> Date: Tue, 19 May 2015 05:53:04 -0700 References: <20150519071656.21667.8186.idtracker@ietfa.amsl.com> Cc: "scim@ietf.org" In-Reply-To: <20150519071656.21667.8186.idtracker@ietfa.amsl.com> X-Mailer: iPhone Mail (12F70) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-21.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 12:53:23 -0000 This draft addresses comments from Benoit, Brian, and Stephen.=20 This should complete all outstanding comments at this time.=20 Thanks everyone for your feedback! Phil > On May 19, 2015, at 00:16, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the System for Cross-domain Identity Manageme= nt Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: Core= Schema > Authors : Phil Hunt > Kelly Grizzle > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-21.txt > Pages : 94 > Date : 2015-05-19 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specifications > are designed to make identity management in cloud based applications > and services easier. The specification suite builds upon experience > with existing schemas and deployments, placing specific emphasis on > simplicity of development and integration, while applying existing > authentication, authorization, and privacy models. Its intent is to > reduce the cost and complexity of user management operations by > providing a common user schema and extension model, as well as > binding documents to provide patterns for exchanging this schema > using HTTP protocol. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups and other resource types in JSON > format. This schema is intended for exchange and use with cloud > service providers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-scim-core-schema-21 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-21 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue May 19 07:39:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5901A896F for ; Tue, 19 May 2015 07:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1U-U4oVjWZA for ; Tue, 19 May 2015 07:39:34 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53E91A8963 for ; Tue, 19 May 2015 07:34:47 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so15198469ieb.0 for ; Tue, 19 May 2015 07:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LFHOuPM+iDe0JeW94lSFOh5xtTiE15mqrh3/dL+q0I0=; b=OZ4wnV6VVD4le6l4wPu4NPS/gQlbVhwvLbpZeW6xMWUGHlUCZWd56G5UiazaCNMa9J TcljbNz0N70kupC1vTeQTttazpTI4ldM7oztjLrJG2rXI+ERPT5I4gpGNOHjYorPznFE BId34+Alw0GjmAybdoIr8qaUJW/NgU8o8jRL1ZYiluZ0JT9kkK4TUDItrYDD1FoJSb3c uG+n0gcOCPJ8YzBGbSPn67c9WyjReIJwHA6kGMxxhifPkPpgrOetllV23zH6gmX+ich4 18zyves2iNNfvDWXJPje7MOyOszmXHaMBLyihuFvLKc4Vb2gZSxXu29BxFEVqruTDisq M5Bg== MIME-Version: 1.0 X-Received: by 10.50.66.172 with SMTP id g12mr21834229igt.34.1432046087394; Tue, 19 May 2015 07:34:47 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Tue, 19 May 2015 07:34:47 -0700 (PDT) In-Reply-To: <63A67C06-C4AC-49AE-BEB4-84DC52F5DE90@oracle.com> References: <20150519071656.21667.8186.idtracker@ietfa.amsl.com> <63A67C06-C4AC-49AE-BEB4-84DC52F5DE90@oracle.com> Date: Tue, 19 May 2015 10:34:47 -0400 X-Google-Sender-Auth: N12oOWd_SfHBpu9Pq5asPpx3u94 Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-21.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:39:35 -0000 > This draft addresses comments from Benoit, Brian, and Stephen. > > This should complete all outstanding comments at this time. Perfect; just waiting for the shepherd to confirm that it's ready to go, and then I'll tell the Secretariat to process the approval. Barry From nobody Tue May 19 07:41:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC911B2F05; Tue, 19 May 2015 07:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmLWL5f_CLbK; Tue, 19 May 2015 07:41:07 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BCF1B2F9F; Tue, 19 May 2015 07:36:46 -0700 (PDT) Received: by iepj10 with SMTP id j10so15173130iep.3; Tue, 19 May 2015 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=khI2t/L+kmWd+YA//m28Ayj8yLldnEr70oJuiQOOvQQ=; b=yAvlOXj+yYBiS3Vwa2ETmsyAc1Ij88SiTBUV9j4jFbLY6di+4djgwLGmmOUVA7LcaA na2TFpscr5FgxFuB5k/7pZf6rFKmLzI6isa8XIq3VIGFbhDYBVAtXUPr9tKJmW9nUuvk v9SXL16Lb9MtFfikCwMPFkEd79JS1ZoW4rekKrPBmzw7vCxWQO9sNqqb16ujEZRWSbib rjiFxZbf4Gnhv9vt6QwqphUrXFhbQ8fl86ggE7DEqgAIPVIGLT7s9r5qOmMBK+TBMdki ZL9gGY2kB8tHnRpStXnqd/v5upHGqHSJgZV2EBDCyVvxcPvC4yuiys2p1fNdrBN9LQ/y Sguw== MIME-Version: 1.0 X-Received: by 10.42.81.201 with SMTP id a9mr42164280icl.9.1432046206206; Tue, 19 May 2015 07:36:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Tue, 19 May 2015 07:36:46 -0700 (PDT) In-Reply-To: <59C40E6C-0072-44C8-847E-472B7D3C24E0@oracle.com> References: <20150516060423.16095.77461.idtracker@ietfa.amsl.com> <59C40E6C-0072-44C8-847E-472B7D3C24E0@oracle.com> Date: Tue, 19 May 2015 10:36:46 -0400 X-Google-Sender-Auth: 5WD6a25XpdK8hp-28RNXrD4Sq6s Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "scim@ietf.org" , internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [scim] I-D Action: draft-ietf-scim-api-19.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:41:09 -0000 > This draft includes corrections based on feed back from Ben Campbell > and Stephen Farrell on draft 18. > > For optional features, text describing how a client may discover feature > availability has been added. More reference links have been added as > suggested. > > Statements of fact using =E2=80=9CMAY=E2=80=9D have been corrected to non= -normative > =E2=80=9Cmay=E2=80=9D per 2119. Does that take care of everything now, as far as you know? Is it ready for the shepherd to have a look and let me know if it's ready for approval? Barry From nobody Tue May 19 07:43:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818E01B2FCB for ; Tue, 19 May 2015 07:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NILiVJapEl4k for ; Tue, 19 May 2015 07:43:17 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DCA1B3034 for ; Tue, 19 May 2015 07:39:20 -0700 (PDT) Received: by iesa3 with SMTP id a3so15294896ies.2 for ; Tue, 19 May 2015 07:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=knU6y2NnBmlhVOSSAQy+upuXXfjNXf0FJUzN1oW1RCg=; b=K3Xi2Za3cwonkCkAN+y/maELpqtwiALxZDatI0Vsr5vAH3hnDR/wVimALrK8C5Qr7V xQBWtStYGCNHVLHXM4NjFEpKJm3iYMf0of7sYrEhPlT/VDgejOc7sGwBmiEEa1ayx67w Il9JdUZpDd41EkDNhqccURaeJxRq7Ak+td0lQVR7frIN9YxjF4LMgL627BlX2xwob2FC L/NWa/TpDEXTW69ng30TB0JOffUZ/HXtWo03JiPFRyqyOy/Tg5ky6q4EI2f9/02hYAE+ N92SV7btkmlDAEEBKQtrYl9k7auxnwx8t1rAcj/JkdpPx7JFk9qAeLGtqmfkTk2jCXa6 GKzA== MIME-Version: 1.0 X-Received: by 10.107.131.157 with SMTP id n29mr11894092ioi.74.1432046359533; Tue, 19 May 2015 07:39:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Tue, 19 May 2015 07:39:19 -0700 (PDT) In-Reply-To: <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> Date: Tue, 19 May 2015 10:39:19 -0400 X-Google-Sender-Auth: bMHVMlbi8VP8_uwlCJrVJhm1xxk Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:43:23 -0000 I think it'd be a fine thing to have a true bar BoF, at a real bar, and perhaps to set it up when Stephen and I can join. Barry On Thu, May 14, 2015 at 12:04 PM, Phil Hunt wrote: > Also Stephen raised a couple of good points in his No Objection comments on public keys. This should be part of that discussion. > > Slightly different topic might be an extension regarding information origin and propagation meta data. This was raised by both Kathleen and Stephen during their reviews of SCIM. > > Phil > >> On May 14, 2015, at 08:33, Phil Hunt wrote: >> >> I will be there. >> >> It would be nice to have an informal meeting to 'white-board' ideas on credential mgmt. Kind of a scim credential bof. >> >> There are many account state issues in common and many things that aren't etc. >> >> Basically we need a rough design position (what docs do we need etc) in order to potentially structure passwords and other credential types. >> >> I think a small room would be appropriate. >> >> Phil >> >>>> On May 14, 2015, at 07:58, Leif Johansson wrote: >>>> >>>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>>> We agreed we would meet late in the day and then migrate to a bar where you would buy us beer >>> >>> So who is planning to be in Prague? >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue May 19 07:45:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD351B2F84 for ; Tue, 19 May 2015 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6Fqf8L_r3Ep for ; Tue, 19 May 2015 07:45:07 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDC31B2F83 for ; Tue, 19 May 2015 07:41:57 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so15372188iec.1 for ; Tue, 19 May 2015 07:41: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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SqGGoJOR5vGExBQGyuGwRvXR0vfcG8HfhnpYjTKtL/w=; b=dAQ4acC5IStRcbQZ/PhYwRMR6joDuhWFngqd8wGhX1zalZekAmLzrwH1RvqDF6nFT0 Z/k2Axfxxns1QQH6SCFIjx9ZcNEAHisAPDguRxAsqtPh1jowjaMG3CrduVSvx60dQ3iB 9BxrovD1yY93Ov++HHvOZP8k6PxwuPIqd1VJnucJQfkFb1bSIOlrOW5qAV2KtT6377X9 W+yA38SFRxX0aCFHcUZtD8ufxSjzitth0Z3Br2ubI+axFOLK44ePePf7h0n+G+7azO2L vmJIbIuUm2gXprZ3Mha63L/ib6CSvRlH3M+qf/ZGVh4MOAEH997V2HuoiCY8ysc0N15k 0tXg== MIME-Version: 1.0 X-Received: by 10.42.102.142 with SMTP id i14mr41058503ico.90.1432046517430; Tue, 19 May 2015 07:41:57 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Tue, 19 May 2015 07:41:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2015 10:41:57 -0400 X-Google-Sender-Auth: O4zVM8Ag80Rsz3J4k4H2UbZyXms Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:45:08 -0000 > I believe the latest version of the use cases draft > (draft-ietf-scim-use-cases-08.txt) and Kathleen=C2=B9s acceptance of the > changes to the security/privacy section address all comments received so > far. Sorry: I had some travel and didn't get back to this. Does this mean that version -08 is ready to go, and I should check it and send the approval notice? Barry From nobody Tue May 19 08:52:12 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9448B1A9136 for ; Tue, 19 May 2015 08:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CJufzTenrk3 for ; Tue, 19 May 2015 08:52:07 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6FA1AC3A0 for ; Tue, 19 May 2015 08:51:31 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 19 May 2015 17:51:27 +0200 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Tue, 19 May 2015 17:51:29 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= To: Phil Hunt Thread-Topic: [scim] Prague? Thread-Index: AQHQjlU0MNC6Twvxd0eSi5tjXUJeMZ17bf8AgAAAyYCAAAm6AIAH4KCA Date: Tue, 19 May 2015 15:51:28 +0000 Message-ID: <6A5A43C8-0BCC-4573-BE6C-3CCB65B54B39@nexusgroup.com> References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> In-Reply-To: <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.75.112.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <648900A3F0D1E34A9B3B423793F65842@nexusgroup.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Leif Johansson , "scim@ietf.org" , Anthony Nadalin Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:52:09 -0000 I will also be in Prague. Interested in the credential beer-bof. Especially= if someone is buying :) > On 14 May 2015, at 17:33, Phil Hunt wrote: >=20 > I will be there.=20 >=20 > It would be nice to have an informal meeting to 'white-board' ideas on cr= edential mgmt. Kind of a scim credential bof.=20 >=20 > There are many account state issues in common and many things that aren't= etc.=20 >=20 > Basically we need a rough design position (what docs do we need etc) in o= rder to potentially structure passwords and other credential types.=20 >=20 > I think a small room would be appropriate.=20 >=20 > Phil >=20 >> On May 14, 2015, at 07:58, Leif Johansson wrote: >>=20 >>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>> We agreed we would meet late in the day and then migrate to a bar where= you would buy us beer >>=20 >> So who is planning to be in Prague? >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue May 19 09:53:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708961AC41A for ; Tue, 19 May 2015 09:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8kK3k0hI6bw for ; Tue, 19 May 2015 09:53:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3DB1AC3B5 for ; Tue, 19 May 2015 09:53:20 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (10.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 19 May 2015 16:53:18 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0166.017; Tue, 19 May 2015 16:53:18 +0000 From: Anthony Nadalin To: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= , Phil Hunt Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUxWwUOLcN7Zk62zK2tbTzRgZ17jzrAgAABFYCAAAm6AIAH4KIAgAARKMA= Date: Tue, 19 May 2015 16:53:16 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <6A5A43C8-0BCC-4573-BE6C-3CCB65B54B39@nexusgroup.com> In-Reply-To: <6A5A43C8-0BCC-4573-BE6C-3CCB65B54B39@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 3:uMSpiEDIVSwWfH2T8FjgIlRLUjqcwFIrDHoGEAmr4/eWWhCwxM3dtBWgna6lJywmXBdBXkeuC0ocbhRYn9OJIZpsKViZPa2iu6a1W/YOqwlszlBpZ41c5pJdSfmNa1nm/RtRce+K/gnurcjqxnnxyg==; 10:7h0OGj8Eofx/HNJtQIdB5GVzoXUlNFbgT7GK+GWa/iSbfYhrMmawak8D/od5OAw5Ih1/EYOqrmSshH8sX/632VlZ3nd0s5ARL1pZpovlYdE=; 6:C26bL74dqAqAKWqOUyRZ8wSif48Vp0xB7pbns0Y0hTZ9bVe6cSmpLE/riT5HayKP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(479174004)(24454002)(189002)(13464003)(377454003)(51704005)(199003)(122556002)(33656002)(86362001)(76576001)(5001960100002)(5001830100001)(5001860100001)(106356001)(87936001)(86612001)(106116001)(2656002)(189998001)(5001770100001)(40100003)(19580405001)(105586002)(19580395003)(102836002)(15975445007)(99286002)(92566002)(68736005)(77096005)(2900100001)(2950100001)(46102003)(101416001)(64706001)(74316001)(97736004)(76176999)(54356999)(4001540100001)(50986999)(62966003)(77156002)(81156007)(93886004)(551544002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 16:53:16.9753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:53:22 -0000 Morteza will buy the beers=20 -----Original Message----- From: Erik Wahlstr=F6m neXus [mailto:erik.wahlstrom@nexusgroup.com]=20 Sent: Tuesday, May 19, 2015 8:51 AM To: Phil Hunt Cc: Leif Johansson; Anthony Nadalin; scim@ietf.org Subject: Re: [scim] Prague? I will also be in Prague. Interested in the credential beer-bof. Especially= if someone is buying :) > On 14 May 2015, at 17:33, Phil Hunt wrote: >=20 > I will be there.=20 >=20 > It would be nice to have an informal meeting to 'white-board' ideas on cr= edential mgmt. Kind of a scim credential bof.=20 >=20 > There are many account state issues in common and many things that aren't= etc.=20 >=20 > Basically we need a rough design position (what docs do we need etc) in o= rder to potentially structure passwords and other credential types.=20 >=20 > I think a small room would be appropriate.=20 >=20 > Phil >=20 >> On May 14, 2015, at 07:58, Leif Johansson wrote: >>=20 >>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>> We agreed we would meet late in the day and then migrate to a bar where= you would buy us beer >>=20 >> So who is planning to be in Prague? >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue May 19 12:03:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292411ACF03 for ; Tue, 19 May 2015 12:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpJYtEwYXE4d for ; Tue, 19 May 2015 12:03:53 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5484C1ACC82 for ; Tue, 19 May 2015 12:03:01 -0700 (PDT) Received: by laat2 with SMTP id t2so39222198laa.1 for ; Tue, 19 May 2015 12:02:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xL2ygqy98hTtcR/VOuZh9JeGed/KwKeC3QkhOYgWHIM=; b=HumPEkpnVHNVOw8sb35WLnoYzcPW9qy9FeC78/ybWLiT5YIi2gw10iNjaD9SJQl8TV TDquh33SeRVKYZR/robDz6pPTDv6qLyNS0U3/1Y9kSKMxDimRVSqHtYQP7O1AXCeGQpA 7JR+lYxcPJzfSXe1RWWDLnFyPg6mHi69xWKGZOyjMB+rDSGZEPTT4FTX19QshtOMacAU i98jqH/cQQJ4FBWey8FNHpc1PnZSRs3bOR0gaEdBOtAjuXOKO2IwcJ4TUELJqqq3TaX6 59A6OnkTfk5hL7bu8DtS2Nqu6lL28dyyZQo37klgc1QvUVjJvXxAzYN+wEOYnOtw+PVm yHFA== X-Gm-Message-State: ALoCoQm68F7Ll04bx1f0IjD7so5dFS1bl3sbIoof7+vy7RoFWyVJ4IM1m1IflKYec4hjIWv6ZutV X-Received: by 10.152.36.65 with SMTP id o1mr18277985laj.55.1432062179876; Tue, 19 May 2015 12:02:59 -0700 (PDT) Received: from [10.0.0.107] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ky7sm3918494lab.37.2015.05.19.12.02.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 12:02:58 -0700 (PDT) Message-ID: <555B88E1.1020905@mnt.se> Date: Tue, 19 May 2015 21:02:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anthony Nadalin , =?windows-1252?Q?Erik_Wahl?= =?windows-1252?Q?str=F6m_neXus?= , Phil Hunt References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <6A5A43C8-0BCC-4573-BE6C-3CCB65B54B39@nexusgroup.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:03:55 -0000 On 05/19/2015 06:53 PM, Anthony Nadalin wrote: > Morteza will buy the beers So we meet informally! From nobody Tue May 19 18:39:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A541E1B2AE7 for ; Tue, 19 May 2015 18:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoWunHFQs0eN for ; Tue, 19 May 2015 18:39:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834201B2ADD for ; Tue, 19 May 2015 18:39:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B22DBEDF; Wed, 20 May 2015 02:39:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbc9O2kEQW3I; Wed, 20 May 2015 02:39:23 +0100 (IST) Received: from [192.168.50.253] (unknown [119.145.14.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8FEBBEA1; Wed, 20 May 2015 02:39:19 +0100 (IST) Message-ID: <555BE5C0.2020005@cs.tcd.ie> Date: Wed, 20 May 2015 02:39:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Barry Leiba , Phil Hunt References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 01:39:32 -0000 On 19/05/15 15:39, Barry Leiba wrote: > I think it'd be a fine thing to have a true bar BoF, at a real bar, > and perhaps to set it up when Stephen and I can join. Bar==good. Picking a night early == better. I tend to have stuff Wed night, so Mon/Thu are usually better to go for, S > > Barry > > On Thu, May 14, 2015 at 12:04 PM, Phil Hunt wrote: >> Also Stephen raised a couple of good points in his No Objection comments on public keys. This should be part of that discussion. >> >> Slightly different topic might be an extension regarding information origin and propagation meta data. This was raised by both Kathleen and Stephen during their reviews of SCIM. >> >> Phil >> >>> On May 14, 2015, at 08:33, Phil Hunt wrote: >>> >>> I will be there. >>> >>> It would be nice to have an informal meeting to 'white-board' ideas on credential mgmt. Kind of a scim credential bof. >>> >>> There are many account state issues in common and many things that aren't etc. >>> >>> Basically we need a rough design position (what docs do we need etc) in order to potentially structure passwords and other credential types. >>> >>> I think a small room would be appropriate. >>> >>> Phil >>> >>>>> On May 14, 2015, at 07:58, Leif Johansson wrote: >>>>> >>>>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>>>> We agreed we would meet late in the day and then migrate to a bar where you would buy us beer >>>> So who is planning to be in Prague? >>>> >>>> _______________________________________________ >>>> 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 From nobody Tue May 19 22:03:59 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF91A00DC for ; Tue, 19 May 2015 22:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOIjrMsmxzmq for ; Tue, 19 May 2015 22:03:56 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 309FC1B3579 for ; Tue, 19 May 2015 22:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1432098235; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=M8JMmKNMKNHkXkNEJSWoPxLJ2zs6deS4FLPcmCQ1itU=; b=BH9LCzT06LMAdGnJnbFqhw3yGW9ogKN+C9LrMn+bDE/QkcCcy37lCUeUfSdGkBl6dqzSa/f1MyVhzvRxULymDtuJemq7S8WmHQNjMlGLonTLlez12k57hD8pkqMEKTSLkXhn/i/ty8aWX4n4TYSIdcBihIpsxbyve+LmSfs/Fc8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02006; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.1.151.150(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.187) by smtp.aliyun-inc.com(127.0.0.1); Wed, 20 May 2015 13:03:50 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 20 May 2015 13:03:46 +0800 From: "Kepeng Li" To: Barry Leiba , "Morteza Ansari (moransar)" Message-ID: Thread-Topic: [scim] Status of use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 05:03:58 -0000 > Does this mean that version -08 is ready to go >From authors=E2=80=99 point of view, yes, we have addressed all the comments received during the IESG review and got their confirmation. Thanks, Kind Regards Kepeng =E5=9C=A8 19/5/15 10:41 pm=EF=BC=8C "Barry Leiba" =E5=86=99=E5=85=A5: >> I believe the latest version of the use cases draft >> (draft-ietf-scim-use-cases-08.txt) and Kathleen=C2=B9s acceptance of the >> changes to the security/privacy section address all comments received so >> far. > >Sorry: I had some travel and didn't get back to this. >Does this mean that version -08 is ready to go, and I should check it >and send the approval notice? > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 20 09:30:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB99B1A87BF for ; Wed, 20 May 2015 09:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSam96Of0fZz for ; Wed, 20 May 2015 09:30:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE931A8797 for ; Wed, 20 May 2015 09:30:45 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 20 May 2015 16:30:44 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0166.017; Wed, 20 May 2015 16:30:44 +0000 From: Anthony Nadalin To: Stephen Farrell , Barry Leiba , Phil Hunt Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUxWwUOLcN7Zk62zK2tbTzRgZ17jzrAgAABFYCAAAm6AIAACLyAgAfDvYCAALhfAIAA+Jyw Date: Wed, 20 May 2015 16:30:43 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> In-Reply-To: <555BE5C0.2020005@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.192.114] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 3:vKbvn0kktixlkKwN78CjMx1y6Wsl3kLtMAV5XxT8UsVMtIhLSf53kZ5c5F2Orb95JxWiiA2oKQz5giwezLwiOuGlWZU1qbGSKrpD7kMrTlL6xVJpVppaLZBhdr3VLAk0gxDu76JR6Uxzgno9PkNO/g==; 10:aV3YSHCID9ssPbLkiIsw+YLy+P2VjWpjK8IokdtzOmd65gNOFXzLDmpEdTWREKG2G5p5IfnDrXrmmsZCPh6RLq2nrS4r7tDkHr62TUJYOcw=; 6:W1PhemWBS5uFBwiq+dcIUHZ+hRQ194QwmN071JQY+8cnywuzRlRnAZdz5a3l0v70 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(479174004)(57704003)(51704005)(377454003)(13464003)(2656002)(189998001)(86612001)(87936001)(102836002)(77096005)(5001830100001)(5001860100001)(5001960100002)(5001770100001)(68736005)(64706001)(99286002)(93886004)(66066001)(86362001)(122556002)(551544002)(40100003)(76176999)(46102003)(50986999)(54356999)(92566002)(19580395003)(105586002)(19580405001)(62966003)(77156002)(106116001)(2950100001)(2900100001)(101416001)(97736004)(106356001)(81156007)(74316001)(15975445007)(33656002)(4001540100001)(76576001)(350894002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 16:30:43.8693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: Leif Johansson , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:30:47 -0000 You know this is real pills and larger country none of that wimpy Guinness= =20 -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Tuesday, May 19, 2015 6:39 PM To: Barry Leiba; Phil Hunt Cc: Leif Johansson; scim@ietf.org Subject: Re: [scim] Prague? On 19/05/15 15:39, Barry Leiba wrote: > I think it'd be a fine thing to have a true bar BoF, at a real bar,=20 > and perhaps to set it up when Stephen and I can join. Bar=3D=3Dgood. Picking a night early =3D=3D better. I tend to have stuff We= d night, so Mon/Thu are usually better to go for, S > > Barry > > On Thu, May 14, 2015 at 12:04 PM, Phil Hunt wrote: >> Also Stephen raised a couple of good points in his No Objection comments= on public keys. This should be part of that discussion. >> >> Slightly different topic might be an extension regarding information ori= gin and propagation meta data. This was raised by both Kathleen and Stephen= during their reviews of SCIM. >> >> Phil >> >>> On May 14, 2015, at 08:33, Phil Hunt wrote: >>> >>> I will be there. >>> >>> It would be nice to have an informal meeting to 'white-board' ideas on = credential mgmt. Kind of a scim credential bof. >>> >>> There are many account state issues in common and many things that aren= 't etc. >>> >>> Basically we need a rough design position (what docs do we need etc) in= order to potentially structure passwords and other credential types. >>> >>> I think a small room would be appropriate. >>> >>> Phil >>> >>>>> On May 14, 2015, at 07:58, Leif Johansson wrote: >>>>> >>>>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>>>> We agreed we would meet late in the day and then migrate to a bar=20 >>>>> where you would buy us beer >>>> So who is planning to be in Prague? >>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 20 09:34:44 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EA91A88C7 for ; Wed, 20 May 2015 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po6IJeDhL-Xx for ; Wed, 20 May 2015 09:34:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7531A88F6 for ; Wed, 20 May 2015 09:34:40 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4KGYXDr002646 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 May 2015 16:34:34 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4KGYXW2029749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2015 16:34:33 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4KGYXbj032115; Wed, 20 May 2015 16:34:33 GMT Received: from [25.26.214.213] (/24.114.78.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 May 2015 09:34:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 20 May 2015 09:34:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> To: Anthony Nadalin X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Leif Johansson , Barry Leiba , "scim@ietf.org" , Stephen Farrell Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:34:43 -0000 We'll just have to do some early practice.=20 Phil > On May 20, 2015, at 09:30, Anthony Nadalin wrote: >=20 > You know this is real pills and larger country none of that wimpy Guinnes= s=20 >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Tuesday, May 19, 2015 6:39 PM > To: Barry Leiba; Phil Hunt > Cc: Leif Johansson; scim@ietf.org > Subject: Re: [scim] Prague? >=20 >=20 >=20 >> On 19/05/15 15:39, Barry Leiba wrote: >> I think it'd be a fine thing to have a true bar BoF, at a real bar,=20 >> and perhaps to set it up when Stephen and I can join. >=20 > Bar=3D=3Dgood. Picking a night early =3D=3D better. I tend to have stuff W= ed night, so Mon/Thu are usually better to go for, >=20 > S >>=20 >> Barry >>=20 >>> On Thu, May 14, 2015 at 12:04 PM, Phil Hunt wrote= : >>> Also Stephen raised a couple of good points in his No Objection comments= on public keys. This should be part of that discussion. >>>=20 >>> Slightly different topic might be an extension regarding information ori= gin and propagation meta data. This was raised by both Kathleen and Stephen d= uring their reviews of SCIM. >>>=20 >>> Phil >>>=20 >>>> On May 14, 2015, at 08:33, Phil Hunt wrote: >>>>=20 >>>> I will be there. >>>>=20 >>>> It would be nice to have an informal meeting to 'white-board' ideas on c= redential mgmt. Kind of a scim credential bof. >>>>=20 >>>> There are many account state issues in common and many things that aren= 't etc. >>>>=20 >>>> Basically we need a rough design position (what docs do we need etc) in= order to potentially structure passwords and other credential types. >>>>=20 >>>> I think a small room would be appropriate. >>>>=20 >>>> Phil >>>>=20 >>>>>> On May 14, 2015, at 07:58, Leif Johansson wrote: >>>>>>=20 >>>>>> On 05/14/2015 04:56 PM, Anthony Nadalin wrote: >>>>>> We agreed we would meet late in the day and then migrate to a bar=20 >>>>>> where you would buy us beer >>>>> So who is planning to be in Prague? >>>>>=20 >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 20 11:50:33 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB511A1AA3 for ; Wed, 20 May 2015 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qksm1MXQ1Rmb for ; Wed, 20 May 2015 11:50:30 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D9B1A8A83 for ; Wed, 20 May 2015 11:50:30 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so46459545iec.1 for ; Wed, 20 May 2015 11:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s8teHbLowLlrJ5R+0/+zzQjpZh8eNZsgvHcp93q6DnM=; b=LHMT2Uk4b+pwxFqINnf1zuMLDvROabZR5cDAiTWdJnU14gty+4vU2plVrRj+YFLQ5D mZP/colGfFUAOiLrLthFO1njL4PaZph4B5Q3L4kxe38CIgSCqtJS2B47LNBVa/U24Ebc HpWr8u61Y5W3Bx7UuKDFg6OI3qhdcXxICCUWvVYNvnub1WEX9pHrznB3wIufDM1zTdXE q7kQaubF8KLqaQv+0PRWa4XUfQUfPCvkWVS95agt4kTcPuY0z4fYHRZxxwaA3DLNss0A GSSwhRZuFHhWfqZ+50ehp5dcfT8k4CgWdI/TEk544ZffZXLCVA4nZ9Tbl03CCWxKS0uG tyyA== MIME-Version: 1.0 X-Received: by 10.107.138.31 with SMTP id m31mr35876770iod.75.1432147830097; Wed, 20 May 2015 11:50:30 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Wed, 20 May 2015 11:50:30 -0700 (PDT) In-Reply-To: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> Date: Wed, 20 May 2015 14:50:30 -0400 X-Google-Sender-Auth: w2IO7bwXCcMv6EH3k0wGHggg3pI Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Anthony Nadalin , Leif Johansson , "scim@ietf.org" , Stephen Farrell Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:50:31 -0000 >> You know this is real pils-and-lager country; none of that wimpy Guinness. [I took the liberty of editing that a bit, after figuring out how it was meant to be parsed. :-) ] > We'll just have to do some early practice. Well, indeed. For my part, I note that there are now craft-beer pubs in London, which actually have some US and US-style craft beers, with real flavour and real alcohol content. I wonder if there's any similar movement in Praha. Off to do a web search on << "craft beer" prague >>... Barry From nobody Wed May 20 11:54:12 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94961A8A65 for ; Wed, 20 May 2015 11:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6w0MM5zls9T for ; Wed, 20 May 2015 11:54:01 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828791A8A60 for ; Wed, 20 May 2015 11:54:01 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so110508467igb.0 for ; Wed, 20 May 2015 11:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vsrtJqziM2L3gCSAMPqEiGj2zq+KnjlJ2YXWCyLEBzA=; b=UH5GjsLeFfpNUMQAGzjKOnaete3nEBPpcF62mI4nSF7uwlZrvTmGJMOm/Ukkpdm+xe 8JY2xMSnHaFjrObTjlwVJ3KDAQD0LlmN/1Pekjdv9knAoAw0acDW+sJcKf0hQdMtnrTX e61+BoC/ILRdiI4WBNcWqwOZXo8Al6UzlDJkmu3pY5T5SMl6VIDog+WgxiqEB8UdmNYG ARVVdOF4LkYKGH9UYKD0IMnPyM8JFLe3jq1jlx/s519SJzkly7D/o47eIM7eN/+lXuNc 8VTANmsRvTolMEod2TlbpHwdouPWOpYz5JpCtuUq79V9rfKrZ6tIxshw/aotradKjuYx 0IAg== MIME-Version: 1.0 X-Received: by 10.43.34.205 with SMTP id st13mr30662809icb.4.1432148040994; Wed, 20 May 2015 11:54:00 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Wed, 20 May 2015 11:54:00 -0700 (PDT) In-Reply-To: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> Date: Wed, 20 May 2015 14:54:00 -0400 X-Google-Sender-Auth: 1ZCSNHky0BAZov5ZvlX_UwJDfc0 Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Anthony Nadalin , Leif Johansson , "scim@ietf.org" , Stephen Farrell Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:54:02 -0000 > Off to do a web search on << "craft beer" prague >>... Well, I don't know about US-style craft beer, but there are these to think about: http://www.praguebeermuseum.com/en http://www.tasteofprague.com/pragueblog/our-favorite-places-in-prague-for-czech-craft-beers http://www.beeradvocate.com/place/city/63/ Pivo rulz! b From nobody Wed May 20 12:40:11 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378211A9004 for ; Wed, 20 May 2015 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew8AfUjg6QZ7 for ; Wed, 20 May 2015 12:40:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114CC1A8FD6 for ; Wed, 20 May 2015 12:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=786; q=dns/txt; s=iport; t=1432150808; x=1433360408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L3SLqG2UEZK/PP3AZ0xPgdrGZj/02ICJGLYhvKyepRI=; b=IUOk8oxB4u2IyYGFUbYD6PZdnsXeZdp6DzuOyx3a3a10wd0o7yH31uac ST0mu2gZS5GQlkWmqt673XI7UqMLG+CZ9cRNC012f17j2bTJPdPLgOW5Q 4TKWNi4QCKwP8czOTIwETXzSCf4CwnZlFizhhxAOeYR9wAzWEgLSjb1Ma s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBQCo4lxV/4UNJK1cgxCBMgaDGL9ab4dRAhyBIToSAQEBAQEBAYEKhCMBAQMBNEUQAgEIHCgCAjAlAgQOBYgkCI19nQgGpBkBAQEBAQEBAQEBAQEBAQEBAQEBGYEbih+EUjMHgmKBSwEEknCIdIIMgTqVWiODeG+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427760000"; d="scan'208";a="536285" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 20 May 2015 19:40:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4KJe7hJ005815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 19:40:07 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 20 May 2015 14:40:06 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba Thread-Topic: [scim] Status of use-cases Thread-Index: AQHQg/sxx9NXYU06Kku3ndwvglzgmJ1woxOAgBMssYCAAXBIgA== Date: Wed, 20 May 2015 19:40:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.39] Content-Type: text/plain; charset="euc-kr" Content-ID: <16CF333C82157449813F6EAC24253CEE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:40:09 -0000 WWVzLCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgb3V0c3RhbmRpbmcgaXNzdWVzIG9yIGNvbW1lbnRz IHRoYXQgd2VyZSBub3QNCmFkZHJlc3NlZC4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQoNCk9uIDUv MTkvMTUsIDc6NDEgQU0sICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3 cm90ZToNCg0KPj4gSSBiZWxpZXZlIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgdXNlIGNhc2Vz IGRyYWZ0DQo+PiAoZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0wOC50eHQpIGFuZCBLYXRobGVl bqn2cyBhY2NlcHRhbmNlIG9mIHRoZQ0KPj4gY2hhbmdlcyB0byB0aGUgc2VjdXJpdHkvcHJpdmFj eSBzZWN0aW9uIGFkZHJlc3MgYWxsIGNvbW1lbnRzIHJlY2VpdmVkIHNvDQo+PiBmYXIuDQo+DQo+ U29ycnk6IEkgaGFkIHNvbWUgdHJhdmVsIGFuZCBkaWRuJ3QgZ2V0IGJhY2sgdG8gdGhpcy4NCj5E b2VzIHRoaXMgbWVhbiB0aGF0IHZlcnNpb24gLTA4IGlzIHJlYWR5IHRvIGdvLCBhbmQgSSBzaG91 bGQgY2hlY2sgaXQNCj5hbmQgc2VuZCB0aGUgYXBwcm92YWwgbm90aWNlPw0KPg0KPkJhcnJ5DQoN Cg== From nobody Wed May 20 12:48:29 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C21A1A903E for ; Wed, 20 May 2015 12:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcONhwBkYqgZ for ; Wed, 20 May 2015 12:48:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD161A903D for ; Wed, 20 May 2015 12:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1432151308; x=1433360908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jihHW+dFgVBD96G+XM38RHCDPyc+0DOjKcn401s/WHE=; b=ViTk4HzbF7Q0H2L60z0wXC0VVBHQhDJlBs1RHVm6Pp4CsKl+MgL0OF1l N35z4qszWDoIwveUrBsJD0zKU1gBWhwCo/n76iKFf2xB2mxKBiEnbEpCB LVUb/TsaWSxwrM3WaYo1yKKNgw2j2bes38x/7mE9x5bZVh4o1+ptnORev w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyBQC95FxV/5tdJa1cgxBUXgbCcoI/DIV1AoE9TAEBAQEBAYELhCMBAQQBAQFrCxACAQhGJwslAgQBDQWILA3PGgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoRSMweELQEEi3mGd4sAlxQjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427760000"; d="scan'208";a="421416390" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 20 May 2015 19:48:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4KJmQX3007772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 19:48:26 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 20 May 2015 14:48:25 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba , Phil Hunt Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUyZJbS4LHsyECZWcHakI804J1741cAgAAAyoCAAAm6AIAACLuAgAfDvoCAALheAIAA+ReAgAABDYCAACYBAIAAAPoA//+Z2gA= Date: Wed, 20 May 2015 19:48:24 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2941DEA793F4C3489FFD1FA992A9EB02@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , Stephen Farrell , "scim@ietf.org" , Leif Johansson Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:48:28 -0000 I don=B9t think you can get bad beer anywhere in Prague! Beer museum has a= n amazing selection of beers on tap, though could be loud if we don=B9t find = a good table. Given Stephen=B9s availability, how about we shoot for Monday night? Cheers, Morteza On 5/20/15, 11:54 AM, "Barry Leiba" wrote: >> Off to do a web search on << "craft beer" prague >>... > >Well, I don't know about US-style craft beer, but there are these to >think about: > >http://www.praguebeermuseum.com/en > >http://www.tasteofprague.com/pragueblog/our-favorite-places-in-prague-for- >czech-craft-beers > >http://www.beeradvocate.com/place/city/63/ > >Pivo rulz! > >b > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 20 15:41:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4B1AC3A0 for ; Wed, 20 May 2015 15:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCeMBQF6CIFb for ; Wed, 20 May 2015 15:41:54 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FC81A90DF for ; Wed, 20 May 2015 15:41:54 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so114866411igb.1 for ; Wed, 20 May 2015 15:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6Hgbq8rf1jyhKAc5n70NAxBBvqle2W7LUbGkvMmIJHg=; b=HopX6yARIcuC+/KBOGo+GDXYUX3NSykiHahTqdF4xIpEUA/GRIi69PCxcz5UES8XOD mtPywhZh/hjZ1Kqx7Ycdg49zsHuCY6RYEFZr3qKZVKKKyJT9eJ/RTnC7aWnKqiYIMhD+ xgXBfPqZogH4wc0TxH39o3NHzUEHMww6qY5vKmyjGkwbL4WmjgJHun2uk84Ih9Ed3toQ ObG5JnB6DZafI4ZOhWQxJESVngsA8jeYlODgSu56IKOX0eaalN0dFht6MJRoIy2XqA8o AznhDo3DBfPSfeNYfZGbCK8FUM7RSA4tPZui7yuwKAk9c9yVcOY8T8qr9tybmvPKeAOk Hwpg== MIME-Version: 1.0 X-Received: by 10.107.3.79 with SMTP id 76mr15639421iod.60.1432161713938; Wed, 20 May 2015 15:41:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Wed, 20 May 2015 15:41:53 -0700 (PDT) In-Reply-To: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> Date: Wed, 20 May 2015 18:41:53 -0400 X-Google-Sender-Auth: oWUNpljRPCDUfJdwOW7U5CJdWvM Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Anthony Nadalin , Stephen Farrell , Leif Johansson , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:41:55 -0000 > I don=C2=B9t think you can get bad beer anywhere in Prague! Beer museum = has an > amazing selection of beers on tap, though could be loud if we don=C2=B9t = find a > good table. Given Stephen=C2=B9s availability, how about we shoot for Mon= day > night? Monday night works for me, as long as we book it now, before things fill up. So it's booked for SCIM. b From nobody Wed May 20 15:43:42 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0074A1AC3B5 for ; Wed, 20 May 2015 15:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drSkwPTwV0ag for ; Wed, 20 May 2015 15:43:40 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FFD1AC3A0 for ; Wed, 20 May 2015 15:43:40 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so114892039igb.1 for ; Wed, 20 May 2015 15:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yC+iOe+648hpfhhy4w3U36LAuB+Q9jB580I6l6arquk=; b=B/akatTNLHMxMye5Qq2UZVVEEOpJnC0NV3wvt8qPLjpJbX7LFtbAKY9E4TMhePdZ8Y F4RVS1Q58b7FLPgoM+/6N45fZ7h+Hco61DPrfKPK3dXNURMKiuqVSDyXWLIEZRtYVp21 zN3K2kTWmJ5aJZl1sLGEMDXDpczhLnHk2Ov0CZhmXk47wr3rh654Z7sb306h/cf1bfO9 iGY0XUnIR53Gxx13qfkzQhtOrKdCQpxEpPzd056A1ZlNd3hBBOCbrPo+tIkaKSuvMh1g Gm/5H1ST1Kvstp3HtjiHdCY3P8/cGXshXxtL8cOpREOB0Kx1UmwjJScr2NfNFWUyo+z2 t48Q== MIME-Version: 1.0 X-Received: by 10.50.30.105 with SMTP id r9mr31448276igh.11.1432161819750; Wed, 20 May 2015 15:43:39 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Wed, 20 May 2015 15:43:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2015 18:43:39 -0400 X-Google-Sender-Auth: CYCSchuwV-me6ymIdaCcWq6-xtQ Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Status of use-cases X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:43:41 -0000 > Yes, I am not aware of any outstanding issues or comments that were not > addressed. OK, then here it goes... Barry From nobody Wed May 20 15:51:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305AB1AC3B7 for ; Wed, 20 May 2015 15:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqIFe6sJJODn for ; Wed, 20 May 2015 15:51:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABF41A8A0E for ; Wed, 20 May 2015 15:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=932; q=dns/txt; s=iport; t=1432162260; x=1433371860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kns8k4xk+pjrtgFJLfKCrRHcOskpBe0392s789/fGDQ=; b=AiQnWJ4OkBP1FKKujBcyIxaNLlZS2Mdcg6Lq+VpK2yZtZIla1tEYGibI 0opTK/h5Jas4p50MDY6L5hB1q2f0Q138WP/QuDLbRQAteKI15N4CKvlrs HlwfPckoPtTpa/gayGjvq3eIE38aSlW6rkDQVKCvsI+31y2fm5MoxZwqg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQAHD11V/5JdJa1cgxCBMgaDGL9aiEACHIEeTAEBAQEBAYELhCMBAQMBNEUQAgEIHCgCAjAlAgQOBYgkCI4WnQgGpAYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgRuKH4UFB4JigUsBBJJwiwCBJ4NrkgIjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,466,1427760000"; d="scan'208";a="421401892" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 20 May 2015 22:50:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4KMowQe027643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 22:50:58 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 20 May 2015 17:50:58 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUyZJbS4LHsyECZWcHakI804J1741cAgAAAyoCAAAm6AIAACLuAgAfDvoCAALheAIAA+ReAgAABDYCAACYBAIAAAPoA//+Z2gCAAKXSgP//jS+A Date: Wed, 20 May 2015 22:50:57 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.39] Content-Type: text/plain; charset="euc-kr" Content-ID: <7DC87C945E436B49A2FC5B017045902D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , Stephen Farrell , Leif Johansson , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:51:01 -0000 TW9uZGF5IGdvaW5nIG9uY2UsIHR3aWNlLCChpiAgUGxlYXNlIHNwZWFrIHVwIGlmIE1vbmRheSBk b2VzIG5vdCB3b3JrIGZvcg0KeW91Lg0KDQpJbiB0aGUgbWVhbnRpbWUgQmFycnkgJiBTdGVwaGVu IHBsZWFzZSBwZW5jaWwgaW4gTW9uZGF5IG5pZ2h0IGJlZm9yZSBpdA0KZ2V0cyBib29rZWQuICBX ZSB3aWxsIGRvIGEgZmluYWwgY29uZmlybWF0aW9uIHRvbW9ycm93Lg0KDQoNCkNoZWVycywNCk1v cnRlemENCg0KT24gNS8yMC8xNSwgMzo0MSBQTSwgIkJhcnJ5IExlaWJhIiA8YmFycnlsZWliYUBj b21wdXRlci5vcmc+IHdyb3RlOg0KDQo+PiBJIGRvbqn2dCB0aGluayB5b3UgY2FuIGdldCBiYWQg YmVlciBhbnl3aGVyZSBpbiBQcmFndWUhICBCZWVyIG11c2V1bSBoYXMNCj4+YW4NCj4+IGFtYXpp bmcgc2VsZWN0aW9uIG9mIGJlZXJzIG9uIHRhcCwgdGhvdWdoIGNvdWxkIGJlIGxvdWQgaWYgd2Ug ZG9uqfZ0DQo+PmZpbmQgYQ0KPj4gZ29vZCB0YWJsZS4gR2l2ZW4gU3RlcGhlbqn2cyBhdmFpbGFi aWxpdHksIGhvdyBhYm91dCB3ZSBzaG9vdCBmb3IgTW9uZGF5DQo+PiBuaWdodD8NCj4NCj5Nb25k YXkgbmlnaHQgd29ya3MgZm9yIG1lLCBhcyBsb25nIGFzIHdlIGJvb2sgaXQgbm93LCBiZWZvcmUg dGhpbmdzDQo+ZmlsbCB1cC4gIFNvIGl0J3MgYm9va2VkIGZvciBTQ0lNLg0KPg0KPmINCg0K From nobody Wed May 20 15:52:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5AA1A8A0E for ; Wed, 20 May 2015 15:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp-YkwAM5T2g for ; Wed, 20 May 2015 15:52:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E1A1A88FA for ; Wed, 20 May 2015 15:52:07 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4KMpxlh011200 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 May 2015 22:51:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4KMpxDi000932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2015 22:51:59 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4KMpxlp002273; Wed, 20 May 2015 22:51:59 GMT Received: from [10.151.104.176] (/148.87.13.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 May 2015 15:51:59 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Wed, 20 May 2015 15:51:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D10FC5A-F5E4-4EA1-8F8A-B04AD348E68C@oracle.com> References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> To: Morteza Ansari X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Stephen Farrell , Anthony Nadalin , Barry Leiba , "scim@ietf.org" , Leif Johansson Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:52:08 -0000 Monday works for me. I arrive Sunday morning. Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 20, 2015, at 3:50 PM, Morteza Ansari (moransar) = wrote: >=20 > Monday going once, twice, =C2=A1=C2=A6 Please speak up if Monday does = not work for > you. >=20 > In the meantime Barry & Stephen please pencil in Monday night before = it > gets booked. We will do a final confirmation tomorrow. >=20 >=20 > Cheers, > Morteza >=20 > On 5/20/15, 3:41 PM, "Barry Leiba" wrote: >=20 >>> I don=C2=A9=C3=B6t think you can get bad beer anywhere in Prague! = Beer museum has >>> an >>> amazing selection of beers on tap, though could be loud if we = don=C2=A9=C3=B6t >>> find a >>> good table. Given Stephen=C2=A9=C3=B6s availability, how about we = shoot for Monday >>> night? >>=20 >> Monday night works for me, as long as we book it now, before things >> fill up. So it's booked for SCIM. >>=20 >> b >=20 From nobody Wed May 20 17:18:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841D11ACD46; Wed, 20 May 2015 17:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VczSNzz_wX3G; Wed, 20 May 2015 17:18:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE941ACD8C; Wed, 20 May 2015 17:18:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150521001831.21131.40980.idtracker@ietfa.amsl.com> Date: Wed, 20 May 2015 17:18:31 -0700 Archived-At: Cc: scim mailing list , scim chair , RFC Editor Subject: [scim] Document Action: 'SCIM Definitions, Overview, Concepts and Requirements' to Informational RFC (draft-ietf-scim-use-cases-08.txt) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 00:18:34 -0000 The IESG has approved the following document: - 'SCIM Definitions, Overview, Concepts and Requirements' (draft-ietf-scim-use-cases-08.txt) as Informational RFC This document is the product of the System for Cross-domain Identity Management Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Technical Summary The SCIM use cases informational document covers the core set of use cases discussed in the working group to be used as guidance in developing SCIM schema and API documents. Review and Consensus The document has been reviewed by the working group. The active contributions mostly come from a relatively small number of vendors. The current documents represent use cases for "version 2.0" of an earlier standard that was developed at OpenWeb Foundation. The document has gone through WGLC and all comments were addressed during the WGLC. It is the view of the shepherd that the document should be published. Personnel Document shepherd: Morteza Ansari Responsible AD: Barry Leiba From nobody Wed May 20 20:04:55 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D551ACEAA for ; Wed, 20 May 2015 20:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2MDus3koT4Z for ; Wed, 20 May 2015 20:04:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FDE1ACEA8 for ; Wed, 20 May 2015 20:04:52 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4L34pbp026374 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 May 2015 03:04:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4L34oN2024707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 May 2015 03:04:51 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t4L34o2m023050 for ; Thu, 21 May 2015 03:04:50 GMT Received: from [10.10.2.242] (/67.151.22.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 May 2015 20:04:50 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-492539BC-3640-47A7-95AB-2484D97AB182 Content-Transfer-Encoding: 7bit From: Phil Hunt Mime-Version: 1.0 (1.0) Date: Wed, 20 May 2015 20:04:49 -0700 Message-Id: To: SCIM WG X-Mailer: iPhone Mail (12F70) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [scim] Saslprepbis dependency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 03:04:54 -0000 --Apple-Mail-492539BC-3640-47A7-95AB-2484D97AB182 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good news. Our main normative dependency for SCIM is now published. =20 Peter Saint-Andre (@stpeter) 2015-05-20, 09:17 RFC 7564: An Internationalization Odyssey. Actual title too long for 140 cha= racters. :-) stpeter.im/journal/1527.h=E2=80=A6 #i18n Phil= --Apple-Mail-492539BC-3640-47A7-95AB-2484D97AB182 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Good news. Our main normative dependen= cy for SCIM is now published.  

P= eter Saint-Andre (@stpeter)
RFC 7564: An Internationalization Odyssey.= Actual title too long for 140 characters. :-) stpeter.im/journal/1527.h=E2=80=A6 #i18n



Phil
= --Apple-Mail-492539BC-3640-47A7-95AB-2484D97AB182-- From nobody Wed May 20 22:26:15 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B581A001A for ; Wed, 20 May 2015 22:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_REMOTE_IMAGE=0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLeX7C0wAYmB for ; Wed, 20 May 2015 22:26:12 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0288C1A005D for ; Wed, 20 May 2015 22:26:12 -0700 (PDT) Received: by labbd9 with SMTP id bd9so95200166lab.2 for ; Wed, 20 May 2015 22:26:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=RlP90EKIvemmnQnj7r5nkRNPoVvm87g/7LdpLSO/e6E=; b=GSks0LSha1cm0KseLujiSaXUQysQNAK3Nux2s5lSTtZ3ltzjxIJbXPYO/L6RyXJo9z XUBuSQ0qrvhFhoNDCpZHboGVEpVq3Ks5InI1OXYuOTp5BmviHId5KCV8XpX3yNTxbYbw LZMexfrsvG23o5vFby+0NIsfiTucJqV1R23KzLEcc0MVVoVPPWqQ09EHaDKgGLTy8Txd VZ9ODg1QmNMfVSv3XwYp+wenOYoQyv1G6lemBHqcF2wgVPIlxH21M+BUH2XCAyV+YC39 ADqmzvur+ftVh81gC6qxkDZ6QPhGBm/vw8zjZCAyIZ60P9tK48ossq7tTwOhiWHax7Rl 06Nw== X-Gm-Message-State: ALoCoQk1cJanIzA9SJjJ7AWg57N5v9TvSpKKHQ43cw0qrQAb3QS3hYPoLxUN4mDaIMgRhS8FOmIX X-Received: by 10.152.181.34 with SMTP id dt2mr728387lac.84.1432185970493; Wed, 20 May 2015 22:26:10 -0700 (PDT) Received: from [10.0.0.141] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id w7sm5037730lag.42.2015.05.20.22.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 22:26:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-831E3218-2EF5-4831-8516-6570B1E71C07 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Thu, 21 May 2015 07:26:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Phil Hunt Archived-At: Cc: SCIM WG , Peter Saint-Andre Subject: Re: [scim] Saslprepbis dependency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 05:26:14 -0000 --Apple-Mail-831E3218-2EF5-4831-8516-6570B1E71C07 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ... explains the grey hairs :-) Thx a lot stpeter! > 21 maj 2015 kl. 05:04 skrev Phil Hunt : >=20 > Good news. Our main normative dependency for SCIM is now published. =20 >=20 > Peter Saint-Andre (@stpeter) > 2015-05-20, 09:17 > RFC 7564: An Internationalization Odyssey. Actual title too long for 140 c= haracters. :-) stpeter.im/journal/1527.h=E2=80=A6 #i18n >=20 >=20 >=20 > Phil > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-831E3218-2EF5-4831-8516-6570B1E71C07 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
... explains the grey hairs= :-)

Thx a lot stpeter!

21 maj 2015 k= l. 05:04 skrev Phil Hunt <phil.hu= nt@oracle.com>:

Good ne= ws. Our main normative dependency for SCIM is now published.  

Peter Saint-Andre (@stpeter)
RFC 7564: A= n Internationalization Odyssey. Actual title too long for 140 characters. :-= ) stpeter.im/journal/1527.h=E2=80=A6= #i18n



Phil
=
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-831E3218-2EF5-4831-8516-6570B1E71C07-- From nobody Wed May 20 23:59:59 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4C1A033A for ; Wed, 20 May 2015 23:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1wSGEJiKRYp for ; Wed, 20 May 2015 23:08:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7180D1A01F4 for ; Wed, 20 May 2015 23:08:36 -0700 (PDT) Received: from [10.204.175.11] (unknown [166.177.251.89]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 23D974064A; Thu, 21 May 2015 00:14:05 -0600 (MDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4B78AE58-AF2C-4562-B998-AF1D9D23818A Content-Transfer-Encoding: 7bit Message-Id: <278A679E-4753-4D4D-8559-5601B91EA2CD@stpeter.im> X-Mailer: iPhone Mail (12F70) From: Peter Saint-Andre Date: Wed, 20 May 2015 23:08:31 -0700 To: Leif Johansson Archived-At: X-Mailman-Approved-At: Wed, 20 May 2015 23:59:59 -0700 Cc: SCIM WG , Phil Hunt Subject: Re: [scim] Saslprepbis dependency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 06:08:38 -0000 --Apple-Mail-4B78AE58-AF2C-4562-B998-AF1D9D23818A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Actually it's only the PRECIS framework that was published today. The saslpr= epbis spec is on the agenda for next week's IESG telechat so if all goes wel= l it might become an RFC in 6-8 weeks.=20 Sent from mobile, might be terse=20 > On May 20, 2015, at 10:26 PM, Leif Johansson wrote: >=20 > ... explains the grey hairs :-) >=20 > Thx a lot stpeter! >=20 >> 21 maj 2015 kl. 05:04 skrev Phil Hunt : >>=20 >> Good news. Our main normative dependency for SCIM is now published. =20 >>=20 >> Peter Saint-Andre (@stpeter) >> 2015-05-20, 09:17 >> RFC 7564: An Internationalization Odyssey. Actual title too long for 140 c= haracters. :-) stpeter.im/journal/1527.h=E2=80=A6 #i18n >>=20 >>=20 >>=20 >> Phil >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-4B78AE58-AF2C-4562-B998-AF1D9D23818A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Actually it's only the PRECIS framewor= k that was published today. The saslprepbis spec is on the agenda for next w= eek's IESG telechat so if all goes well it might become an RFC in 6-8 weeks.=  

Sent from mobile, might be terse 

On May 20= , 2015, at 10:26 PM, Leif Johansson <leif= j@mnt.se> wrote:

=
... explains the grey hairs :-)

Thx a lot stpe= ter!

21 maj 2015 kl. 05:04 skrev Phil Hunt <phil.hunt@oracle.com>:

Good news. Our main normative dependency for SCIM i= s now published.  




Phil
_______________________________________________
scim mailing list
scim@ie= tf.org
https://www.ietf.org/mailman/listinfo/scim
= --Apple-Mail-4B78AE58-AF2C-4562-B998-AF1D9D23818A-- From nobody Thu May 21 04:16:40 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B191ACDC8 for ; Thu, 21 May 2015 04:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 762hcGLrM_mb for ; Thu, 21 May 2015 04:16:36 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66EF1ACDC4 for ; Thu, 21 May 2015 04:16:35 -0700 (PDT) Received: by labbd9 with SMTP id bd9so100824319lab.2 for ; Thu, 21 May 2015 04:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jzPQjcRY+jCs2cixYJcR+57lPRqmvQnV6DKlXpx2db4=; b=kkBagAd74UbfM4DuqFnzLOzSRVh3dbx7yLJIU3lDuc2XNgzcSAnX5BZ7yDV45jGc79 JFqgRac5oDq6Dc927Cgj55OtQsrIGePkK5ND27r956PFGaX+Qc/ooaDh3MeaSKEA7yOf U2wtMnnPU0qGOUC1JxK3TDcTFaQ+pfPhehUAiPeDXvs4TKKFaierhPBp31+M1ol36r7X GrTQIZC2P7WXMgfzNmUmpLpRSN+A5WOZ/801jaIhQchUAXY6Ul8rr0bCMtA2/9lr5dfC 081Fb7GJHfEay1tBzL2wjI9JnvtNpFjjn6e1MlyIMSAjQF5GKQMSivHLrz1SvvqAYnzL zpKQ== X-Gm-Message-State: ALoCoQmSvYH8xn2K07R75vzkj18UVbyAIueuFhrJEs/xqXkoabHC3Y+7Ago+VOxy3OqXPsN8z/QG X-Received: by 10.152.5.134 with SMTP id s6mr1659688las.99.1432206994265; Thu, 21 May 2015 04:16:34 -0700 (PDT) Received: from [193.10.94.104] ([193.10.94.104]) by mx.google.com with ESMTPSA id ln6sm5211419lac.45.2015.05.21.04.16.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 04:16:33 -0700 (PDT) Message-ID: <555DBE90.7010309@mnt.se> Date: Thu, 21 May 2015 13:16:32 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt , Morteza Ansari References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> <7D10FC5A-F5E4-4EA1-8F8A-B04AD348E68C@oracle.com> In-Reply-To: <7D10FC5A-F5E4-4EA1-8F8A-B04AD348E68C@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Anthony Nadalin , Barry Leiba , Stephen Farrell , "scim@ietf.org" Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:16:38 -0000 On 05/21/2015 12:51 AM, Phil Hunt wrote: > Monday works for me. I arrive Sunday morning. wfm too Monday night it is > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On May 20, 2015, at 3:50 PM, Morteza Ansari (moransar) wrote: >> >> Monday going once, twice, 隆娄 Please speak up if Monday does not work for >> you. >> >> In the meantime Barry & Stephen please pencil in Monday night before it >> gets booked. We will do a final confirmation tomorrow. >> >> >> Cheers, >> Morteza >> >> On 5/20/15, 3:41 PM, "Barry Leiba" wrote: >> >>>> I don漏枚t think you can get bad beer anywhere in Prague! Beer museum has >>>> an >>>> amazing selection of beers on tap, though could be loud if we don漏枚t >>>> find a >>>> good table. Given Stephen漏枚s availability, how about we shoot for Monday >>>> night? >>> >>> Monday night works for me, as long as we book it now, before things >>> fill up. So it's booked for SCIM. >>> >>> b >> > From nobody Thu May 21 08:07:07 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882BF1A6FEE for ; Thu, 21 May 2015 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W3KjYd6Z8lX for ; Thu, 21 May 2015 08:07:01 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0681A1A9C for ; Thu, 21 May 2015 08:06:47 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4LF6jIL008562 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 May 2015 15:06:46 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4LF6iWH014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 May 2015 15:06:44 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4LF6hcm031051; Thu, 21 May 2015 15:06:43 GMT Received: from [10.10.4.119] (/67.151.22.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 May 2015 08:06:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_286A15CA-90F7-4A38-B800-EDCB6DB9A2FC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: <278A679E-4753-4D4D-8559-5601B91EA2CD@stpeter.im> Date: Thu, 21 May 2015 08:06:42 -0700 Message-Id: References: <278A679E-4753-4D4D-8559-5601B91EA2CD@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Leif Johansson , SCIM WG Subject: Re: [scim] Saslprepbis dependency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:07:05 -0000 --Apple-Mail=_286A15CA-90F7-4A38-B800-EDCB6DB9A2FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops=E2=80=A6sorry for the false alarm. Still it is good news. Congrats = Peter! Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 20, 2015, at 11:08 PM, Peter Saint-Andre = wrote: >=20 > Actually it's only the PRECIS framework that was published today. The = saslprepbis spec is on the agenda for next week's IESG telechat so if = all goes well it might become an RFC in 6-8 weeks.=20 >=20 > Sent from mobile, might be terse=20 >=20 > On May 20, 2015, at 10:26 PM, Leif Johansson > wrote: >=20 >> ... explains the grey hairs :-) >>=20 >> Thx a lot stpeter! >>=20 >> 21 maj 2015 kl. 05:04 skrev Phil Hunt >: >>=20 >>> Good news. Our main normative dependency for SCIM is now published. =20= >>>=20 >>> Peter Saint-Andre (@stpeter = ) >>> 2015-05-20, 09:17 = >>> RFC 7564: An Internationalization Odyssey. Actual title too long for = 140 characters. :-) stpeter.im/journal/1527.h=E2=80=A6 = #i18n = >>>=20 >>>=20 >>> Phil >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim = > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_286A15CA-90F7-4A38-B800-EDCB6DB9A2FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oops=E2=80=A6sorry for the false alarm. Still it is good = news.  Congrats Peter!


On May 20, 2015, at 11:08 PM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

Actually it's = only the PRECIS framework that was published today. The saslprepbis spec = is on the agenda for next week's IESG telechat so if all goes well it = might become an RFC in 6-8 weeks. 

Sent = from mobile, might be terse 

On = May 20, 2015, at 10:26 PM, Leif Johansson <leifj@mnt.se> wrote:

... = explains the grey hairs :-)

Thx a lot stpeter!

21 = maj 2015 kl. 05:04 skrev Phil Hunt <phil.hunt@oracle.com>:

Good news. Our main = normative dependency for SCIM is now published.  

Peter Saint-An= dre (@stpe= ter)
RFC 7564: An Internationalization Odyssey. Actual title= too long for 140 characters. :-) = stpeter.im/journal/1527.h=E2=80=A6 #i18n
Peter Saint-Andre (@stpeter)
2015-05-20, 09:17
RFC = 7564: An Internationalization Odyssey. Actual title too long for 140 = characters. :-) stpeter.im/journal/1527.h=E2=80=A6 #i18n



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

= --Apple-Mail=_286A15CA-90F7-4A38-B800-EDCB6DB9A2FC-- From nobody Thu May 21 10:11:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213D41A007E for ; Thu, 21 May 2015 10:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls316RKocwql for ; Thu, 21 May 2015 10:11:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2443F1A1A3D for ; Thu, 21 May 2015 10:07:15 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4LH7EUB002592 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 May 2015 17:07:14 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4LH7EiI025981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 May 2015 17:07:14 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4LH7EAq024558 for ; Thu, 21 May 2015 17:07:14 GMT Received: from [10.151.97.254] (/148.87.13.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 May 2015 10:07:13 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_907DF26E-A34D-4E6E-B10A-F95106D7A476" Message-Id: Date: Thu, 21 May 2015 10:07:13 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:11:49 -0000 --Apple-Mail=_907DF26E-A34D-4E6E-B10A-F95106D7A476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The use case document is apparently ready to go. Do we want to hold it = and publish it together with the Protocol and Schema docs (as a = cluster)? The result would be a sequential set of RFCs (just like what just = happened for JOSE). Any objection to publishing together? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_907DF26E-A34D-4E6E-B10A-F95106D7A476 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The use case document is apparently ready to go. Do we want = to hold it and publish it together with the Protocol and Schema docs (as = a cluster)?

The = result would be a sequential set of RFCs (just like what just happened = for JOSE).

Any = objection to publishing together?


= --Apple-Mail=_907DF26E-A34D-4E6E-B10A-F95106D7A476-- From nobody Thu May 21 10:28:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56B11A00BE for ; Thu, 21 May 2015 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFPvvnyAZE4p for ; Thu, 21 May 2015 10:28:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1397D1A00F7 for ; Thu, 21 May 2015 10:28:05 -0700 (PDT) Received: from BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) by BN1PR04MB311.namprd04.prod.outlook.com (10.141.63.153) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 21 May 2015 17:27:47 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 21 May 2015 17:27:46 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.189]) with mapi id 15.01.0160.009; Thu, 21 May 2015 17:27:46 +0000 From: Kelly Grizzle To: Phil Hunt , SCIM WG Thread-Topic: [scim] publish scim docs as a cluster? Thread-Index: AQHQk+k8IQso/+z0+kW4ojRkyO7JyJ2Grw1g Date: Thu, 21 May 2015 17:27:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: A2970006009DDCA2970153 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.grizzle@sailpoint.com; x-originating-ip: [97.79.140.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB391; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB311; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR04MB391; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB391; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(189002)(5001860100001)(19580405001)(19580395003)(102836002)(5001830100001)(15975445007)(68736005)(16236675004)(105586002)(74316001)(19617315012)(122556002)(62966003)(77156002)(189998001)(5001770100001)(97736004)(4001540100001)(81156007)(40100003)(107886002)(5001960100002)(16601075003)(76576001)(2900100001)(46102003)(2950100001)(106356001)(99286002)(106116001)(54356999)(66066001)(64706001)(19300405004)(50986999)(76176999)(19625215002)(33656002)(101416001)(87936001)(2656002)(86362001)(92566002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sailpoint.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN1PR04MB39237B5BB6F9C6FEF7B4CDDE2C10BN1PR04MB392namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 17:27:46.2849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB391 X-OriginatorOrg: sailpoint.com Archived-At: Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:28:07 -0000 --_000_BN1PR04MB39237B5BB6F9C6FEF7B4CDDE2C10BN1PR04MB392namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for publishing together. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 21, 2015 12:07 PM To: SCIM WG Subject: [scim] publish scim docs as a cluster? The use case document is apparently ready to go. Do we want to hold it and = publish it together with the Protocol and Schema docs (as a cluster)? The result would be a sequential set of RFCs (just like what just happened = for JOSE). Any objection to publishing together? Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_BN1PR04MB39237B5BB6F9C6FEF7B4CDDE2C10BN1PR04MB392namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for publishing tog= ether.

 <= /p>

From: scim [ma= ilto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 21, 2015 12:07 PM
To: SCIM WG
Subject: [scim] publish scim docs as a cluster?

 

The use case document is apparently ready to go. Do = we want to hold it and publish it together with the Protocol and Schema doc= s (as a cluster)?

 

The result would be a sequential set of RFCs (just l= ike what just happened for JOSE).

 

Any objection to publishing together?

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

--_000_BN1PR04MB39237B5BB6F9C6FEF7B4CDDE2C10BN1PR04MB392namprd_-- From nobody Thu May 21 10:43:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6E1A011D for ; Thu, 21 May 2015 10:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRMWWKvN8Ve6 for ; Thu, 21 May 2015 10:43:29 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BD71A0203 for ; Thu, 21 May 2015 10:43:29 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so16149080igb.0 for ; Thu, 21 May 2015 10:43:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ikw+6p3xglV253k53VnXH63wDOt970DPZUmPuNy6t1g=; b=Y39bhE19TWc5U+svAuJBtdnbKy5od0pW3pG9rMH2E4MA+BGXTZB4M5JGQje8RdaUbx PYJkDZeNxS3EAS9u/XgzwcvtCvidUFpap6TewFEf87MoGAh5WIPTH1KEgHRc0w3aMKrO PWN16vNj0FZHRv3qndfmZWpB/xE2Wj102NtFTHYt6O7sG+6GEg9EdL4lZgn57+XAyAXB moi21NWxD20VjjI7KiT8LmFJqTtm0R+OqLusvXoFknt6RwSnlgam+wBuh+nYFyQzcenl 8DEzUzx/E/BGLl10FJpkwEK7bxQMRuKYzUagcDyUGHoSbnIxEzlPWynn4qM8PUGAI4iC SLqg== X-Gm-Message-State: ALoCoQnSf0tr6eYSv/uN6/iBXXH+v/WNY24ayneotkjH0rUIfcTXwNm0dkKzAcRR26zLBI1/+B2Y X-Received: by 10.42.81.75 with SMTP id y11mr4652763ick.88.1432230208368; Thu, 21 May 2015 10:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.116.15 with HTTP; Thu, 21 May 2015 10:43:08 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Thu, 21 May 2015 13:43:08 -0400 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=20cf301cc1b2cea47705169b1482 Archived-At: Cc: SCIM WG , Phil Hunt Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:43:31 -0000 --20cf301cc1b2cea47705169b1482 Content-Type: text/plain; charset=UTF-8 Agreed - publish together On Thu, May 21, 2015 at 1:27 PM, Kelly Grizzle wrote: > +1 for publishing together. > > > > *From:* scim [mailto:scim-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Thursday, May 21, 2015 12:07 PM > *To:* SCIM WG > *Subject:* [scim] publish scim docs as a cluster? > > > > The use case document is apparently ready to go. Do we want to hold it and > publish it together with the Protocol and Schema docs (as a cluster)? > > > > The result would be a sequential set of RFCs (just like what just happened > for JOSE). > > > > Any objection to publishing together? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --20cf301cc1b2cea47705169b1482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed - publish together
=
On Thu, May 21, 2015 at 1:27 PM, Kelly Grizz= le <kelly.grizzle@sailpoint.com> wrote:

+1 for publishing togethe= r.

=C2=A0

From: scim [ma= ilto:scim-bounce= s@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 21, 2015 12:07 PM
To: SCIM WG
Subject: [scim] publish scim docs as a cluster?=

=C2=A0

The use case document is apparently ready to go. Do = we want to hold it and publish it together with the Protocol and Schema doc= s (as a cluster)?

=C2=A0

The result would be a sequential set of RFCs (just l= ike what just happened for JOSE).

=C2=A0

Any objection to publishing together?<= /p>

=C2=A0

Phil<= /p>

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0


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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--20cf301cc1b2cea47705169b1482-- From nobody Thu May 21 11:07:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D6B1A1A34 for ; Thu, 21 May 2015 11:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqtLlWRiqjTS for ; Thu, 21 May 2015 11:07:01 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF6D1A19E4 for ; Thu, 21 May 2015 11:07:01 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so16706048igb.0 for ; Thu, 21 May 2015 11:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7OkvCOYtN/G+fnnexANh317yxWtPGCGznUUGTZYWej8=; b=SsmADqXJrjb8YDf3JjiCEm6b1puYIWfZxMjboY7hRjp1ILAmasWTaHS9o/qtW9PQq8 ezna76wkucIIY5v/RifFtnn2FVYi6OMGgUVrXz2/Feb+c2zHWv390Opt7Dn3bRa4Wv0K uUIq/k+xxGw0Dn1PQ0ep6herhlzAl815rsK17tw/taa4rQwSA6s3ObakbeTC1zcUwVem fhSIzFx56sRfIqHdClqJzupLVuVwFvN5uyaw0587sXp59dxTNHv9DHCo+jzbL5xbICei uXz9xaZ+Bw8gToXZDY+n3KoPSm1aGN4fV8UXNgvtw9aRMOa7iCya1I5c05snvRXxopD2 Dfag== MIME-Version: 1.0 X-Received: by 10.42.102.142 with SMTP id i14mr4735652ico.90.1432231620637; Thu, 21 May 2015 11:07:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Thu, 21 May 2015 11:07:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 14:07:00 -0400 X-Google-Sender-Auth: KDy0owPzkZtuL2vep8SRI4fUa-4 Message-ID: From: Barry Leiba To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: SCIM WG Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:07:02 -0000 Three "votes" for clustering the three, and none against yet. I'll send the RFC Editor a note asking them to put them in a cluster. Barry On Thu, May 21, 2015 at 1:07 PM, Phil Hunt wrote: > The use case document is apparently ready to go. Do we want to hold it and > publish it together with the Protocol and Schema docs (as a cluster)? > > The result would be a sequential set of RFCs (just like what just happened > for JOSE). > > Any objection to publishing together? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Thu May 21 11:09:06 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1E1A034F for ; Thu, 21 May 2015 11:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUuetMlDUdF0 for ; Thu, 21 May 2015 11:09:03 -0700 (PDT) Received: from mail.cleargovsolutions.com (mail.cleargovsolutions.com [74.217.92.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB8D1A1A3D for ; Thu, 21 May 2015 11:09:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1432230796; x=1432835596; s=mail01; d=cleargovsolutions.com; c=relaxed/relaxed; v=1; bh=ISEXZJ5dQRGBuTzXmrND28zQMCI=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=/CeAjODo0ji3fM/nMx0zV/OD3xh5K7igWPpbz4x9U/safAcN3meYGh1gCe8qZq9oofjGazLidRZgmJ7tXWaHtOv10DvaIgeJJgfQ01MJt/3FeWhPra2IZ8Des9VSxGuTzKaGGSapOj5DZiSuXeIsM6mbB9RnLW6CpP/GVJRbGqs= Received: from AlexisPC ([65.115.222.48]) by mail.cleargovsolutions.com (IceWarp 11.1.1.0 x64) with ASMTP id 201505211353151808; Thu, 21 May 2015 13:53:15 -0400 From: "Alexis Bor" To: "'Phil Hunt'" , "'SCIM WG'" References: In-Reply-To: Date: Thu, 21 May 2015 13:08:43 -0500 Message-ID: <008301d093f1$2dc5bf00$89513d00$@cleargovsolutions.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01D093C7.44F2C440" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQOk0B4U8RRKQ/iBvjN4vIj82B7/+JneQckw Content-Language: en-us Archived-At: Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:09:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0084_01D093C7.44F2C440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have been mostly a lurker in this effort, but from experience, it really helped a lot when LDAP was issued with sequential numbers. Alexis From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 21, 2015 12:07 PM To: SCIM WG Subject: [scim] publish scim docs as a cluster? The use case document is apparently ready to go. Do we want to hold it and publish it together with the Protocol and Schema docs (as a cluster)? The result would be a sequential set of RFCs (just like what just happened for JOSE). Any objection to publishing together? Phil @independentid www.independentid.com phil.hunt@oracle.com ------=_NextPart_000_0084_01D093C7.44F2C440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been mostly a lurker in this effort, but from experience, it = really helped a lot when LDAP was issued with sequential = numbers.

 

Alexis

 

From:<= /b> = scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, May 21, 2015 12:07 PM
To: SCIM = WG
Subject: [scim] publish scim docs as a = cluster?

 

The use case = document is apparently ready to go. Do we want to hold it and publish it = together with the Protocol and Schema docs (as a = cluster)?

 

The result would be a sequential set of RFCs (just = like what just happened for JOSE).

 

Any objection to publishing = together?

 

= Phil

=  

= @independentid

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

 

------=_NextPart_000_0084_01D093C7.44F2C440-- From nobody Thu May 21 11:57:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3B1A8849 for ; Thu, 21 May 2015 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.192 X-Spam-Level: * X-Spam-Status: No, score=1.192 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKDuAMrchyCx for ; Thu, 21 May 2015 11:57:28 -0700 (PDT) Received: from nm41-vm4.bullet.mail.bf1.yahoo.com (nm41-vm4.bullet.mail.bf1.yahoo.com [216.109.114.159]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0631A876F for ; Thu, 21 May 2015 11:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432234646; bh=MvVm21HWRRWXVmHYbvmnFqETwO9RklE3JU8fjbcXhGY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Y+oBQFkbqFVdOyVSxp72/NZjAMU8mCFPTT5qWyn/PBDkFtQIUdMMUgMrfMNuLSMfo8WebsHdk4+MjPnssoEAvv1wLiaMxe2m1pyZF3XWHJdvwm1QdATY1fU9YZxb3ipooTWxKQrSFUCGxgqevLdRP9tMZUQsTjsG3fDmv9oI2Jf9v7Atvy5X4MP+xnaHrwf5xB/5TrqfT5W1irRh3YJoDNOMkE10pVFIRywdcg7yUueI5RD6X5Nmj0PPYxvlXRrYb6AHkTVSfHDPwNDUOkI7bFaJrYXZuF5rXVehwCzOYrZC10f8vuDxr8r/8szGSFJeKBTD3BjFyFh8cphM9oZLMQ== Received: from [98.139.215.141] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2015 18:57:26 -0000 Received: from [98.139.212.230] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2015 18:57:26 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 21 May 2015 18:57:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 603944.96952.bm@omp1039.mail.bf1.yahoo.com X-YMail-OSG: pcUT93MVM1kbxUXfGtfFnf0dGIVul8iTAkYOih0BHn6sdty0RyKIT_AG4j1G2ha Y5eW2Ht3QExiwlJO0D9U3PXqSFMHxJaaPHr7Y1QXR7LK7V9D5a84T6TxD3DnqPH1ScrLXklCo8i3 TCrSBk7va067R7W7QpRmH6AdN2UF4VkQQefeyhdx3O_Tqu_Ln8bTepfMFXn9L984FggcF.v0v29m .wzXVgOTb2c5bKhBeyAGgsZhPLK1cR6TIju3R4kN1_uLgE8LFqOpeUNHToQC0FWf0q1xvLmLecxz uIKD6ueSqfqbb99LwcYdNxxaRf3WyPPGBCsBqXZykW1zbjP8L1pQFUNXpGSOduAsn9wFj8AU5Cos EXvW.LQ6N7bBRcEhP4e7d2l6kGIcKIUeKBjKYxG.k25Ijm_tFZPbsd4fWchI7I8EQMDLNfrT5Lnu lwmsNGLXI0zjeLhsGKni3ayX4zwrFz.5VaPY1r.6XCh4mJToCSAHXvB18cC8l.nB_CqFuMthPUg6 uqrUA1sMcileXGQ-- Received: by 76.13.26.127; Thu, 21 May 2015 18:57:26 +0000 Date: Thu, 21 May 2015 18:57:25 +0000 (UTC) From: Bill Mills To: Alexis Bor , 'Phil Hunt' , 'SCIM WG' Message-ID: <107148480.4719113.1432234645726.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <008301d093f1$2dc5bf00$89513d00$@cleargovsolutions.com> References: <008301d093f1$2dc5bf00$89513d00$@cleargovsolutions.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4719112_725875679.1432234645717" Archived-At: Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:57:29 -0000 ------=_Part_4719112_725875679.1432234645717 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Various good reasons to cluster and no reason not to.=20 On Thursday, May 21, 2015 11:09 AM, Alexis Bor wrote: =20 #yiv5402928526 #yiv5402928526 -- _filtered #yiv5402928526 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv5402928526 {panose-1:2= 4 5 3 5 4 6 3 2 4;} _filtered #yiv5402928526 {font-family:Calibri;panose-1= :2 15 5 2 2 2 4 3 2 4;}#yiv5402928526 #yiv5402928526 p.yiv5402928526MsoNorm= al, #yiv5402928526 li.yiv5402928526MsoNormal, #yiv5402928526 div.yiv5402928= 526MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv540292= 8526 a:link, #yiv5402928526 span.yiv5402928526MsoHyperlink {color:blue;text= -decoration:underline;}#yiv5402928526 a:visited, #yiv5402928526 span.yiv540= 2928526MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv54= 02928526 span.yiv5402928526apple-style-span {}#yiv5402928526 span.yiv540292= 8526EmailStyle18 {color:#1F497D;}#yiv5402928526 .yiv5402928526MsoChpDefault= {font-size:10.0pt;} _filtered #yiv5402928526 {margin:1.0in 1.0in 1.0in 1.0= in;}#yiv5402928526 div.yiv5402928526WordSection1 {}#yiv5402928526 I have be= en mostly a lurker in this effort, but from experience, it really helped a = lot when LDAP was issued with sequential numbers. =C2=A0Alexis =C2=A0From:= scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Thursday, May 21, 2015 12:07 PM To: SCIM WG Subject: [scim] publish scim docs as a cluster? =C2=A0The use case document= is apparently ready to go. Do we want to hold it and publish it together w= ith the Protocol and Schema docs (as a cluster)? =C2=A0The result would be = a sequential set of RFCs (just like what just happened for JOSE). =C2=A0Any= objection to publishing together? =C2=A0Phil =C2=A0@independentidwww.indep= endentid.comphil.hunt@oracle.com =C2=A0 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_Part_4719112_725875679.1432234645717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Various good reasons to cluster and no reason n= ot to.



On Thursday, May 21, 2015 11:09 = AM, Alexis Bor <alexis.bor@cleargovsolutions.com> wrote:
 =


<= style>#yiv5402928526 #yiv5402928526 -- =20 _filtered #yiv5402928526 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 = 2 4;} _filtered #yiv5402928526 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5402928526 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 = 4;} #yiv5402928526 =20 #yiv5402928526 p.yiv5402928526MsoNormal, #yiv5402928526 li.yiv5402928526Mso= Normal, #yiv5402928526 div.yiv5402928526MsoNormal =09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;} #yiv5402928526 a:link, #yiv5402928526 span.yiv5402928526MsoHyperlink =09{color:blue;text-decoration:underline;} #yiv5402928526 a:visited, #yiv5402928526 span.yiv5402928526MsoHyperlinkFoll= owed =09{color:purple;text-decoration:underline;} #yiv5402928526 span.yiv5402928526apple-style-span =09{} #yiv5402928526 span.yiv5402928526EmailStyle18 =09{color:#1F497D;} #yiv5402928526 .yiv5402928526MsoChpDefault =09{font-size:10.0pt;} _filtered #yiv5402928526 {margin:1.0in 1.0in 1.0in 1.0in;} #yiv5402928526 div.yiv5402928526WordSection1 =09{} #yiv5402928526
I have be= en mostly a lurker in this effort, but from experience, it really helped a = lot when LDAP was issued with sequential numbers.
 
Alexis
 
From: scim [mailto:scim-bounces@ietf.org] On Behalf O= f Phil Hunt
Sent: Thursday, May 21, 2015 12:07= PM
To: SCIM WG
Subject: = [scim] publish scim docs as a cluster?
 
The use case document is apparently ready to go. Do we want to hold it = and publish it together with the Protocol and Schema docs (as a cluster)?
 
The result would be a sequential set of R= FCs (just like what just happened for JOSE).
 
Any objection to publishing together?
 
<= div>
 

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


<= /div>
------=_Part_4719112_725875679.1432234645717-- From nobody Thu May 21 13:03:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2A71A8A5A for ; Thu, 21 May 2015 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo56KHEUDx-7 for ; Thu, 21 May 2015 13:03:51 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABF71A8A57 for ; Thu, 21 May 2015 13:03:50 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so26165464lbb.0 for ; Thu, 21 May 2015 13:03:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OoxOGcy5wdPCMTBQuX+K9LnM9nV0rjsNf4dglP4nMK4=; b=M7h/RMIp460Gs+HeUyX/yT/il+iTHY9e3u46Cso5HGK9kfF6lFs1sTn3HfbHeDvNqJ xK9Q6EKXwVKZXBraa+X8lkgbkt5hYJLprPGfLrBCrQyx/AfjRGVggf+61J7oUmHNk1iv xF5XXB8mvtzOBiJwPWuzyZsvxRKslLGmKEb8VL4hsbn6bp0G0GNd3A/Cym4bhKQ8/UYp +U8578RjyFJ/Qgl7qyte22npDC0g37IZCle2icHzMlPLz0QdJrzzg91a+hJs8vIwq27D jGq5btdIX8R08kv3yMy1ZIyOd7dVqFiRfyWpSxTSVvDiPx/WNrJJarCOcPF5cr+ZD9mi DTNg== X-Gm-Message-State: ALoCoQkGWGiBMJXJjYBnO6ob9JPFmtIbNAY6IAl2EQPjGrZ5IRcpY8OpFIxqUI8MCR8fXVpkvFdb X-Received: by 10.152.25.227 with SMTP id f3mr3512820lag.67.1432238629521; Thu, 21 May 2015 13:03:49 -0700 (PDT) Received: from [10.0.0.107] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id w9sm531279laj.21.2015.05.21.13.03.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 13:03:48 -0700 (PDT) Message-ID: <555E3A24.7020205@mnt.se> Date: Thu, 21 May 2015 22:03:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] publish scim docs as a cluster? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:03:54 -0000 On 05/21/2015 08:07 PM, Barry Leiba wrote: > Three "votes" for clustering the three, and none against yet. I'll > send the RFC Editor a note asking them to put them in a cluster. > good call From nobody Thu May 21 16:37:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F961A9105 for ; Thu, 21 May 2015 16:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56bO2p6nWtvS for ; Thu, 21 May 2015 16:37:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FD61A90DD for ; Thu, 21 May 2015 16:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1432251435; x=1433461035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TG/S99NKHGQ3n/Cf0xqUoU7V4CWm2xx4dfpgH2ZSj9o=; b=L4rKyFgIRH14/rEczkyEtxvJ2HmZvMaLBn/g7BgbICQHofAgw8cOBP5z 5RyX+tnSEu+qr0Wj2W+xeZ3JpLi6qWqT3OvqyWAMEiU6LuyihLwX9DV2v 8QnbO1bkT8U4n5OCJE8/8ZUwgcFnl75meTmyU9QNmQJqP1690vYuiIe0B A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBQCVa15V/4ENJK1cgxBUUgwGgxm/DoI+CoV3AhyBJ0wBAQEBAQGBC4QjAQEEAQEBMToLEAIBCBgEKAICJQslAgQBDQWILA2RUp0IBqQVAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBG4ofhQUHgmKBSwEEknqLB4Eog2uSCiOCChyBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,472,1427760000"; d="scan'208";a="13875597" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 21 May 2015 23:37:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4LNbF9J011237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 23:37:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 21 May 2015 18:37:14 -0500 From: "Morteza Ansari (moransar)" To: "Morteza Ansari (moransar)" , Barry Leiba Thread-Topic: [scim] Prague? Thread-Index: AQHQjlUyZJbS4LHsyECZWcHakI804J1741cAgAAAyoCAAAm6AIAACLuAgAfDvoCAALheAIAA+ReAgAABDYCAACYBAIAAAPoA//+Z2gCAAKXSgP//jS+AgAGfQQA= Date: Thu, 21 May 2015 23:37:14 +0000 Message-ID: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.85.18] Content-Type: text/plain; charset="euc-kr" Content-ID: <61245DAA90AB954C846FD879EBE43373@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anthony Nadalin , Phil Hunt , Leif Johansson , "scim@ietf.org" , Stephen Farrell Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:37:17 -0000 SSB0aGluayB3ZSBhcmUgc2V0IGZvciBNb25kYXkgbmlnaHQuIEJhcnJ5LCBzaW5jZSB5b3UgZGlk IHRoZSBob21ld29yayBmb3INCmJhciBvcHRpb25zLCBkbyB5b3Ugd2FudCB0byBwaWNrIG9uZSBv ZiB0aGVtIGFuZCBwb3N0IHRoZSBsb2NhdGlvbiBhbmQNCnRpbWU/DQoNCg0KQ2hlZXJzLA0KTW9y dGV6YQ0KDQpPbiA1LzIwLzE1LCAzOjUwIFBNLCAiTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSIg PG1vcmFuc2FyQGNpc2NvLmNvbT4NCndyb3RlOg0KDQo+TW9uZGF5IGdvaW5nIG9uY2UsIHR3aWNl LCChpiAgUGxlYXNlIHNwZWFrIHVwIGlmIE1vbmRheSBkb2VzIG5vdCB3b3JrIGZvcg0KPnlvdS4N Cj4NCj5JbiB0aGUgbWVhbnRpbWUgQmFycnkgJiBTdGVwaGVuIHBsZWFzZSBwZW5jaWwgaW4gTW9u ZGF5IG5pZ2h0IGJlZm9yZSBpdA0KPmdldHMgYm9va2VkLiAgV2Ugd2lsbCBkbyBhIGZpbmFsIGNv bmZpcm1hdGlvbiB0b21vcnJvdy4NCj4NCj4NCj5DaGVlcnMsDQo+TW9ydGV6YQ0KPg0KPk9uIDUv MjAvMTUsIDM6NDEgUE0sICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3 cm90ZToNCj4NCj4+PiBJIGRvbqn2dCB0aGluayB5b3UgY2FuIGdldCBiYWQgYmVlciBhbnl3aGVy ZSBpbiBQcmFndWUhICBCZWVyIG11c2V1bSBoYXMNCj4+PmFuDQo+Pj4gYW1hemluZyBzZWxlY3Rp b24gb2YgYmVlcnMgb24gdGFwLCB0aG91Z2ggY291bGQgYmUgbG91ZCBpZiB3ZSBkb26p9nQNCj4+ PmZpbmQgYQ0KPj4+IGdvb2QgdGFibGUuIEdpdmVuIFN0ZXBoZW6p9nMgYXZhaWxhYmlsaXR5LCBo b3cgYWJvdXQgd2Ugc2hvb3QgZm9yIE1vbmRheQ0KPj4+IG5pZ2h0Pw0KPj4NCj4+TW9uZGF5IG5p Z2h0IHdvcmtzIGZvciBtZSwgYXMgbG9uZyBhcyB3ZSBib29rIGl0IG5vdywgYmVmb3JlIHRoaW5n cw0KPj5maWxsIHVwLiAgU28gaXQncyBib29rZWQgZm9yIFNDSU0uDQo+Pg0KPj5iDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zY2ltIG1haWxp bmcgbGlzdA0KPnNjaW1AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NjaW0NCg0K From nobody Fri May 22 08:01:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE891B2C27 for ; Fri, 22 May 2015 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o2cxRibe-3q for ; Fri, 22 May 2015 08:01:53 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AE71B2C24 for ; Fri, 22 May 2015 08:01:53 -0700 (PDT) Received: by igcau1 with SMTP id au1so34692717igc.1 for ; Fri, 22 May 2015 08:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Uo4K19TF+Pbsl2/1s8/HfIBWuk8SfmXof9EDcpv945Y=; b=xMaWiXscxHHcmBeiihKJegoflkoIO1W5M4/Y+Dk/ih7q0/uqytF3M0ej3YtARxzQ+H C3QT5dzbMBicTD4Hm1V+ZOLAfz9KXPkfazrBx8T7XNGgCsEC7P93mW7FJ754Ud90zYt0 bizJ2LdmyWjmLV63FIfqBC/zrj4dXDjY1GFixmNUsq6h9pLhpqqq2gRv87QJYbRWa/y5 cxGTNtvAc1YtOu2bpAZVhPs4qo3A+yhE8DHHXoPvp0jcqdSU38A+LO0Zv4fvW0A+Jr2V RuOwj/JZAh01co/RmbB8JEt8fhuay0na/WCAcb0X4xj4z63lUc1nzwn97B9VJmBHMWSk aAKg== MIME-Version: 1.0 X-Received: by 10.42.104.143 with SMTP id r15mr9913425ico.33.1432306913204; Fri, 22 May 2015 08:01:53 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Fri, 22 May 2015 08:01:53 -0700 (PDT) In-Reply-To: References: <5554B5B5.2000805@mnt.se> <5554B82B.9020109@mnt.se> <10136803-FF94-43A5-8666-1664DD4A63E5@oracle.com> <9B8D0122-309C-4CB5-8785-0955005F65D9@oracle.com> <555BE5C0.2020005@cs.tcd.ie> Date: Fri, 22 May 2015 11:01:53 -0400 X-Google-Sender-Auth: Tr9Ck_QV4D6DxnsdwLNKSJzQL8s Message-ID: From: Barry Leiba To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Anthony Nadalin , Stephen Farrell , Leif Johansson , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] Prague? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:01:55 -0000 > I think we are set for Monday night. Barry, since you did the homework for > bar options, do you want to pick one of them and post the location and > time? Well, let's try hitting the Prague Beer Museum, http://www.praguebeermuseum.com/en, and see how our luck is. Time: 30 minutes after the end of the last session on Monday. Have to see when that is after the agenda comes out. Barry From nobody Fri May 22 09:12:09 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92EA1A6FFB for ; Thu, 21 May 2015 09:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqV3B0lP2eNG for ; Thu, 21 May 2015 09:18:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A81A8865 for ; Thu, 21 May 2015 09:18:13 -0700 (PDT) Received: from aither.local (unknown [216.9.110.15]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 927B640994; Thu, 21 May 2015 10:23:44 -0600 (MDT) Message-ID: <555E0542.6050607@stpeter.im> Date: Thu, 21 May 2015 09:18:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt References: <278A679E-4753-4D4D-8559-5601B91EA2CD@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 09:12:08 -0700 Cc: Leif Johansson , SCIM WG Subject: Re: [scim] Saslprepbis dependency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:18:17 -0000 Yes, the wheels grind slowly. :-) But getting the framework done was the big hurdle - saslprepbis is much more straightforward. Soon! On 5/21/15 8:06 AM, Phil Hunt wrote: > Oops鈥orry for the false alarm. Still it is good news. Congrats Peter! > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On May 20, 2015, at 11:08 PM, Peter Saint-Andre > > wrote: >> >> Actually it's only the PRECIS framework that was published today. The >> saslprepbis spec is on the agenda for next week's IESG telechat so if >> all goes well it might become an RFC in 6-8 weeks. >> >> Sent from mobile, might be terse >> >> On May 20, 2015, at 10:26 PM, Leif Johansson > > wrote: >> >>> ... explains the grey hairs :-) >>> >>> Thx a lot stpeter! >>> >>> 21 maj 2015 kl. 05:04 skrev Phil Hunt >> >: >>> >>>> Good news. Our main normative dependency for SCIM is now published. >>>> >>>> *Peter Saint-Andre (@stpeter >>>> )* >>>> 2015-05-20, 09:17 >>>> >>>> RFC 7564: An Internationalization Odyssey. Actual title too long for >>>> 140 characters. :-) stpeter.im/journal/1527.h鈥 >>>> #i18n >>>> >>>> >>>> >>>> >>>> >>>> Phil >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim From nobody Wed May 27 15:58:27 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851AB1A909B for ; Wed, 27 May 2015 15:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6GNEYS3YuOy for ; Wed, 27 May 2015 15:58:23 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F409F1A883D for ; Wed, 27 May 2015 15:58:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,509,1427760000"; d="scan'208,217";a="269205571" From: Haavar Valeur To: Phil Hunt Thread-Topic: [scim] SCIM Notify Draft Thread-Index: AQHQWfg8epe9EYmBKkC0R5Umdy4Tep2RYqSA Date: Wed, 27 May 2015 22:58:18 +0000 Message-ID: <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> In-Reply-To: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_92C06156AB924F5D8A68D852ED69E61Ecitrixcom_" MIME-Version: 1.0 X-DLP: MIA2 Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 22:58:25 -0000 --_000_92C06156AB924F5D8A68D852ED69E61Ecitrixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbC4NCknigJlkIGJlIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiB0aGlzLiBJIGhhdmUg YSBmZXcgdXNlcyBjYXNlcyB3aGVyZSBJIG1pZ2h0IGJlIGFibGUgdG8gYXBwbHkgU0NJTSBub3Rp ZmljYXRpb25zLg0KDQpPbmUgY29tbWVudCBJIHdvdWxkIGxpa2UgdG8gbWFrZSBvZmYgdGhlIGJh dCBpcyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBkaXZvcmNpbmcgdGhlIHRyYW5zcG9ydCBhbmQg bWVzc2FnZSBmb3JtYXQuIEkgdGhpbmsgdGhlIGJhcnJpZXIgb2YgZW50cnkgb2YgYWRvcHRpbmcg dGhlIG1lc3NhZ2UgZm9ybWF0LCB3aGlsZSB1c2luZyBleGlzdGluZyB0cmFuc3BvcnRzIGluIHRo ZSBpbmZyYXN0cnVjdHVyZSwgaXMgcmVsYXRpdmVseSBsb3cuIFRoZXJlIGlzIHZhbHVlIGluIHN3 aXRjaGluZyB0aGUgdW5kZXJsYXlpbmcgdHJhbnNwb3J0LCBidXQgaXQgc2hvdWxkIG5vdCBiZSBh IHN0cmljdCByZXF1aXJlbWVudC4NCg0KQmVzdA0KSGFhdmFyDQoNCg0KT24gTWFyIDgsIDIwMTUs IGF0IDQ6MzIgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk9uIGJlaGFsZiBvZiBJYW4gR2xhemVyLCBNb3J0 ZXphIEFuc2FyaSwgYW5kIG15c2VsZiwgSSBoYXZlIHN1Ym1pdHRlZCBhbiBpbmRpdmlkdWFsIGRy YWZ0IGNvbnRyaWJ1dGlvbiBmb3IgY29tbWVudHMgYW5kIGNvbnNpZGVyYXRpb24uIFRoZSBkcmFm dCBpcyBhdmFpbGFibGUgaGVyZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o dW50LXNjaW0tbm90aWZ5LTAwDQoNClRoZSBkcmFmdCBmb2xsb3dzIHVwIGZyb20gdGhlIHByZXNl bnRhdGlvbiBtYWRlIGF0IElFVEY5MSBpbiBIb25vbHVsdSBhbmQgZGVmaW5lcyBTQ0lNIGV2ZW50 cyBhbmQgbWVzc2FnZXMgdXNlZCB0byBub3RpZnkgc3Vic2NyaWJlcnMgb2YgZXZlbnRzIGZyb20g YSBwdWJsaXNoaW5nIHNlcnZpY2UgcHJvdmlkZXIgdmlhIGEgZGlzdHJpYnV0aW9uIHNlcnZpY2Ug a25vd24gYXMgYSBub3RpZmljYXRpb24gaHViLiAgVGhlIGh1YiBzaG91bGQgaGF2ZSB0aGUgY2Fw YWJpbGl0eSB0byBkZWxpdmVyIGV2ZW50IG1lc3NhZ2VzIHNlY3VyZWx5IHZpYSBzaW1wbGUgSFRU UCBQT1NULCBXZWJQVVNILCBhbmQgb3RoZXIgbWVzc2FnaW5nIHByb3RvY29scyB3aGVyZSB1c2Vm dWwuDQoNCkkgd291bGQgbGlrZSB0byByZXF1ZXN0IHRoYXQgd2UgYWRkIHRoaXMgYXMgYSBkaXNj dXNzaW9uIGl0ZW0gZm9yIHRoZSBEYWxsYXMgYWdlbmRhLg0KDQpBdCB0aGUgbWVldGluZyBJIHBy b3Bvc2Ugd2UgZGlzY3VzczoNCg0KMS4gIFdoYXQgYXJlIHRoZSBpbnRlbmRlZCBiZW5lZml0cyBh bmQgdXNlcyBmb3IgTm90aWZ5IGluIFNDSU0gZW52aXJvbm1lbnRzDQoyLiAgV2hhdCBhcmUgdGhl IHNjYWxhYmlsaXR5LCBpbmZvcm1hdGlvbiwgYW5kIHRlY2huaWNhbCBwcm9ibGVtcyBiZWluZyBh ZGRyZXNzZWQNCjMuICBXaGF0IGlzIGxlZnQgdG8gZGVmaW5lDQphbmQgZmluYWxseSwNCjQuICBJ cyB0aGVyZSBlbm91Z2ggaW50ZXJlc3QgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWRkIE5vdGlm eSB0byB0aGUgU0NJTSBjaGFydGVyLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5k ZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2lt QGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2Nv LmNvbS8xVzJCUjBHM0xsOXBzY1hsWlJVb0xYZVBRZFpVZE5PTW9tQV9VRDRVYUlZeUtSQmtFeXdK SmhYMnNtaUc1aEJCTW5OalVoellVd2ZOVEg2cE9iZS1FODRoRDM1cXNnU2hXVnFSYlRNdzhtS0dl NHNfZEswVVNBcDZfLTlvdnF2azBubFF0ZG5tdkd0Z1dXckVMOTZDMXI5cGd5ai1RRDVsLXNDRVNQ bUE5TXpJL2h0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c2NpbQ0KDQo= --_000_92C06156AB924F5D8A68D852ED69E61Ecitrixcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FFF5488ADE08544BCB9B435845E89F4@citrix.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgUGhpbC4NCjxkaXYgY2xhc3M9 IiI+SeKAmWQgYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIHRoaXMuIEkgaGF2ZSBhIGZldyB1 c2VzIGNhc2VzIHdoZXJlIEkgbWlnaHQgYmUgYWJsZSB0byBhcHBseSBTQ0lNIG5vdGlmaWNhdGlv bnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5PbmUgY29tbWVudCBJIHdvdWxkIGxpa2UgdG8gbWFrZSBvZmYgdGhlIGJhdCBpcyB0aGF0 IHdlIHNob3VsZCBjb25zaWRlciBkaXZvcmNpbmcgdGhlIHRyYW5zcG9ydCBhbmQgbWVzc2FnZSBm b3JtYXQuIEkgdGhpbmsgdGhlIGJhcnJpZXIgb2YgZW50cnkgb2YgYWRvcHRpbmcgdGhlIG1lc3Nh Z2UgZm9ybWF0LCB3aGlsZSB1c2luZyBleGlzdGluZyB0cmFuc3BvcnRzIGluIHRoZSBpbmZyYXN0 cnVjdHVyZSwgaXMgcmVsYXRpdmVseQ0KIGxvdy4gVGhlcmUgaXMgdmFsdWUgaW4gc3dpdGNoaW5n IHRoZSB1bmRlcmxheWluZyB0cmFuc3BvcnQsIGJ1dCBpdCBzaG91bGQgbm90IGJlIGEgc3RyaWN0 IHJlcXVpcmVtZW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+QmVzdDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IYWF2YXI8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1hciA4LCAyMDE1LCBhdCA0OjMyIFBNLCBQaGlsIEh1 bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgY2xhc3M9IiI+cGhp bC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uIGJlaGFsZiBvZiBJYW4gR2xh emVyLCBNb3J0ZXphIEFuc2FyaSwgYW5kIG15c2VsZiwgSSBoYXZlIHN1Ym1pdHRlZCBhbiBpbmRp dmlkdWFsIGRyYWZ0IGNvbnRyaWJ1dGlvbiBmb3IgY29tbWVudHMgYW5kIGNvbnNpZGVyYXRpb24u IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtc2NpbS1ub3RpZnktMDAiIGNsYXNz PSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tbm90aWZ5LTAw PC9hPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoZSBkcmFmdCBmb2xsb3dzIHVwIGZyb20gdGhlIHByZXNlbnRhdGlvbiBt YWRlIGF0IElFVEY5MSBpbiBIb25vbHVsdSBhbmQgZGVmaW5lcyBTQ0lNIGV2ZW50cyBhbmQgbWVz c2FnZXMgdXNlZCB0byBub3RpZnkgc3Vic2NyaWJlcnMgb2YgZXZlbnRzIGZyb20gYSBwdWJsaXNo aW5nIHNlcnZpY2UgcHJvdmlkZXIgdmlhIGEgZGlzdHJpYnV0aW9uIHNlcnZpY2Uga25vd24gYXMg YSBub3RpZmljYXRpb24gaHViLiAmbmJzcDtUaGUgaHViDQogc2hvdWxkIGhhdmUgdGhlIGNhcGFi aWxpdHkgdG8gZGVsaXZlciBldmVudCBtZXNzYWdlcyBzZWN1cmVseSB2aWEgc2ltcGxlIEhUVFAg UE9TVCwgV2ViUFVTSCwgYW5kIG90aGVyIG1lc3NhZ2luZyBwcm90b2NvbHMgd2hlcmUgdXNlZnVs LiAmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkkgd291bGQgbGlrZSB0byByZXF1ZXN0IHRoYXQgd2UgYWRkIHRoaXMgYXMgYSBk aXNjdXNzaW9uIGl0ZW0gZm9yIHRoZSBEYWxsYXMgYWdlbmRhLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXQgdGhlIG1lZXRpbmcgSSBw cm9wb3NlIHdlIGRpc2N1c3M6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLiAmbmJzcDtXaGF0IGFyZSB0aGUgaW50ZW5kZWQgYmVuZWZp dHMgYW5kIHVzZXMgZm9yIE5vdGlmeSBpbiBTQ0lNIGVudmlyb25tZW50czwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4yLiAmbmJzcDtXaGF0IGFyZSB0aGUgc2NhbGFiaWxpdHksIGluZm9ybWF0aW9uLCBh bmQgdGVjaG5pY2FsIHByb2JsZW1zIGJlaW5nIGFkZHJlc3NlZDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4zLiAmbmJzcDtXaGF0IGlzIGxlZnQgdG8gZGVmaW5lPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFu ZCBmaW5hbGx5LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj40LiAmbmJzcDtJcyB0aGVyZSBlbm91Z2gg aW50ZXJlc3QgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWRkIE5vdGlmeSB0byB0aGUgU0NJTSBj aGFydGVyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGJvcmRlci1zcGFj aW5nOiAwcHg7Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1j b2xsYXBzZTogc2VwYXJhdGU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyBib3JkZXItc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7IHdvcmQtc3BhY2luZzogMHB4OyBib3JkZXItc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt ZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTogc2VwYXJhdGU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog MjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IGJvcmRlci1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+UGhpbDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QGluZGVwZW5kZW50aWQ8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSIg Y2xhc3M9IiI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiBjbGFzcz0iIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnNjaW0gbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIGNsYXNzPSIiPnNjaW1A aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8x VzJCUjBHM0xsOXBzY1hsWlJVb0xYZVBRZFpVZE5PTW9tQV9VRDRVYUlZeUtSQmtFeXdKSmhYMnNt aUc1aEJCTW5OalVoellVd2ZOVEg2cE9iZS1FODRoRDM1cXNnU2hXVnFSYlRNdzhtS0dlNHNfZEsw VVNBcDZfLTlvdnF2azBubFF0ZG5tdkd0Z1dXckVMOTZDMXI5cGd5ai1RRDVsLXNDRVNQbUE5TXpJ L2h0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2NpbTxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92C06156AB924F5D8A68D852ED69E61Ecitrixcom_-- From nobody Wed May 27 16:12:42 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746B1B2A8E for ; Wed, 27 May 2015 16:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tStg3WTuKR4y for ; Wed, 27 May 2015 16:12:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01AC1B2A6E for ; Wed, 27 May 2015 16:12:38 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4RNCa1w019828 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 May 2015 23:12:36 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4RNCZp5029776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2015 23:12:36 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4RNCZxB031310; Wed, 27 May 2015 23:12:35 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 May 2015 16:12:34 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-FC9D4D09-68C0-4C1F-80C3-3C1D2854A5AA Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> Date: Wed, 27 May 2015 16:12:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> To: Haavar Valeur X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 23:12:41 -0000 --Apple-Mail-FC9D4D09-68C0-4C1F-80C3-3C1D2854A5AA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the feed back.=20 I agree we should narrow down where possible.=20 Would like to see a single publish method but I can see need for multiple de= livery methods.=20 Scale and diversity are issues. Eg major cloud sp to major cloud sp is diffe= rent from secure mobile events.=20 There was a lot of pressure to consider web push too. I don't see the specif= ic case for it. It kinda fits as a persistent search mechanism.=20 I agree we need to focus the draft to move it forward.=20 Phil > On May 27, 2015, at 15:58, Haavar Valeur wrote:= >=20 > Hi Phil. > I=E2=80=99d be interested in working on this. I have a few uses cases wher= e I might be able to apply SCIM notifications. >=20 > One comment I would like to make off the bat is that we should consider di= vorcing the transport and message format. I think the barrier of entry of ad= opting the message format, while using existing transports in the infrastruc= ture, is relatively low. There is value in switching the underlaying transpo= rt, but it should not be a strict requirement. >=20 > Best > Haavar >=20 >=20 >> On Mar 8, 2015, at 4:32 PM, Phil Hunt wrote: >>=20 >> On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an i= ndividual draft contribution for comments and consideration. The draft is av= ailable here: >> https://tools.ietf.org/html/draft-hunt-scim-notify-00 >>=20 >> The draft follows up from the presentation made at IETF91 in Honolulu and= defines SCIM events and messages used to notify subscribers of events from a= publishing service provider via a distribution service known as a notificat= ion hub. The hub should have the capability to deliver event messages secur= ely via simple HTTP POST, WebPUSH, and other messaging protocols where usefu= l. =20 >>=20 >> I would like to request that we add this as a discussion item for the Dal= las agenda. >>=20 >> At the meeting I propose we discuss: >>=20 >> 1. What are the intended benefits and uses for Notify in SCIM environmen= ts >> 2. What are the scalability, information, and technical problems being a= ddressed >> 3. What is left to define >> and finally, >> 4. Is there enough interest in the working group to add Notify to the SC= IM charter. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYy= KRBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6= _-9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-FC9D4D09-68C0-4C1F-80C3-3C1D2854A5AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the feed back. 
<= div>
I agree we should narrow down where possible. 
=

Would like to see a single publish method but I can see n= eed for multiple delivery methods. 

Scale and d= iversity are issues. Eg major cloud sp to major cloud sp is different from s= ecure mobile events. 

There was a lot of press= ure to consider web push too. I don't see the specific case for it. It kinda= fits as a persistent search mechanism. 

I agr= ee we need to focus the draft to move it forward. 

Phil

On May 27, 2015, at 15:58, Haavar Valeur <haavar.valeur@citrix.com> wrote:

Hi Phil.
I=E2=80=99d be interested in working on this. I have a few u= ses cases where I might be able to apply SCIM notifications.

One comment I would like to make off the bat is that we shou= ld consider divorcing the transport and message format. I think the barrier o= f entry of adopting the message format, while using existing transports in t= he infrastructure, is relatively low. There is value in switching the underlaying transport, but it should n= ot be a strict requirement.

Best
Haavar


On Mar 8, 2015, at 4:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an ind= ividual draft contribution for comments and consideration. The draft is avai= lable here:
https://tools.ietf.org/html/draft-hunt-scim-notify-00

The draft follows up from the presentation made at IETF91 in= Honolulu and defines SCIM events and messages used to notify subscribers of= events from a publishing service provider via a distribution service known a= s a notification hub.  The hub should have the capability to deliver event messages securely via simple HT= TP POST, WebPUSH, and other messaging protocols where useful.  

I would like to request that we add this as a discussion ite= m for the Dallas agenda.

At the meeting I propose we discuss:

1.  What are the intended benefits and uses for Notify i= n SCIM environments
2.  What are the scalability, information, and technica= l problems being addressed
3.  What is left to define
and finally,
4.  Is there enough interest in the working group to ad= d Notify to the SCIM charter.

Phil

@independentid
www.inde= pendentid.com
phil.hunt@oracle.c= om

_______________________________________________
scim mailing list
scim@ietf.org
= https://secure-web.cisco.com/1W2BR0= G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKRBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pOb= e-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD= 5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-FC9D4D09-68C0-4C1F-80C3-3C1D2854A5AA-- From nobody Wed May 27 17:20:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AB61B2B02 for ; Wed, 27 May 2015 17:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e2jAQk2Dzzc for ; Wed, 27 May 2015 17:20:21 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF93D1B2B0C for ; Wed, 27 May 2015 17:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1432772421; x=1433982021; h=from:to:subject:date:message-id:mime-version; bh=FZvGNPjbDeWEk621MUdbqORKIpi03sEaFEBC3nQP1NU=; b=ARjhx36UoBIF52CxlWfBJ0DzOWJR5zruNaVrRVbOkUXJOx1T3IwDNdPR 9gL14jTXnAp0yyncl3ARuHJkXNj543p7rD0r1chqmBsW+B2JJfs730Lyr bLQ9TS+aHXA4oPVlqrZHpvqZwzFSC/hoYbgqu+pm0UTnhrtKH2owgt5js g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnBAAKX2ZV/5FdJa1cgkVLgTjAfGYJiRY4FAEBAQEBAQGBCoQZEIELAQsBdCcEiECfKLNsAQEIAQEBAR6UcwWTCIsPgSmDcYJ/iz2DWSNhgxeCNYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,509,1427760000"; d="scan'208,217";a="153983895" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 28 May 2015 00:20:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4S0KDjC009542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 May 2015 00:20:13 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 27 May 2015 19:20:13 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: SCIM extensions... Thread-Index: AQHQmNwQfbcKziUGq0W5l2LbqN412g== Date: Thu, 28 May 2015 00:20:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.84.181] Content-Type: multipart/alternative; boundary="_000_D18BAD4D126280moransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: [scim] SCIM extensions... X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 00:20:23 -0000 --_000_D18BAD4D126280moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Now that the flurry of reviews/feedback/revisions to the core docs are sett= led (many many thanks to Phil for fronting a lot of those and turning aroun= d revisions after revisions), I think it is time to look at some of the ext= ensions that was proposed. This is a perfect opportunity for the WG to sta= rt thinking about next steps. Please review the slides from the Dallas meeting, read the drafts and send = your feedback/suggestions to the group. And if you have other ideas you li= ke to propose, please do so. Cheers, Morteza --_000_D18BAD4D126280moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <48CD58DAD209B74AA237CB58DF01AD7D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

Now that the flurry of reviews/feedback/revisions to the core docs are= settled (many many thanks to Phil for fronting a lot of those and turning = around revisions after revisions), I think it is time to look at some of th= e extensions that was proposed.  This is a perfect opportunity for the WG to start thinking about nex= t steps.

Please review the slides from the Dallas meeting, read the drafts and = send your feedback/suggestions to the group.  And if you have other id= eas you like to propose, please do so. 


Cheers,
Morteza
--_000_D18BAD4D126280moransarciscocom_-- From nobody Thu May 28 09:13:45 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B61B2C25 for ; Thu, 28 May 2015 09:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeeuENawyGqz for ; Thu, 28 May 2015 09:13:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB4B1B2C3C for ; Thu, 28 May 2015 09:13:34 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4SGDXH4015663 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 May 2015 16:13:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4SGDXPk026328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2015 16:13:33 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4SGDX5V014001; Thu, 28 May 2015 16:13:33 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 May 2015 09:13:33 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-6F5916DA-AB34-484C-B512-4234A5C5C2CC Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Thu, 28 May 2015 09:13:31 -0700 References: <20150528160549.20022.76577.idtracker@ietfa.amsl.com> To: HTTP Working Group X-Mailer: iPhone Mail (12F70) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: SCIM WG Subject: [scim] Fwd: New Version Notification for draft-hunt-scim-search-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:13:43 -0000 --Apple-Mail-6F5916DA-AB34-484C-B512-4234A5C5C2CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable As proposed, here is a draft profiling SCIM using the proposed draft for HTT= P SEARCH.=20 This is not a high priority for SCIM, but I thought it would add value to th= e HTTP discussions happening now.=20 SCIM is a good use case because you can see SCIM has already had to use both= GET and POST for searching.=20 In a future world I believe the core scim specs could have been simpler with= a http search method.=20 Also adding to the discussion in the draft is the notion of stored queries a= nd the relationship with SEARCH.=20 Phil Begin forwarded message: > From: internet-drafts@ietf.org > Date: May 28, 2015 at 09:05:49 PDT > To: "Phil Hunt" , "Phil Hunt" > Subject: New Version Notification for draft-hunt-scim-search-00.txt >=20 >=20 > A new version of I-D, draft-hunt-scim-search-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-scim-search > Revision: 00 > Title: SCIM HTTP SEARCH Method Extension > Document date: 2015-05-28 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-hunt-scim-searc= h-00.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-scim-search/ > Htmlized: https://tools.ietf.org/html/draft-hunt-scim-search-00 >=20 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is an HTTP based protocol that makes managing identities in multi- > domain scenarios easier to support through a standardized service. > Examples include but are not limited to enterprise to cloud service > providers, and inter-cloud based scenarios. This specification > extends the SCIM Protocol to include support for HTTP SEARCH. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-6F5916DA-AB34-484C-B512-4234A5C5C2CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As proposed, here is a draft profiling= SCIM using the proposed draft for HTTP SEARCH. 

This is not a high priority for SCIM, but I thought it would add value to= the HTTP discussions happening now. 

SCIM is a= good use case because you can see SCIM has already had to use both GET and P= OST for searching. 

In a future world I believ= e the core scim specs could have been simpler with a http search method.&nbs= p;

Also adding to the discussion in the draft is th= e notion of stored queries and the relationship with SEARCH. 

Phil

Begin forwarded message:

From: in= ternet-drafts@ietf.org
Date: May 28, 2015 at 09:05:49 PDT
<= b>To: "Phil Hunt" <phil.hunt@y= ahoo.com>, "Phil Hunt" <phi= l.hunt@yahoo.com>
Subject: New Version Notification for d= raft-hunt-scim-search-00.txt


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

Name:        draft-hunt-scim-search
R= evision:    00
Title:        S= CIM HTTP SEARCH Method Extension
Document date:    = ;2015-05-28
Group:        Individual Sub= mission
Pages:        13
URL:            h= ttps://www.ietf.org/internet-drafts/draft-hunt-scim-search-00.txt=
Status:         https://datatrack= er.ietf.org/doc/draft-hunt-scim-search/
Htmlized:  =      https://tools.ietf.org/html/draft-hunt-scim-search-00


Abstract:
  The System for Cross-Domain Identity Management (SCIM) specif= ication
  is an HTTP based protocol that makes ma= naging identities in multi-
  domain scenarios ea= sier to support through a standardized service.
  = ;Examples include but are not limited to enterprise to cloud service<= br>   providers, and inter-cloud based scenarios.  This= specification
  extends the SCIM Protocol to inc= lude support for HTTP SEARCH.




Please note that it may take a couple o= f minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.= org.

The IETF Secretariat

= --Apple-Mail-6F5916DA-AB34-484C-B512-4234A5C5C2CC-- From nobody Thu May 28 14:47:10 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CEA1A9072 for ; Thu, 28 May 2015 14:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1QeaSpU87Wo for ; Thu, 28 May 2015 14:47:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11711A88C6 for ; Thu, 28 May 2015 14:47:07 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 21:47:06 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0172.012; Thu, 28 May 2015 21:47:05 +0000 From: Anthony Nadalin To: Phil Hunt , Haavar Valeur Thread-Topic: [scim] SCIM Notify Draft Thread-Index: AQHQWfg8RNmYGnLmgkadFgriRpU2rp2Q7U0AgAAD9ICAAXos0A== Date: Thu, 28 May 2015 21:47:05 +0000 Message-ID: References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> In-Reply-To: <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 3:5zBGwuzRv9jBxN+yoOdbXiMIRTbTi+6fYorzJ4Iac1NAzPLAX5HaQD0T0Ti1yPB4+AhvV2RCrHZE1YeY9v1vyh5tq3peEMni7XrGuW24OPuBRHnPgg4meT1b04QR14tkLsHKTVfPvYqR3v+jdR5vxw==; 10:YYWqNQ9a+HznZ233d7RkSuYAefQiVthcBYD1a8DR7YeOfNSl53YFdbkxYvUj8YUsf/83VzhoIlWfSEvpPTyRJ/sfQwLMqW+pLnbXNrGoGj0=; 6:Llet0dXIOuNqDWZNDvNEQZuDJQlpEjLkbpmaNJ+GQMCmBaqqpkceu11cAa7Whq0q x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(189002)(24454002)(377454003)(199003)(50986999)(54356999)(33656002)(19580395003)(19580405001)(106116001)(64706001)(5001830100001)(189998001)(4001540100001)(5001960100002)(76576001)(76176999)(5001860100001)(101416001)(19609705001)(106356001)(16236675004)(16601075003)(74316001)(62966003)(92566002)(15975445007)(19617315012)(86362001)(77096005)(19300405004)(86612001)(2656002)(81156007)(77156002)(122556002)(87936001)(46102003)(97736004)(105586002)(5001770100001)(102836002)(40100003)(575784001)(2950100001)(99286002)(19625215002)(68736005)(5002640100001)(2900100001)(7059030)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234441DE99F8B459EEFEB54A6CA0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 21:47:05.7325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 21:47:10 -0000 --_000_BN3PR0301MB1234441DE99F8B459EEFEB54A6CA0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQgYnV0IGRpZCB5b3UgaW50ZW5kIHRvIGFsbG93IGZv ciBlcnJvciBjb25kaXRpb24gbm90aWZpY2F0aW9uID8NCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNj aW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVz ZGF5LCBNYXkgMjcsIDIwMTUgNDoxMiBQTQ0KVG86IEhhYXZhciBWYWxldXINCkNjOiBTQ0lNIFdH DQpTdWJqZWN0OiBSZTogW3NjaW1dIFNDSU0gTm90aWZ5IERyYWZ0DQoNClRoYW5rcyBmb3IgdGhl IGZlZWQgYmFjay4NCg0KSSBhZ3JlZSB3ZSBzaG91bGQgbmFycm93IGRvd24gd2hlcmUgcG9zc2li bGUuDQoNCldvdWxkIGxpa2UgdG8gc2VlIGEgc2luZ2xlIHB1Ymxpc2ggbWV0aG9kIGJ1dCBJIGNh biBzZWUgbmVlZCBmb3IgbXVsdGlwbGUgZGVsaXZlcnkgbWV0aG9kcy4NCg0KU2NhbGUgYW5kIGRp dmVyc2l0eSBhcmUgaXNzdWVzLiBFZyBtYWpvciBjbG91ZCBzcCB0byBtYWpvciBjbG91ZCBzcCBp cyBkaWZmZXJlbnQgZnJvbSBzZWN1cmUgbW9iaWxlIGV2ZW50cy4NCg0KVGhlcmUgd2FzIGEgbG90 IG9mIHByZXNzdXJlIHRvIGNvbnNpZGVyIHdlYiBwdXNoIHRvby4gSSBkb24ndCBzZWUgdGhlIHNw ZWNpZmljIGNhc2UgZm9yIGl0LiBJdCBraW5kYSBmaXRzIGFzIGEgcGVyc2lzdGVudCBzZWFyY2gg bWVjaGFuaXNtLg0KDQpJIGFncmVlIHdlIG5lZWQgdG8gZm9jdXMgdGhlIGRyYWZ0IHRvIG1vdmUg aXQgZm9yd2FyZC4NCg0KUGhpbA0KDQpPbiBNYXkgMjcsIDIwMTUsIGF0IDE1OjU4LCBIYWF2YXIg VmFsZXVyIDxoYWF2YXIudmFsZXVyQGNpdHJpeC5jb208bWFpbHRvOmhhYXZhci52YWxldXJAY2l0 cml4LmNvbT4+IHdyb3RlOg0KSGkgUGhpbC4NCknigJlkIGJlIGludGVyZXN0ZWQgaW4gd29ya2lu ZyBvbiB0aGlzLiBJIGhhdmUgYSBmZXcgdXNlcyBjYXNlcyB3aGVyZSBJIG1pZ2h0IGJlIGFibGUg dG8gYXBwbHkgU0NJTSBub3RpZmljYXRpb25zLg0KDQpPbmUgY29tbWVudCBJIHdvdWxkIGxpa2Ug dG8gbWFrZSBvZmYgdGhlIGJhdCBpcyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBkaXZvcmNpbmcg dGhlIHRyYW5zcG9ydCBhbmQgbWVzc2FnZSBmb3JtYXQuIEkgdGhpbmsgdGhlIGJhcnJpZXIgb2Yg ZW50cnkgb2YgYWRvcHRpbmcgdGhlIG1lc3NhZ2UgZm9ybWF0LCB3aGlsZSB1c2luZyBleGlzdGlu ZyB0cmFuc3BvcnRzIGluIHRoZSBpbmZyYXN0cnVjdHVyZSwgaXMgcmVsYXRpdmVseSBsb3cuIFRo ZXJlIGlzIHZhbHVlIGluIHN3aXRjaGluZyB0aGUgdW5kZXJsYXlpbmcgdHJhbnNwb3J0LCBidXQg aXQgc2hvdWxkIG5vdCBiZSBhIHN0cmljdCByZXF1aXJlbWVudC4NCg0KQmVzdA0KSGFhdmFyDQoN Cg0KT24gTWFyIDgsIDIwMTUsIGF0IDQ6MzIgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk9uIGJlaGFsZiBv ZiBJYW4gR2xhemVyLCBNb3J0ZXphIEFuc2FyaSwgYW5kIG15c2VsZiwgSSBoYXZlIHN1Ym1pdHRl ZCBhbiBpbmRpdmlkdWFsIGRyYWZ0IGNvbnRyaWJ1dGlvbiBmb3IgY29tbWVudHMgYW5kIGNvbnNp ZGVyYXRpb24uIFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tbm90aWZ5LTAwDQoNClRoZSBkcmFmdCBmb2xsb3dz IHVwIGZyb20gdGhlIHByZXNlbnRhdGlvbiBtYWRlIGF0IElFVEY5MSBpbiBIb25vbHVsdSBhbmQg ZGVmaW5lcyBTQ0lNIGV2ZW50cyBhbmQgbWVzc2FnZXMgdXNlZCB0byBub3RpZnkgc3Vic2NyaWJl cnMgb2YgZXZlbnRzIGZyb20gYSBwdWJsaXNoaW5nIHNlcnZpY2UgcHJvdmlkZXIgdmlhIGEgZGlz dHJpYnV0aW9uIHNlcnZpY2Uga25vd24gYXMgYSBub3RpZmljYXRpb24gaHViLiAgVGhlIGh1YiBz aG91bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBkZWxpdmVyIGV2ZW50IG1lc3NhZ2VzIHNlY3Vy ZWx5IHZpYSBzaW1wbGUgSFRUUCBQT1NULCBXZWJQVVNILCBhbmQgb3RoZXIgbWVzc2FnaW5nIHBy b3RvY29scyB3aGVyZSB1c2VmdWwuDQoNCkkgd291bGQgbGlrZSB0byByZXF1ZXN0IHRoYXQgd2Ug YWRkIHRoaXMgYXMgYSBkaXNjdXNzaW9uIGl0ZW0gZm9yIHRoZSBEYWxsYXMgYWdlbmRhLg0KDQpB dCB0aGUgbWVldGluZyBJIHByb3Bvc2Ugd2UgZGlzY3VzczoNCg0KMS4gIFdoYXQgYXJlIHRoZSBp bnRlbmRlZCBiZW5lZml0cyBhbmQgdXNlcyBmb3IgTm90aWZ5IGluIFNDSU0gZW52aXJvbm1lbnRz DQoyLiAgV2hhdCBhcmUgdGhlIHNjYWxhYmlsaXR5LCBpbmZvcm1hdGlvbiwgYW5kIHRlY2huaWNh bCBwcm9ibGVtcyBiZWluZyBhZGRyZXNzZWQNCjMuICBXaGF0IGlzIGxlZnQgdG8gZGVmaW5lDQph bmQgZmluYWxseSwNCjQuICBJcyB0aGVyZSBlbm91Z2ggaW50ZXJlc3QgaW4gdGhlIHdvcmtpbmcg Z3JvdXAgdG8gYWRkIE5vdGlmeSB0byB0aGUgU0NJTSBjaGFydGVyLg0KDQpQaGlsDQoNCkBpbmRl cGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0g bWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6 Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xVzJCUjBHM0xsOXBzY1hsWlJVb0xYZVBRZFpVZE5PTW9t QV9VRDRVYUlZeUtSQmtFeXdKSmhYMnNtaUc1aEJCTW5OalVoellVd2ZOVEg2cE9iZS1FODRoRDM1 cXNnU2hXVnFSYlRNdzhtS0dlNHNfZEswVVNBcDZfLTlvdnF2azBubFF0ZG5tdkd0Z1dXckVMOTZD MXI5cGd5ai1RRDVsLXNDRVNQbUE5TXpJL2h0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGc2NpbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRv OnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nj aW0NCg== --_000_BN3PR0301MB1234441DE99F8B459EEFEB54A6CA0BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IG1lbnRpb25lZCBpbiB0aGUgZHJh ZnQgYnV0IGRpZCB5b3UgaW50ZW5kIHRvIGFsbG93IGZvciBlcnJvciBjb25kaXRpb24gbm90aWZp Y2F0aW9uID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIE1heSAyNywgMjAxNSA0OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBIYWF2YXIgVmFsZXVy PGJyPg0KPGI+Q2M6PC9iPiBTQ0lNIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0g U0NJTSBOb3RpZnkgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZmVlZCBiYWNrLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdlIHNo b3VsZCBuYXJyb3cgZG93biB3aGVyZSBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgbGlrZSB0byBzZWUgYSBz aW5nbGUgcHVibGlzaCBtZXRob2QgYnV0IEkgY2FuIHNlZSBuZWVkIGZvciBtdWx0aXBsZSBkZWxp dmVyeSBtZXRob2RzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TY2FsZSBhbmQgZGl2ZXJzaXR5IGFyZSBpc3N1ZXMuIEVnIG1ham9y IGNsb3VkIHNwIHRvIG1ham9yIGNsb3VkIHNwIGlzIGRpZmZlcmVudCBmcm9tIHNlY3VyZSBtb2Jp bGUgZXZlbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVyZSB3YXMgYSBsb3Qgb2YgcHJlc3N1cmUgdG8gY29uc2lkZXIgd2Vi IHB1c2ggdG9vLiBJIGRvbid0IHNlZSB0aGUgc3BlY2lmaWMgY2FzZSBmb3IgaXQuIEl0IGtpbmRh IGZpdHMgYXMgYSBwZXJzaXN0ZW50IHNlYXJjaCBtZWNoYW5pc20uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2UgbmVl ZCB0byBmb2N1cyB0aGUgZHJhZnQgdG8gbW92ZSBpdCBmb3J3YXJkLiZuYnNwOzxicj4NCjxicj4N ClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDI3LCAyMDE1LCBhdCAx NTo1OCwgSGFhdmFyIFZhbGV1ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhYXZhci52YWxldXJAY2l0 cml4LmNvbSI+aGFhdmFyLnZhbGV1ckBjaXRyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFBoaWwuIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlkIGJlIGludGVy ZXN0ZWQgaW4gd29ya2luZyBvbiB0aGlzLiBJIGhhdmUgYSBmZXcgdXNlcyBjYXNlcyB3aGVyZSBJ IG1pZ2h0IGJlIGFibGUgdG8gYXBwbHkgU0NJTSBub3RpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY29tbWVudCBJIHdv dWxkIGxpa2UgdG8gbWFrZSBvZmYgdGhlIGJhdCBpcyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciBk aXZvcmNpbmcgdGhlIHRyYW5zcG9ydCBhbmQgbWVzc2FnZSBmb3JtYXQuIEkgdGhpbmsgdGhlIGJh cnJpZXIgb2YgZW50cnkgb2YgYWRvcHRpbmcgdGhlIG1lc3NhZ2UgZm9ybWF0LCB3aGlsZSB1c2lu ZyBleGlzdGluZyB0cmFuc3BvcnRzIGluIHRoZSBpbmZyYXN0cnVjdHVyZSwgaXMgcmVsYXRpdmVs eQ0KIGxvdy4gVGhlcmUgaXMgdmFsdWUgaW4gc3dpdGNoaW5nIHRoZSB1bmRlcmxheWluZyB0cmFu c3BvcnQsIGJ1dCBpdCBzaG91bGQgbm90IGJlIGEgc3RyaWN0IHJlcXVpcmVtZW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYWF2YXI8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1hciA4LCAyMDE1LCBhdCA0OjMyIFBNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIGJl aGFsZiBvZiBJYW4gR2xhemVyLCBNb3J0ZXphIEFuc2FyaSwgYW5kIG15c2VsZiwgSSBoYXZlIHN1 Ym1pdHRlZCBhbiBpbmRpdmlkdWFsIGRyYWZ0IGNvbnRyaWJ1dGlvbiBmb3IgY29tbWVudHMgYW5k IGNvbnNpZGVyYXRpb24uIFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tbm90aWZ5LTAwIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaHVudC1zY2ltLW5vdGlmeS0wMDwvYT48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBmb2xsb3dzIHVwIGZyb20g dGhlIHByZXNlbnRhdGlvbiBtYWRlIGF0IElFVEY5MSBpbiBIb25vbHVsdSBhbmQgZGVmaW5lcyBT Q0lNIGV2ZW50cyBhbmQgbWVzc2FnZXMgdXNlZCB0byBub3RpZnkgc3Vic2NyaWJlcnMgb2YgZXZl bnRzIGZyb20gYSBwdWJsaXNoaW5nIHNlcnZpY2UgcHJvdmlkZXIgdmlhIGEgZGlzdHJpYnV0aW9u IHNlcnZpY2Uga25vd24gYXMgYSBub3RpZmljYXRpb24gaHViLiAmbmJzcDtUaGUNCiBodWIgc2hv dWxkIGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gZGVsaXZlciBldmVudCBtZXNzYWdlcyBzZWN1cmVs eSB2aWEgc2ltcGxlIEhUVFAgUE9TVCwgV2ViUFVTSCwgYW5kIG90aGVyIG1lc3NhZ2luZyBwcm90 b2NvbHMgd2hlcmUgdXNlZnVsLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdCB3ZSBh ZGQgdGhpcyBhcyBhIGRpc2N1c3Npb24gaXRlbSBmb3IgdGhlIERhbGxhcyBhZ2VuZGEuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBt ZWV0aW5nIEkgcHJvcG9zZSB3ZSBkaXNjdXNzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiAmbmJzcDtXaGF0IGFyZSB0aGUgaW50ZW5kZWQg YmVuZWZpdHMgYW5kIHVzZXMgZm9yIE5vdGlmeSBpbiBTQ0lNIGVudmlyb25tZW50czxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gJm5ic3A7V2hh dCBhcmUgdGhlIHNjYWxhYmlsaXR5LCBpbmZvcm1hdGlvbiwgYW5kIHRlY2huaWNhbCBwcm9ibGVt cyBiZWluZyBhZGRyZXNzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjMuICZuYnNwO1doYXQgaXMgbGVmdCB0byBkZWZpbmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBmaW5hbGx5LDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gJm5ic3A7 SXMgdGhlcmUgZW5vdWdoIGludGVyZXN0IGluIHRoZSB3b3JraW5nIGdyb3VwIHRvIGFkZCBOb3Rp ZnkgdG8gdGhlIFNDSU0gY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QGlu ZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVw ZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+ c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3NlY3VyZS13ZWIuY2lzY28u Y29tLzFXMkJSMEczTGw5cHNjWGxaUlVvTFhlUFFkWlVkTk9Nb21BX1VENFVhSVl5S1JCa0V5d0pK aFgyc21pRzVoQkJNbk5qVWh6WVV3Zk5USDZwT2JlLUU4NGhEMzVxc2dTaFdWcVJiVE13OG1LR2U0 c19kSzBVU0FwNl8tOW92cXZrMG5sUXRkbm12R3RnV1dyRUw5NkMxcjlwZ3lqLVFENWwtc0NFU1Bt QTlNekkvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz Y2ltIj5odHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFXMkJSMEczTGw5cHNjWGxaUlVvTFhl UFFkWlVkTk9Nb21BX1VENFVhSVl5S1JCa0V5d0pKaFgyc21pRzVoQkJNbk5qVWh6WVV3Zk5USDZw T2JlLUU4NGhEMzVxc2dTaFdWcVJiVE13OG1LR2U0c19kSzBVU0FwNl8tOW92cXZrMG5sUXRkbm12 R3RnV1dyRUw5NkMxcjlwZ3lqLVFENWwtc0NFU1BtQTlNekkvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1234441DE99F8B459EEFEB54A6CA0BN3PR0301MB1234_-- From nobody Thu May 28 15:11:28 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9AC1A86EE for ; Thu, 28 May 2015 15:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hy2bZMkzL6N for ; Thu, 28 May 2015 15:11:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475C61A1B88 for ; Thu, 28 May 2015 15:11:22 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4SMBKOt009827 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 May 2015 22:11:21 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4SMBKYP014051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2015 22:11:20 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4SMBK3U021023; Thu, 28 May 2015 22:11:20 GMT Received: from [10.0.1.27] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 May 2015 15:11:19 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_98A9AEFE-4B17-42CC-9B23-CF4D68829B35" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Thu, 28 May 2015 15:11:17 -0700 Message-Id: <0483B673-970B-415F-8F46-E264A638757B@oracle.com> References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 22:11:25 -0000 --Apple-Mail=_98A9AEFE-4B17-42CC-9B23-CF4D68829B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tony, Good question. Well, the idea of publishing =E2=80=9Cevents=E2=80=9D rather than = commands is to avoid errors being an issue. Consider the following cases: 1. A client that fails to make an update (it is rejected) at a = publishing service provider. In this case it is a non-event since = service provider state did not change. 2. An error that is an account condition (can be defined by a filter): = If the resource has certain state (e.g. account is disabled due to login = failures) then it just becomes a resource modification event does it = not? 3. Publisher / Subscriber State Inconsistency: The publisher is simply = telling the client what happened at the publisher. It is up to the = client to decide what it wants to do. If the client deems it an error, = it has to decide its own recovery or mapping. E.g. User Anne gets added to CRM_Users. An event goes to the CRM SaaS service indicating Anne is a member of = CRM_Users. The SaaS service provider receiving the event realizes it = has no account for =E2=80=9CAnne=E2=80=9D. It has to first go get Anne = from the publisher (SCIM GET) to create the account and then provision = Ann for CRM SaaS Or=E2=80=A6 were you thinking of something else? Phil @independentid www.independentid.com phil.hunt@oracle.com > On May 28, 2015, at 2:47 PM, Anthony Nadalin = wrote: >=20 > Not mentioned in the draft but did you intend to allow for error = condition notification ? > =C2=A0 <> > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, May 27, 2015 4:12 PM > To: Haavar Valeur > Cc: SCIM WG > Subject: Re: [scim] SCIM Notify Draft > =20 > Thanks for the feed back.=20 > =20 > I agree we should narrow down where possible.=20 > =20 > Would like to see a single publish method but I can see need for = multiple delivery methods.=20 > =20 > Scale and diversity are issues. Eg major cloud sp to major cloud sp is = different from secure mobile events.=20 > =20 > There was a lot of pressure to consider web push too. I don't see the = specific case for it. It kinda fits as a persistent search mechanism.=20 > =20 > I agree we need to focus the draft to move it forward.=20 >=20 > Phil >=20 > On May 27, 2015, at 15:58, Haavar Valeur > wrote: >=20 > Hi Phil. > I=E2=80=99d be interested in working on this. I have a few uses cases = where I might be able to apply SCIM notifications. > =20 > One comment I would like to make off the bat is that we should = consider divorcing the transport and message format. I think the barrier = of entry of adopting the message format, while using existing transports = in the infrastructure, is relatively low. There is value in switching = the underlaying transport, but it should not be a strict requirement. > =20 > Best > Haavar > =20 > =20 > On Mar 8, 2015, at 4:32 PM, Phil Hunt > wrote: > =20 > On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted = an individual draft contribution for comments and consideration. The = draft is available here: > https://tools.ietf.org/html/draft-hunt-scim-notify-00 = > =20 > The draft follows up from the presentation made at IETF91 in Honolulu = and defines SCIM events and messages used to notify subscribers of = events from a publishing service provider via a distribution service = known as a notification hub. The hub should have the capability to = deliver event messages securely via simple HTTP POST, WebPUSH, and other = messaging protocols where useful. =20 > =20 > I would like to request that we add this as a discussion item for the = Dallas agenda. > =20 > At the meeting I propose we discuss: > =20 > 1. What are the intended benefits and uses for Notify in SCIM = environments > 2. What are the scalability, information, and technical problems = being addressed > 3. What is left to define > and finally, > 4. Is there enough interest in the working group to add Notify to the = SCIM charter. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > = https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyK= RBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp= 6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fscim = > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = --Apple-Mail=_98A9AEFE-4B17-42CC-9B23-CF4D68829B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Tony,

Good question.

Well, the idea of publishing =E2=80=9Cevents=E2=80=9D = rather than commands is to avoid errors being an issue.
Consider the following cases:

1. A = client that fails to make an update (it is rejected) at a publishing = service provider. In this case it is a non-event since service provider = state did not change.

2. An error that is an account condition (can be defined by a = filter): If the resource has certain state (e.g. account is disabled due = to login failures) then it just becomes a resource modification event = does it not?

3. = Publisher / Subscriber State Inconsistency:  The publisher is = simply telling the client what happened at the publisher. It is up to = the client to decide what it wants to do. If the client deems it an = error, it has to decide its own recovery or mapping.

E.g.   User Anne = gets added to CRM_Users.

An event goes to the CRM SaaS service indicating Anne is a = member of CRM_Users.  The SaaS service provider receiving the event = realizes it has no account for =E2=80=9CAnne=E2=80=9D. It has to first = go get Anne from the publisher (SCIM GET) to create the account and then = provision Ann for CRM SaaS

Or=E2=80=A6 were you thinking of something else?


On May 28, 2015, at 2:47 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

Not mentioned in the draft but did you intend to = allow for error condition notification ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 27, 2015 4:12 PM
To: Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 

Thanks for the feed = back. 

 

I agree we should narrow down = where possible. 

 

Would like to see a single = publish method but I can see need for multiple delivery = methods. 

 

Scale and diversity are issues. = Eg major cloud sp to major cloud sp is different from secure mobile = events. 

 

There was a lot of pressure to = consider web push too. I don't see the specific case for it. It kinda = fits as a persistent search mechanism. 

 

I agree we need to focus the = draft to move it forward. 

Phil


On May 27, 2015, at 15:58, Haavar Valeur <haavar.valeur@citrix.com> wrote:

Hi Phil.

=

I=E2=80=99d be interested in = working on this. I have a few uses cases where I might be able to apply = SCIM notifications.

 

One comment I would like to make = off the bat is that we should consider divorcing the transport and = message format. I think the barrier of entry of adopting the message = format, while using existing transports in the infrastructure, is = relatively low. There is value in switching the underlaying transport, but it = should not be a strict requirement.

 

Best

Haavar

 

 

On Mar 8, 2015, at 4:32 PM, Phil = Hunt <phil.hunt@oracle.com> wrote:

 

On behalf of Ian Glazer, Morteza = Ansari, and myself, I have submitted an individual draft contribution = for comments and consideration. The draft is available here:

https://tools.ietf.org/html/draft-hunt-scim-notify-00

 

The draft follows up from the = presentation made at IETF91 in Honolulu and defines SCIM events and = messages used to notify subscribers of events from a publishing service = provider via a distribution service known as a notification hub. =  The hub should have the capability to deliver event messages securely via = simple HTTP POST, WebPUSH, and other messaging protocols where useful. =  

 

I would like to request that we = add this as a discussion item for the Dallas agenda.

 

At the meeting I propose we = discuss:

 

1.  What are the intended = benefits and uses for Notify in SCIM environments

2.  What are the = scalability, information, and technical problems being addressed

3.  What is left to = define

and finally,

4.  Is there enough interest = in the working group to add Notify to the SCIM charter.

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

_______________________________________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMom= A_UD4UaIYyKRBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKG= e4s_dK0USAp6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim

 

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


= --Apple-Mail=_98A9AEFE-4B17-42CC-9B23-CF4D68829B35-- From nobody Thu May 28 15:27:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ABD1A9167 for ; Thu, 28 May 2015 15:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxeUX92Ow_bv for ; Thu, 28 May 2015 15:27:27 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD43D1AC529 for ; Thu, 28 May 2015 15:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15394; q=dns/txt; s=iport; t=1432852036; x=1434061636; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QQ9W0qRRP8I9pHTHevswAvUc8v0P3dmhMHm8KdXhaOQ=; b=ItHObBYObmiou9YCuarQAYAzalBhvCnsgHv4HZ5OpF53wF6iWRhjhH1P 59IJ7G54qMIdIVivhRJAQhWDTxA4Enk9ow32CI+/dHqzHIv4zXC+akoXE dAs8jUvyJEwbCp1juhyj8XwfcMUoqdamFHeBzJH2aMp5QHUGKDz7y86eJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AABACglWdV/5xdJa1cgkVLVF4GvRBmCYFQAQaFegKBUTgUAQEBAQEBAYEKhCIBAQEEAQEBKhwlCxACAQgOAwMBAQEoBycLFAkIAgQBDQWILQ3VbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4R1DQEDBgEGA4QkBYVKgV2JJYI8hDWGWpcvI2GBBSQcgVJvAQGBRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208,217";a="154383488" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 28 May 2015 22:27:16 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4SMRFI7020195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 22:27:16 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 28 May 2015 17:27:15 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , Phil Hunt , Haavar Valeur Thread-Topic: [scim] SCIM Notify Draft Thread-Index: AQHQWfg7cHYeoZXXK0ShpUdWPA/+u52RQR4AgAAD9YCAAXp6gP//leGA Date: Thu, 28 May 2015 22:27:15 +0000 Message-ID: References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.42.132] Content-Type: multipart/alternative; boundary="_000_D18CE43C12656Amoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 22:27:29 -0000 --_000_D18CE43C12656Amoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Interesting question. I never thought of that. Do you have any specific use= case(s) in mind? Cheers, Morteza From: Anthony Nadalin > Date: Thursday, May 28, 2015 at 2:47 PM To: Phil Hunt >, Haavar V= aleur > Cc: "scim@ietf.org" > Subject: Re: [scim] SCIM Notify Draft Not mentioned in the draft but did you intend to allow for error condition = notification ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, May 27, 2015 4:12 PM To: Haavar Valeur Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft Thanks for the feed back. I agree we should narrow down where possible. Would like to see a single publish method but I can see need for multiple d= elivery methods. Scale and diversity are issues. Eg major cloud sp to major cloud sp is diff= erent from secure mobile events. There was a lot of pressure to consider web push too. I don't see the speci= fic case for it. It kinda fits as a persistent search mechanism. I agree we need to focus the draft to move it forward. Phil On May 27, 2015, at 15:58, Haavar Valeur > wrote: Hi Phil. I=92d be interested in working on this. I have a few uses cases where I mig= ht be able to apply SCIM notifications. One comment I would like to make off the bat is that we should consider div= orcing the transport and message format. I think the barrier of entry of ad= opting the message format, while using existing transports in the infrastru= cture, is relatively low. There is value in switching the underlaying trans= port, but it should not be a strict requirement. Best Haavar On Mar 8, 2015, at 4:32 PM, Phil Hunt > wrote: On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an in= dividual draft contribution for comments and consideration. The draft is av= ailable here: https://tools.ietf.org/html/draft-hunt-scim-notify-00 The draft follows up from the presentation made at IETF91 in Honolulu and d= efines SCIM events and messages used to notify subscribers of events from a= publishing service provider via a distribution service known as a notifica= tion hub. The hub should have the capability to deliver event messages sec= urely via simple HTTP POST, WebPUSH, and other messaging protocols where us= eful. I would like to request that we add this as a discussion item for the Dalla= s agenda. At the meeting I propose we discuss: 1. What are the intended benefits and uses for Notify in SCIM environments 2. What are the scalability, information, and technical problems being add= ressed 3. What is left to define and finally, 4. Is there enough interest in the working group to add Notify to the SCIM= charter. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKR= BkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_= -9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_D18CE43C12656Amoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Interesting question. I never thought of that. Do you have any specifi= c use case(s) in mind?


Cheers,
Morteza

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thursday, May 28, 2015 at 2:4= 7 PM
To: Phil Hunt <phil.hunt@oracle.com>, Haavar Valeur <haavar.valeur@citrix.com> Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] SCIM Notify Dra= ft

Not mentioned in the draft but did = you intend to allow for error condition notification ?

&n= bsp;

From: scim [m= ailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 27, 2015 4:12 PM
To: Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 

Thanks for the feed back. 

 

I agree we should narrow down where possible. <= o:p>

 

Would like to see a single publish method but I can = see need for multiple delivery methods. 

 

Scale and diversity are issues. Eg major cloud sp to= major cloud sp is different from secure mobile events. 

 

There was a lot of pressure to consider web push too= . I don't see the specific case for it. It kinda fits as a persistent searc= h mechanism. 

 

I agree we need to focus the draft to move it forwar= d. 

Phil


On May 27, 2015, at 15:58, Haavar Valeur <haavar.valeur@citrix.com> wrote:

Hi Phil.

I=92d be interested in working on this. I have a few= uses cases where I might be able to apply SCIM notifications.

 

One comment I would like to make off the bat is that= we should consider divorcing the transport and message format. I think the= barrier of entry of adopting the message format, while using existing tran= sports in the infrastructure, is relatively low. There is value in switching the underlaying transport, but it should = not be a strict requirement.

 

Best

Haavar

 

 

On Mar 8, 2015, at 4:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

On behalf of Ian Glazer, Morteza Ansari, and myself,= I have submitted an individual draft contribution for comments and conside= ration. The draft is available here:

https://tools.ietf.org/html/draft-hunt-scim-notify-00

 

The draft follows up from the presentation made at I= ETF91 in Honolulu and defines SCIM events and messages used to notify subsc= ribers of events from a publishing service provider via a distribution serv= ice known as a notification hub.  The hub should have the capability to deliver event messages securely via simp= le HTTP POST, WebPUSH, and other messaging protocols where useful.  

 

I would like to request that we add this as a discus= sion item for the Dallas agenda.

 

At the meeting I propose we discuss:

 

1.  What are the intended benefits and uses for= Notify in SCIM environments

2.  What are the scalability, information, and = technical problems being addressed

3.  What is left to define

and finally,

4.  Is there enough interest in the working gro= up to add Notify to the SCIM charter.

 

Phil

 

@independentid

= phil.hunt@oracle.com=

 

_______________________________________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1W= 2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKRBkEywJJhX2smiG5hBBMnNjUhzYUwfNT= H6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9p= gyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim=

 

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

 --_000_D18CE43C12656Amoransarciscocom_-- From nobody Thu May 28 15:41:13 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB71ACC8A for ; Thu, 28 May 2015 15:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU2OtTxukpdQ for ; Thu, 28 May 2015 15:41:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A6D1AC44C for ; Thu, 28 May 2015 15:41:07 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 22:41:04 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0172.012; Thu, 28 May 2015 22:41:05 +0000 From: Anthony Nadalin To: "Morteza Ansari (moransar)" , Phil Hunt , Haavar Valeur Thread-Topic: [scim] SCIM Notify Draft Thread-Index: AQHQWfg8RNmYGnLmgkadFgriRpU2rp2Q7U0AgAAD9ICAAXos0IAAC4iAgAACSxA= Date: Thu, 28 May 2015 22:41:04 +0000 Message-ID: References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 3:3qQa8Lv7x8mhtxuFNcLh1iRbpo3LG5k6T1pCOzrzIRMk9F4DOoY/BVqtuBS8Vm/bnZDlFRw9QAzyzfZMfuZ3Dz7P2Bc8b3KzPZv1E24weuzML9gvH1/Ou2PFkZ43VFW0lvHkdnGWtu+d3kloRkl0YQ==; 10:a7CGDk5y5zhNyqVUDLV71ouDem9pmP9j4FADwGxme4oH2sTDH5ELHzZu8RiGZyZkt+MqUivb1+fVMJh8g+MuHCn78pvKAxj7bxreGpNDGCU=; 6:zPARoI1PBK7HowjzLKvFZb9a2p53ANthL+XYiTqxerVTM97R5nSqtO5RindT0H52 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BN3PR0301MB1235; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(24454002)(51914003)(2900100001)(74316001)(19300405004)(2656002)(87936001)(19580405001)(40100003)(4001540100001)(64706001)(584604001)(86362001)(33656002)(86612001)(19617315012)(81156007)(97736004)(5001830100001)(77156002)(19580395003)(575784001)(50986999)(101416001)(106356001)(122556002)(102836002)(16601075003)(19609705001)(92566002)(46102003)(54356999)(189998001)(93886004)(106116001)(77096005)(76176999)(105586002)(16236675004)(68736005)(15975445007)(99286002)(5001860100001)(76576001)(2950100001)(5001920100001)(5001770100001)(5001960100002)(19625215002)(5002640100001)(62966003)(7059030)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234CAFE50E6B8D4D2C341DFA6CA0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 22:41:04.7369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 22:41:12 -0000 --_000_BN3PR0301MB1234CAFE50E6B8D4D2C341DFA6CA0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not all these operations have to/can be be atomic so was thinking about the= case where it was not atomic but wanted the listeners to know that a CREAT= E was in progress (to reserve that entry), but this might fail later From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Thursday, May 28, 2015 3:27 PM To: Anthony Nadalin; Phil Hunt; Haavar Valeur Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft Interesting question. I never thought of that. Do you have any specific use= case(s) in mind? Cheers, Morteza From: Anthony Nadalin > Date: Thursday, May 28, 2015 at 2:47 PM To: Phil Hunt >, Haavar V= aleur > Cc: "scim@ietf.org" > Subject: Re: [scim] SCIM Notify Draft Not mentioned in the draft but did you intend to allow for error condition = notification ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, May 27, 2015 4:12 PM To: Haavar Valeur Cc: SCIM WG Subject: Re: [scim] SCIM Notify Draft Thanks for the feed back. I agree we should narrow down where possible. Would like to see a single publish method but I can see need for multiple d= elivery methods. Scale and diversity are issues. Eg major cloud sp to major cloud sp is diff= erent from secure mobile events. There was a lot of pressure to consider web push too. I don't see the speci= fic case for it. It kinda fits as a persistent search mechanism. I agree we need to focus the draft to move it forward. Phil On May 27, 2015, at 15:58, Haavar Valeur > wrot Hi Phil. I'd be interested in working on this. I have a few uses cases where I might= be able to apply SCIM notifications. One comment I would like to make off the bat is that we should consider div= orcing the transport and message format. I think the barrier of entry of ad= opting the message format, while using existing transports in the infrastru= cture, is relatively low. There is value in switching the underlaying trans= port, but it should not be a strict requirement. Best Haavar On Mar 8, 2015, at 4:32 PM, Phil Hunt > wrote: On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an in= dividual draft contribution for comments and consideration. The draft is av= ailable here: https://tools.ietf.org/html/draft-hunt-scim-notify-00 The draft follows up from the presentation made at IETF91 in Honolulu and d= efines SCIM events and messages used to notify subscribers of events from a= publishing service provider via a distribution service known as a notifica= tion hub. The hub should have the capability to deliver event messages sec= urely via simple HTTP POST, WebPUSH, and other messaging protocols where us= eful. I would like to request that we add this as a discussion item for the Dalla= s agenda. At the meeting I propose we discuss: 1. What are the intended benefits and uses for Notify in SCIM environments 2. What are the scalability, information, and technical problems being add= ressed 3. What is left to define and finally, 4. Is there enough interest in the working group to add Notify to the SCIM= charter. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKR= BkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_= -9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BN3PR0301MB1234CAFE50E6B8D4D2C341DFA6CA0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not all these operations have to/can = be be atomic so was thinking about the case where it was not atomic but wan= ted the listeners to know that a CREATE was in progress (to reserve that entry), but this might fail later

&nbs= p;

From: Morteza Ansari (moransar) [mai= lto:moransar@cisco.com]
Sent: Thursday, May 28, 2015 3:27 PM
To: Anthony Nadalin; Phil Hunt; Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 

Interesting question. I never thought o= f that. Do you have any specific use case(s) in mind?

 

 

Cheers,

Morteza

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thursday, May 28, 2015 at 2:47 PM
To: Phil Hunt <phil.hunt@= oracle.com>, Haavar Valeur <haavar.valeur@citrix.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] SCIM Notify Draft

 

Not mentioned in the draft but did yo= u intend to allow for error condition notification ?

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 27, 2015 4:12 PM
To: Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 =

Thanks for the feed back= . 

 =

I agree we should narrow= down where possible. 

 =

Would like to see a sing= le publish method but I can see need for multiple delivery methods. 

 =

Scale and diversity are = issues. Eg major cloud sp to major cloud sp is different from secure mobile= events. 

 =

There was a lot of press= ure to consider web push too. I don't see the specific case for it. It kind= a fits as a persistent search mechanism. 

 =

I agree we need to focus= the draft to move it forward. 

Phil


On May 27, 2015, at 15:58, Haavar Valeur <haavar.valeur@citrix.com> wrot

Hi Phil.

I’d be interested = in working on this. I have a few uses cases where I might be able to apply = SCIM notifications.

 =

One comment I would like= to make off the bat is that we should consider divorcing the transport and= message format. I think the barrier of entry of adopting the message forma= t, while using existing transports in the infrastructure, is relatively low. There is value in switching the und= erlaying transport, but it should not be a strict requirement.

 =

Best

Haavar=

 =

 =

On Mar 8, 2015, at 4:32 = PM, Phil Hunt <phil.hunt@oracle.= com> wrote:

 =

On behalf of Ian Glazer,= Morteza Ansari, and myself, I have submitted an individual draft contribut= ion for comments and consideration. The draft is available here:

https://tools.ietf.org/html/draft= -hunt-scim-notify-00

 =

The draft follows up fro= m the presentation made at IETF91 in Honolulu and defines SCIM events and m= essages used to notify subscribers of events from a publishing service prov= ider via a distribution service known as a notification hub.  The hub should have the capability to deliver= event messages securely via simple HTTP POST, WebPUSH, and other messaging= protocols where useful.  

 =

I would like to request = that we add this as a discussion item for the Dallas agenda.

 =

At the meeting I propose= we discuss:

 =

1.  What are the in= tended benefits and uses for Notify in SCIM environments<= /p>

2.  What are the sc= alability, information, and technical problems being addressed

3.  What is left to= define

and finally,<= /span>

4.  Is there enough= interest in the working group to add Notify to the SCIM charter.

 =

Phil

 

@independentid

phil.hunt@orac= le.com

 =

________________________= _______________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1W= 2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKRBkEywJJhX2smiG5hBBMnNjUhzYUwfNT= H6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9p= gyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim=

 =

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

--_000_BN3PR0301MB1234CAFE50E6B8D4D2C341DFA6CA0BN3PR0301MB1234_-- From nobody Thu May 28 15:48:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0B1ACCEC for ; Thu, 28 May 2015 15:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVU9xRcbgrdw for ; Thu, 28 May 2015 15:48:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A551AC44C for ; Thu, 28 May 2015 15:48:22 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4SMmIWJ022099 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 May 2015 22:48:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t4SMmIgv009585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2015 22:48:18 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4SMmISU029487; Thu, 28 May 2015 22:48:18 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 May 2015 15:48:17 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-6AFF6E92-BEB4-45C1-854A-84385BF3935E Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Thu, 28 May 2015 15:48:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <40991CC5-814E-4596-8ED1-35E713EAFBEC@oracle.com> References: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> <92C06156-AB92-4F5D-8A68-D852ED69E61E@citrix.com> <061C8FC6-9CA3-42AC-881A-CA9CADD7585E@oracle.com> To: Anthony Nadalin X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: SCIM WG , Haavar Valeur , "Morteza Ansari \(moransar\)" Subject: Re: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 22:48:25 -0000 --Apple-Mail-6AFF6E92-BEB4-45C1-854A-84385BF3935E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not sure if this matters if the event isn't published until commit.=20 Eg a bulk request that must roll back all items is not committed so it is a n= on event.=20 Maybe this is a higher level workflow error that is not atomic? Eg an initi= al account is created but never verified.=20 Phil > On May 28, 2015, at 15:41, Anthony Nadalin wrote: >=20 > Not all these operations have to/can be be atomic so was thinking about th= e case where it was not atomic but wanted the listeners to know that a CREAT= E was in progress (to reserve that entry), but this might fail later > =20 > From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]=20 > Sent: Thursday, May 28, 2015 3:27 PM > To: Anthony Nadalin; Phil Hunt; Haavar Valeur > Cc: SCIM WG > Subject: Re: [scim] SCIM Notify Draft > =20 > Interesting question. I never thought of that. Do you have any specific us= e case(s) in mind? > =20 > =20 > Cheers, > Morteza > =20 > From: Anthony Nadalin > Date: Thursday, May 28, 2015 at 2:47 PM > To: Phil Hunt , Haavar Valeur > Cc: "scim@ietf.org" > Subject: Re: [scim] SCIM Notify Draft > =20 > Not mentioned in the draft but did you intend to allow for error condition= notification ? > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Wednesday, May 27, 2015 4:12 PM > To: Haavar Valeur > Cc: SCIM WG > Subject: Re: [scim] SCIM Notify Draft > =20 > Thanks for the feed back.=20 > =20 > I agree we should narrow down where possible.=20 > =20 > Would like to see a single publish method but I can see need for multiple d= elivery methods.=20 > =20 > Scale and diversity are issues. Eg major cloud sp to major cloud sp is dif= ferent from secure mobile events.=20 > =20 > There was a lot of pressure to consider web push too. I don't see the spec= ific case for it. It kinda fits as a persistent search mechanism.=20 > =20 > I agree we need to focus the draft to move it forward.=20 >=20 > Phil >=20 > On May 27, 2015, at 15:58, Haavar Valeur wrot >=20 > Hi Phil. > I=E2=80=99d be interested in working on this. I have a few uses cases wher= e I might be able to apply SCIM notifications. > =20 > One comment I would like to make off the bat is that we should consider di= vorcing the transport and message format. I think the barrier of entry of ad= opting the message format, while using existing transports in the infrastruc= ture, is relatively low. There is value in switching the underlaying transpo= rt, but it should not be a strict requirement. > =20 > Best > Haavar > =20 > =20 > On Mar 8, 2015, at 4:32 PM, Phil Hunt wrote: > =20 > On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an i= ndividual draft contribution for comments and consideration. The draft is av= ailable here: > https://tools.ietf.org/html/draft-hunt-scim-notify-00 > =20 > The draft follows up from the presentation made at IETF91 in Honolulu and d= efines SCIM events and messages used to notify subscribers of events from a p= ublishing service provider via a distribution service known as a notificatio= n hub. The hub should have the capability to deliver event messages securel= y via simple HTTP POST, WebPUSH, and other messaging protocols where useful.= =20 > =20 > I would like to request that we add this as a discussion item for the Dall= as agenda. > =20 > At the meeting I propose we discuss: > =20 > 1. What are the intended benefits and uses for Notify in SCIM environment= s > 2. What are the scalability, information, and technical problems being ad= dressed > 3. What is left to define > and finally, > 4. Is there enough interest in the working group to add Notify to the SCI= M charter. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://secure-web.cisco.com/1W2BR0G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyK= RBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pObe-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_= -9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.o= rg%2Fmailman%2Flistinfo%2Fscim > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-6AFF6E92-BEB4-45C1-854A-84385BF3935E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not sure if this matters if the event i= sn't published until commit. 

Eg a bulk request that must roll b= ack all items is not committed so it is a non event. 

Maybe this is a higher level workflow error that is not atomic? &nbs= p;Eg an initial account is created but never verified. 

P= hil

On May 28, 2015, at 15:41, Anthony Nadalin <tonynad@microsoft.com> wrote:

=

Not all these operations have to/can be= be atomic so was thinking about the case where it was not atomic but wanted= the listeners to know that a CREATE was in progress (to reserve that entry), but this might fail later

 =

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Thursday, May 28, 2015 3:27 PM
To: Anthony Nadalin; Phil Hunt; Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 

Interesting question. I never thought of t= hat. Do you have any specific use case(s) in mind?

 

 

Cheers,

Morteza

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thursday, May 28, 2015 at 2:47 PM
To: Phil Hunt <phil.hunt@o= racle.com>, Haavar Valeur <haavar.valeur@citrix.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM Notify Draft

 

Not mentioned in the draft but did you i= ntend to allow for error condition notification ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 27, 2015 4:12 PM
To: Haavar Valeur
Cc: SCIM WG
Subject: Re: [scim] SCIM Notify Draft

 <= /p>

Thanks for the feed back.=  

 <= /p>

I agree we should narrow d= own where possible. 

 <= /p>

Would like to see a singl= e publish method but I can see need for multiple delivery methods. 

 <= /p>

Scale and diversity are i= ssues. Eg major cloud sp to major cloud sp is different from secure mobile e= vents. 

 <= /p>

There was a lot of pressu= re to consider web push too. I don't see the specific case for it. It kinda f= its as a persistent search mechanism. 

 <= /p>

I agree we need to focus t= he draft to move it forward. 

Phil


On May 27, 2015, at 15:58, Haavar Valeur <haavar.valeur@citrix.com> wrot

Hi Phil.

I=E2=80=99d be interested= in working on this. I have a few uses cases where I might be able to apply S= CIM notifications.

 <= /p>

One comment I would like t= o make off the bat is that we should consider divorcing the transport and me= ssage format. I think the barrier of entry of adopting the message format, w= hile using existing transports in the infrastructure, is relatively low. There is value in switching the unde= rlaying transport, but it should not be a strict requirement.

 <= /p>

Best

Haavar<= /p>

 <= /p>

 <= /p>

On Mar 8, 2015, at 4:32 P= M, Phil Hunt <phil.hunt@oracle.co= m> wrote:

 <= /p>

On behalf of Ian Glazer, M= orteza Ansari, and myself, I have submitted an individual draft contribution= for comments and consideration. The draft is available here:

https://tools.ietf.org/html/draft-h= unt-scim-notify-00

 <= /p>

The draft follows up from= the presentation made at IETF91 in Honolulu and defines SCIM events and mes= sages used to notify subscribers of events from a publishing service provide= r via a distribution service known as a notification hub.  The hub should have the capability to deliver e= vent messages securely via simple HTTP POST, WebPUSH, and other messaging pr= otocols where useful.  

 <= /p>

I would like to request t= hat we add this as a discussion item for the Dallas agenda.

 <= /p>

At the meeting I propose w= e discuss:

 <= /p>

1.  What are the int= ended benefits and uses for Notify in SCIM environments

2.  What are the sca= lability, information, and technical problems being addressed

3.  What is left to d= efine

and finally,

4.  Is there enough i= nterest in the working group to add Notify to the SCIM charter.

 <= /p>

Phil<= o:p>

 

@independentid

phil.hunt@oracle= .com

 <= /p>

_________________________= ______________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1W2BR0= G3Ll9pscXlZRUoLXePQdZUdNOMomA_UD4UaIYyKRBkEywJJhX2smiG5hBBMnNjUhzYUwfNTH6pOb= e-E84hD35qsgShWVqRbTMw8mKGe4s_dK0USAp6_-9ovqvk0nlQtdnmvGtgWWrEL96C1r9pgyj-QD= 5l-sCESPmA9MzI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim

 <= /p>

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

= --Apple-Mail-6AFF6E92-BEB4-45C1-854A-84385BF3935E--