From nobody Mon Apr 6 09:34: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 BB7AC1A8A28; Mon, 6 Apr 2015 09:34:56 -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 m8mGbyXiEToI; Mon, 6 Apr 2015 09:34:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E312A1A89AE; Mon, 6 Apr 2015 09:34:45 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150406163445.28992.60300.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 09:34:45 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] Last Call: (System for Cross-Domain Identity Management: Core Schema) to Proposed Standard X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:34:57 -0000 The IESG has received a request from the System for Cross-domain Identity Management WG (scim) to consider the following document: - 'System for Cross-Domain Identity Management: Core Schema' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 6 09:35: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 B5E8B1A89AE; Mon, 6 Apr 2015 09:35:21 -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 zLyrAJ7meBz0; Mon, 6 Apr 2015 09:35:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 192A81A899A; Mon, 6 Apr 2015 09:35:14 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150406163514.26499.2539.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 09:35:14 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] Last Call: (System for Cross-Domain Identity Management: Protocol) to Proposed Standard X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:35:22 -0000 The IESG has received a request from the System for Cross-domain Identity Management WG (scim) to consider the following document: - 'System for Cross-Domain Identity Management: Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized services. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model and a service protocol defined by this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-scim-api/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-scim-api/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 7 00:08: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 5A8911B324D; Tue, 7 Apr 2015 00:08:47 -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 R0CSryuMS-ar; Tue, 7 Apr 2015 00:08:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 267861B324C; Tue, 7 Apr 2015 00:08:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407070846.30702.90166.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 00:08:46 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [scim] Last Call Expired: 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, 07 Apr 2015 07:08:47 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Tue Apr 7 13:04:00 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 C9A131A8A80; Tue, 24 Mar 2015 12:07:33 -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 v4p8KjzszFD8; Tue, 24 Mar 2015 12:07:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 609891A8A9B; Tue, 24 Mar 2015 12:07:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324190731.8406.78178.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 12:07:31 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: 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, 24 Mar 2015 19:07:34 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 7 13:04: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 7E8D31A8BC3; Tue, 24 Mar 2015 12:34:00 -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 HLVX9mMxQWNQ; Tue, 24 Mar 2015 12:33:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD741A8AD1; Tue, 24 Mar 2015 12:33:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324193358.4705.27089.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 12:33:58 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: 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, 24 Mar 2015 19:34:00 -0000 Last call has been made for draft-ietf-scim-use-cases and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 7 13:04: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 366541A8A65; Mon, 6 Apr 2015 08:50:34 -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 7NO4kN5iEqVL; Mon, 6 Apr 2015 08:50:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCB91A8A77; Mon, 6 Apr 2015 08:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406155031.2019.17157.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 08:50:31 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 15:50:34 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ From nobody Tue Apr 7 13:04: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 4EBF71A8A9C; Mon, 6 Apr 2015 08:50:42 -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 1kA-65a0_7jq; Mon, 6 Apr 2015 08:50:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F231A8A65; Mon, 6 Apr 2015 08:50:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406155041.4051.59843.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 08:50:41 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 15:50:42 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-api/ From nobody Tue Apr 7 13:04: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 6663A1A8AC9; Mon, 6 Apr 2015 09:34:59 -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 bAafbsyoc5HR; Mon, 6 Apr 2015 09:34:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBDA1A896D; Mon, 6 Apr 2015 09:34:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406163446.28992.81553.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 09:34:46 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:34:59 -0000 Last call has been made for draft-ietf-scim-core-schema and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ From nobody Tue Apr 7 13:04: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 47FC41A899A; Mon, 6 Apr 2015 09:35: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 47GYhZ7_alKy; Mon, 6 Apr 2015 09:35:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD301A8A9A; Mon, 6 Apr 2015 09:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406163514.26499.25307.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 09:35:14 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:03:58 -0700 Subject: [scim] ID Tracker State Update Notice: X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:35:22 -0000 Last call has been made for draft-ietf-scim-api and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-api/ From nobody Tue Apr 7 15:06: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 E3B991ACD7B; Tue, 7 Apr 2015 15:06:15 -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 rzCTMUqN8Gbo; Tue, 7 Apr 2015 15:06:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC791ACD79; Tue, 7 Apr 2015 15:06:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407220613.29027.5075.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 15:06:13 -0700 From: IETF Secretariat Archived-At: Subject: [scim] ID Tracker State Update Notice: 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, 07 Apr 2015 22:06:16 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 7 16:44:52 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 6E30F1AC3AF; Tue, 7 Apr 2015 15:02:34 -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 JNhWbfwt25CY; Tue, 7 Apr 2015 15:02:30 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8281ABD3E; Tue, 7 Apr 2015 15:02:30 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t37M2TZY022267; Tue, 7 Apr 2015 22:02:29 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id AA69AC20819; Tue, 7 Apr 2015 22:02:29 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150324193347.4705.84819.idtracker@ietfa.amsl.com> References: <20150324193347.4705.84819.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #815247 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 07 Apr 2015 22:02:29 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 16:44:51 -0700 Cc: iesg@ietf.org, scim@ietf.org, draft-ietf-scim-use-cases@ietf.org, scim-chairs@ietf.org Subject: [scim] [IANA #815247] Last Call: (System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows) to Informational RFC X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:02:34 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-scim-use-cases-05, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Tue Mar 24 19:34:12 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the System for Cross-domain Identity > Management WG (scim) to consider the following document: > - 'System for Cross-domain Identity Management (SCIM) Definitions, > Overview, and Flows' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-07. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document provides definitions and an overview of the System for > Cross-domain Identity Management (SCIM). It lays out the system's > models and flows, and includes user scenarios, use cases, and > requirements. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Tue Apr 7 18:01: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 5B4101B2A77 for ; Tue, 7 Apr 2015 18:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NDgYhhxzUPxM for ; Tue, 7 Apr 2015 18:01:42 -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 57FA61B2A6C for ; Tue, 7 Apr 2015 18:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1428454900; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=bZ52w+AWJGhDRYGsF4shg+Hf4x0h+PE1wkaFpsLfE9M=; b=QrvmjfhbVbp5xxhGvELsw25YSKH/X+jQ9VidLdR3OCZV/BzUW8oujLamOn4RxjyFwb2FNzZJGzufXIEDLhwP3mv1RdS+krTuIBqjHcdpgFa9iXAY2MyopgsEOrfzvHii0ZnfLia1X6+5o82EBKVO8C+W8JMi1woJwSKP70119zo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R661e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02009; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.1.151.84(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.183) by smtp.aliyun-inc.com(127.0.0.1); Wed, 08 Apr 2015 09:01:37 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 08 Apr 2015 09:01:32 +0800 From: "Kepeng Li" To: Magnus =?ISO-8859-1?B?TnlzdHL2bQ==?= , Message-ID: Thread-Topic: Secdir review of draft-ietf-scim-use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3511328496_3965431" Archived-At: Cc: scim Subject: Re: [scim] Secdir review of draft-ietf-scim-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, 08 Apr 2015 01:01:45 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3511328496_3965431 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Magnus, Thanks for the review. >Section 3.5: Shouldn't there also be a requirement for the secure transfer= of attributes between A and B based on matters such as A trusting authenticati= on results from B, a means to provide those authentication results securely to= B, etc.? Essentially similar to what was presented in Section 3.3? OK, I propose to add the following to section 3.5 as requirements: Relying party B must be able to authenticate the end user Relying party B must be able to securely provide the authentication results to directory service A Directory service A must be able to securely provide end user=E2=80=99s identity information (e.g., attributes) to relying party B >Section 3.6: Similar comment as for Section 3.5. There seems to be general security requirements missing for these two scenarios? Similarly, I propose to add the following sentences to section 3.6 as requirements: Relying party B must be able to authenticate the end user Relying party B must be able to securely provide the authentication results to directory service A Directory service A must be able to securely provide end user=E2=80=99s changed identity information (e.g., attributes) to relying party B >Section 4: Editorial suggestion: "only authenticated entity" -> "only authenticated entities=E2=80=9D. OK. Please let me know if the proposed changes above are fine with you. Thanks, Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m =E6=97=A5=E6=9C=9F: Monday, 6 April, 2015 9:51 am =E8=87=B3: "secdir@ietf.org" , =E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-scim-use-cases =E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: =E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5 Apr 2015 18:51:14 -0700 (PDT) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This memo describes the "System for Cross-domain Identity Management (SCIM)." SCIM is a companion document to the SCIM Schema memo and the SCIM Protocol memo. Section 3.5: Shouldn't there also be a requirement for the secure transfer of attributes between A and B based on matters such as A trusting authentication results from B, a means to provide those authentication results securely to B, etc.? Essentially similar to what was presented in Section 3.3? Section 3.6: Similar comment as for Section 3.5. There seems to be general security requirements missing for these two scenarios? Section 4: I only glanced the Security Consideration sections referenced here, but they do seem adequate, and given that I don't see that this memo'= s Security Consideration section need to contain more information. Editorial suggestion: "only authenticated entity" -> "only authenticated entities". -- Magnus --B_3511328496_3965431 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Magnus,

=
Thanks for the review.

>Section = 3.5: Shouldn't there also be a requirement for the secure transfer of attrib= utes between A and B based on matters such as A trusting authentication resu= lts from B, a means to provide those authentication results securely to B, e= tc.? Essentially similar to what was presented in Section 3.3?

=
OK, I propose to add the following to section 3.5 as requirements:

      Relying party B must be able = to authenticate the end user 
      Relying pa= rty B must be able to securely provide the authentication results to directo= ry service A 
      Directory service A must b= e able to securely provide end user’s identity information (e.g., attr= ibutes) to relying party B 

>Section = 3.6: Similar comment as for Section 3.5. There seems to be general security = requirements missing for these two scenarios?

Simil= arly, I propose to add the following sentences to section 3.6 as requirement= s:

      Relying party B must b= e able to authenticate the end user 
      Rel= ying party B must be able to securely provide the authentication results to = directory service A 
      Directory service A= must be able to securely provide end user’s changed identity informat= ion (e.g., attributes) to relying party B 

>Sect= ion 4:  Editorial suggestion: "only authenticated entity" -> "only a= uthenticated entities”.

OK.
<= br>
Please let me know if the proposed changes above are fine with= you.

Thanks,

Kind Regards=
Kepeng

=
=E5=8F=91=E4= =BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m <magnus= n@gmail.com>
=E6=97=A5=E6=9C=9F: Monday= , 6 April, 2015 9:51 am
=E8=87=B3: "secdir@ietf.org" <secdir@ietf.org>, <draft-ietf-scim-use-cases@tools.ietf.org>
=E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-sci= m-use-cases
=E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: <<= a href=3D"mailto:magnusn@gmail.com">magnusn@gmail.com>
=E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA: <draft-ietf-scim-use-cases@ietf.org>
=E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5 Apr 2015 18:51:14 -070= 0 (PDT)


=
I have reviewed this d= ocument as part of the security directorate's ongoing effort to review all IETF documents being processed by the IE= SG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This memo describes the "System for Cross-domain Identity Man= agement (SCIM)." SCIM is a companion document to the SCIM Schema memo and th= e SCIM Protocol memo.

Section 3.5: Shouldn't there also be= a requirement for the secure transfer of attributes between A and B based o= n matters such as A trusting authentication results from B, a means to provi= de those authentication results securely to B, etc.? Essentially similar to = what was presented in Section 3.3?

Section 3.6: Similar co= mment as for Section 3.5. There seems to be general security requirements mi= ssing for these two scenarios?

Section 4: I only glanced t= he Security Consideration sections referenced here, but they do seem adequat= e, and given that I don't see that this memo's Security Consideration sectio= n need to contain more information. Editorial suggestion: "only authenticate= d entity" -> "only authenticated entities".

-- Magnus
=
--B_3511328496_3965431-- From nobody Tue Apr 14 06:09: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 687B41A90E6; Tue, 14 Apr 2015 06:09:49 -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 GlRdvqN-KRet; Tue, 14 Apr 2015 06:09:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1981A90A4; Tue, 14 Apr 2015 06:09:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414130933.6755.68105.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:09:33 -0700 From: IETF Secretariat Archived-At: Subject: [scim] ID Tracker State Update Notice: 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, 14 Apr 2015 13:09:49 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 14 06:10:52 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 57A031A924C; Tue, 14 Apr 2015 06:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 IwzBpwZB-Uiz; Tue, 14 Apr 2015 06:10:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6201A9125; Tue, 14 Apr 2015 06:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414130959.24488.25088.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:09:59 -0700 From: IETF Secretariat Archived-At: Subject: [scim] Telechat update notice: 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, 14 Apr 2015 13:10:49 -0000 Placed on agenda for telechat - 2015-04-23 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 14 09:22: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 9FD0B1B2E41; Tue, 14 Apr 2015 09:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzOImpV6_FzO; Tue, 14 Apr 2015 09:22:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 654861B2E2C; Tue, 14 Apr 2015 09:22:51 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414162251.24587.79812.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 09:22:51 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-06.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, 14 Apr 2015 16:22:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Definitions, Overview, and Flows Authors : Phil Hunt Bhumip Khasnabish Anthony Nadalin Kepeng LI Zachary Zeltsan Filename : draft-ietf-scim-use-cases-06.txt Pages : 18 Date : 2015-04-13 Abstract: This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's 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: http://tools.ietf.org/html/draft-ietf-scim-use-cases-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-06 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 Apr 14 09:22: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 B89E91B2E3B; Tue, 14 Apr 2015 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PFgIuZe-u5D; Tue, 14 Apr 2015 09:22:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B071B2E3C; Tue, 14 Apr 2015 09:22:51 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414162251.24587.63383.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 09:22:51 -0700 Archived-At: Subject: [scim] New Version Notification - draft-ietf-scim-use-cases-06.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, 14 Apr 2015 16:22:53 -0000 A new version (-06) has been submitted for draft-ietf-scim-use-cases: http://www.ietf.org/internet-drafts/draft-ietf-scim-use-cases-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-06 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. IETF Secretariat. From nobody Tue Apr 14 10:27: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 A70201B315D for ; Mon, 13 Apr 2015 19:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, 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 EPDwX-CrJdwT for ; Mon, 13 Apr 2015 19:26:44 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 AC0B11B3137 for ; Mon, 13 Apr 2015 19:26:43 -0700 (PDT) Received: by wizk4 with SMTP id k4so95593105wiz.1 for ; Mon, 13 Apr 2015 19:26:42 -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=HyOw8/gYhnm/cB6Ewxrrq6ueyZvsur6/Olggw8As9Dg=; b=jvp0lP5Nf5vzAKeHMnBoiIn9q7MlUD41OFCi49B1LxBWGqnYSVcdUNE2OMfEkPj4gP CP3CrUI0zQ+rcGJb0AdWBfqnR7fV5J7p5LGsvc2fEASoreaE6I1miiBwht3S3LRUGePM BKSxAgoMSOXGFsMl6WHc0BxywYc8ZGI0Tv47vArqpMfhgyBe5UFCDhQYYlM6OWW/TVDz 9h50Upv3nU68lAwfz739ogeI2/0VQN+/JHieU81HDgonZOadsZvnX4aIW6bK9e4aoJwF WyfgIt0crNu/Zp5zqaICeISwbi4NH+Zp0zYj9dT7Ud1MqgNW6Q0PR7kIP+igmvzcqBDU 1j4g== MIME-Version: 1.0 X-Received: by 10.180.7.134 with SMTP id j6mr28036180wia.9.1428978402390; Mon, 13 Apr 2015 19:26:42 -0700 (PDT) Received: by 10.180.46.131 with HTTP; Mon, 13 Apr 2015 19:26:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Apr 2015 19:26:42 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Kepeng Li Content-Type: multipart/alternative; boundary=f46d0442828810f6280513a5f674 Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 10:27:44 -0700 Cc: scim , draft-ietf-scim-use-cases@tools.ietf.org Subject: Re: [scim] Secdir review of draft-ietf-scim-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, 14 Apr 2015 02:26:45 -0000 --f46d0442828810f6280513a5f674 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, these updates look good to me. Best, On Tue, Apr 7, 2015 at 6:01 PM, Kepeng Li wrote: > Hi Magnus, > > Thanks for the review. > > >Section 3.5: Shouldn't there also be a requirement for the secure > transfer of attributes between A and B based on matters such as A trustin= g > authentication results from B, a means to provide those authentication > results securely to B, etc.? Essentially similar to what was presented in > Section 3.3? > > OK, I propose to add the following to section 3.5 as requirements: > > Relying party B must be able to authenticate the end user > Relying party B must be able to securely provide the authentication > results to directory service A > Directory service A must be able to securely provide end user=E2=80= =99s > identity information (e.g., attributes) to relying party B > > >Section 3.6: Similar comment as for Section 3.5. There seems to be > general security requirements missing for these two scenarios? > > Similarly, I propose to add the following sentences to section 3.6 as > requirements: > > Relying party B must be able to authenticate the end user > Relying party B must be able to securely provide the authentication > results to directory service A > Directory service A must be able to securely provide end user=E2=80= =99s > changed identity information (e.g., attributes) to relying party B > > >Section 4: Editorial suggestion: "only authenticated entity" -> "only > authenticated entities=E2=80=9D. > > OK. > > Please let me know if the proposed changes above are fine with you. > > Thanks, > > Kind Regards > Kepeng > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m > =E6=97=A5=E6=9C=9F: Monday, 6 April, 2015 9:51 am > =E8=87=B3: "secdir@ietf.org" , < > draft-ietf-scim-use-cases@tools.ietf.org> > =E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-scim-use-cases > =E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: > =E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA: > =E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5 Apr 2015 18:51:14 -0700 (PDT= ) > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This memo describes the "System for Cross-domain Identity Management > (SCIM)." SCIM is a companion document to the SCIM Schema memo and the SCI= M > Protocol memo. > > Section 3.5: Shouldn't there also be a requirement for the secure transfe= r > of attributes between A and B based on matters such as A trusting > authentication results from B, a means to provide those authentication > results securely to B, etc.? Essentially similar to what was presented in > Section 3.3? > > Section 3.6: Similar comment as for Section 3.5. There seems to be genera= l > security requirements missing for these two scenarios? > > Section 4: I only glanced the Security Consideration sections referenced > here, but they do seem adequate, and given that I don't see that this > memo's Security Consideration section need to contain more information. > Editorial suggestion: "only authenticated entity" -> "only authenticated > entities". > > -- Magnus > --=20 -- Magnus --f46d0442828810f6280513a5f674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, these updates look good to me. Best,

On Tue, Apr 7, 2015 a= t 6:01 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> w= rote:
=
Hi Magnus,

Thanks for t= he review.

>Sectio= n 3.5: Shouldn't there also be a requirement for the secure transfer of= attributes between A and B based on matters such as A trusting authenticat= ion results from B, a means to provide those authentication results securel= y to B, etc.? Essentially similar to what was presented in Section 3.3?
=
OK, I propose to add the following t= o section 3.5 as requirements:

=C2=A0 =C2=A0 = =C2=A0 Relying party B must be able to authenticate the end user=C2=A0
=C2=A0 =C2=A0 =C2=A0 Relying party B must be able to securely provide= the authentication results to directory service A=C2=A0
=C2=A0 = =C2=A0 =C2=A0 Directory service A must be able to securely provide end user= =E2=80=99s identity information (e.g., attributes) to relying party B=C2=A0=

>Section 3.6: Si= milar comment as for Section 3.5. There seems to be general security requir= ements missing for these two scenarios?

Similarly, I propose to add the following sentences to sectio= n 3.6 as requirements:

=C2=A0 =C2=A0 =C2=A0 R= elying party B must be able to authenticate the end user=C2=A0
= =C2=A0 =C2=A0 =C2=A0 Relying party B must be able to securely provide the a= uthentication results to directory service A=C2=A0
=C2=A0 =C2=A0 = =C2=A0 Directory service A must be able to securely provide end user=E2=80= =99s changed identity information (e.g., attributes) to relying party B=C2= =A0

>Section 4: =C2=A0Editorial suggestion: &= quot;only authenticated entity" -> "only authenticated entitie= s=E2=80=9D.

OK.

Ple= ase let me know if the proposed changes above are fine with you.
=
Thanks,

Kind Regards
Kepeng
=

=E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3= =B6m <magnusn@gma= il.com>
=E6=97=A5=E6=9C=9F: Monday, 6 April, 2015 9:51 am
=E8= =87=B3: "= secdir@ietf.org" <secdir@ietf.org>, <draft-ietf-scim-use-cases@tools.iet= f.org>
=E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-scim-use-cases
=E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: <magnusn@gmail.com>=E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4= =BA=BA: <draft-ietf-scim-use-cases@ietf.org>
=E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5= Apr 2015 18:51:14 -0700 (PDT)


I have reviewed this docu= ment as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IE= SG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments.
<= div dir=3D"ltr">

This memo describes = the "System for Cross-domain Identity Management (SCIM)." SCIM is= a companion document to the SCIM Schema memo and the SCIM Protocol memo.
Section 3.5: Shouldn't there also be a requirement for= the secure transfer of attributes between A and B based on matters such as= A trusting authentication results from B, a means to provide those authent= ication results securely to B, etc.? Essentially similar to what was presen= ted in Section 3.3?

Section 3.6: Similar comment as for S= ection 3.5. There seems to be general security requirements missing for the= se two scenarios?

Section 4: I only glanced the Security = Consideration sections referenced here, but they do seem adequate, and give= n that I don't see that this memo's Security Consideration section = need to contain more information. Editorial suggestion: "only authenti= cated entity" -> "only authenticated entities".

-- Magnus



--
-- Magnus
--f46d0442828810f6280513a5f674-- From nobody Tue Apr 14 12:08: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 84A181ACD9C; Tue, 14 Apr 2015 12:08:26 -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 lobpmuIPmDbG; Tue, 14 Apr 2015 12:08:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB121ACE61; Tue, 14 Apr 2015 12:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414190528.17463.13102.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 12:05:28 -0700 From: IETF Secretariat Archived-At: Subject: [scim] ID Tracker State Update Notice: 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, 14 Apr 2015 19:08:26 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ From nobody Tue Apr 14 16:08: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 ED3A51B304B for ; Tue, 14 Apr 2015 16:08:47 -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 F7zyvIMZIOUM for ; Tue, 14 Apr 2015 16:08:46 -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 4C5101B3044 for ; Tue, 14 Apr 2015 16:08:46 -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 t3EN8jU2031446 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Apr 2015 23:08:45 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 t3EN8jC5013375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Apr 2015 23:08:45 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 t3EN8jvg010511 for ; Tue, 14 Apr 2015 23:08:45 GMT Received: from [172.31.147.139] (/216.9.110.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Apr 2015 16:08:44 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <0ED83628-C7B7-4352-BD50-C62DD6E74856@oracle.com> Date: Tue, 14 Apr 2015 16:08:42 -0700 To: SCIM WG X-Mailer: iPhone Mail (12F70) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [scim] Password mgmt draft - password history X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:08:48 -0000 I received an interesting comment today that the password history attribute s= hould be made complex so that the date the password value was used can be se= t. This is useful for expiring password history based on passage of time rat= her than simple count.=20 Btw. Any other comments regarding the submission? Phil= From nobody Tue Apr 14 18:49: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 4014D1B2BAD for ; Tue, 14 Apr 2015 18:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Viui9E2uqtvW for ; Tue, 14 Apr 2015 18:49:14 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 686941B2BC8 for ; Tue, 14 Apr 2015 18:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1429062552; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=e2shGKglByFSLC77uO9A5B0u4WDWrK0sdXqYUZdPcHA=; b=KjMP3LDhddepZIzKmPzoRJweEQNs2FcEi+ZoPj0t1KvjHKQBl9AFDK3F21gSq17UKztFKQotyOgm2tlGbcwqw7WirHZNHD2YhYqAWpBah4T6OqBUvsxC/XQHDvZ3fa2UhD6glJeo6XtITASfV7AkahLKgSaVsW+CV+JHV46bqlE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05022; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.144.239(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.158) by smtp.aliyun-inc.com(127.0.0.1); Wed, 15 Apr 2015 09:49:06 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 15 Apr 2015 09:49:01 +0800 From: "Kepeng Li" To: Magnus =?ISO-8859-1?B?TnlzdHL2bQ==?= Message-ID: Thread-Topic: [scim] Secdir review of draft-ietf-scim-use-cases References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3511936146_5815964" Archived-At: Cc: scim Subject: Re: [scim] Secdir review of draft-ietf-scim-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, 15 Apr 2015 01:49:17 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3511936146_5815964 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you Magnus. Here is the updated draft to reflect the changes: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-06 Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m =E6=97=A5=E6=9C=9F: Tuesday, 14 April, 2015 10:26 am =E8=87=B3: Li Kepeng =E6=8A=84=E9=80=81: scim , =E4=B8=BB=E9=A2=98: Re: [scim] Secdir review of draft-ietf-scim-use-cases Thanks, these updates look good to me. Best, On Tue, Apr 7, 2015 at 6:01 PM, Kepeng Li wrote: > Hi Magnus, >=20 > Thanks for the review. >=20 >> >Section 3.5: Shouldn't there also be a requirement for the secure trans= fer >> of attributes between A and B based on matters such as A trusting >> authentication results from B, a means to provide those authentication >> results securely to B, etc.? Essentially similar to what was presented i= n >> Section 3.3? >=20 > OK, I propose to add the following to section 3.5 as requirements: >=20 > Relying party B must be able to authenticate the end user > Relying party B must be able to securely provide the authentication > results to directory service A > Directory service A must be able to securely provide end user=E2=80=99s i= dentity > information (e.g., attributes) to relying party B >=20 >> >Section 3.6: Similar comment as for Section 3.5. There seems to be gene= ral >> security requirements missing for these two scenarios? >=20 > Similarly, I propose to add the following sentences to section 3.6 as > requirements: >=20 > Relying party B must be able to authenticate the end user > Relying party B must be able to securely provide the authentication > results to directory service A > Directory service A must be able to securely provide end user=E2=80=99s c= hanged > identity information (e.g., attributes) to relying party B >=20 >> >Section 4: Editorial suggestion: "only authenticated entity" -> "only >> authenticated entities=E2=80=9D. >=20 > OK. >=20 > Please let me know if the proposed changes above are fine with you. >=20 > Thanks, >=20 > Kind Regards > Kepeng >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m > =E6=97=A5=E6=9C=9F: Monday, 6 April, 2015 9:51 am > =E8=87=B3: "secdir@ietf.org" , > > =E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-scim-use-cases > =E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: > =E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA: > =E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5 Apr 2015 18:51:14 -0700 (PDT) >=20 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. >=20 > This memo describes the "System for Cross-domain Identity Management (SCI= M)." > SCIM is a companion document to the SCIM Schema memo and the SCIM Protoco= l > memo. >=20 > Section 3.5: Shouldn't there also be a requirement for the secure transfe= r of > attributes between A and B based on matters such as A trusting authentica= tion > results from B, a means to provide those authentication results securely = to B, > etc.? Essentially similar to what was presented in Section 3.3? >=20 > Section 3.6: Similar comment as for Section 3.5. There seems to be genera= l > security requirements missing for these two scenarios? >=20 > Section 4: I only glanced the Security Consideration sections referenced = here, > but they do seem adequate, and given that I don't see that this memo's > Security Consideration section need to contain more information. Editoria= l > suggestion: "only authenticated entity" -> "only authenticated entities". >=20 > -- Magnus --=20 -- Magnus _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --B_3511936146_5815964 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Thank you Magnus.
Here is the updated draft to reflect the changes:

Diff from previous version:

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m = <magnusn@gmail.com>
=E6=97=A5=E6=9C=9F: Tuesday, 14 April, 2015 10:26 am
<= span style=3D"font-weight:bold">=E8=87=B3: Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E6=8A=84=E9=80=81: scim <sc= im@ietf.org>, <draft-ietf-scim-use-cases@tools.ietf.org>
=E4=B8=BB=E9=A2=98: Re: [scim] Secdir review of draft-ietf-scim-us= e-cases

Thanks, these updates look go= od to me. Best,

On Tue, Apr 7, 2015 at 6:01 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com<= /a>> wrote:
=
Hi Magnus,

Thanks for the revie= w.

>Section 3.5: Shou= ldn't there also be a requirement for the secure transfer of attributes betw= een A and B based on matters such as A trusting authentication results from = B, a means to provide those authentication results securely to B, etc.? Esse= ntially similar to what was presented in Section 3.3?

OK, I propose to add the following to section 3.5 as requi= rements:

      Relying party B = must be able to authenticate the end user 
    &nbs= p; Relying party B must be able to securely provide the authentication resul= ts to directory service A 
      Directory ser= vice A must be able to securely provide end user’s identity informatio= n (e.g., attributes) to relying party B 

>Section 3.6: Similar comment as for Section 3.5. = There seems to be general security requirements missing for these two scenar= ios?

Similarly, I propose to = add the following sentences to section 3.6 as requirements:

      Relying party B must be able to authentic= ate the end user 
      Relying party B must b= e able to securely provide the authentication results to directory service A=  
      Directory service A must be able to se= curely provide end user’s changed identity information (e.g., attribut= es) to relying party B 

>Section 4:  = ;Editorial suggestion: "only authenticated entity" -> "only authenticated= entities”.

OK.

Please let me know if the proposed changes above are fine with you.
<= div>
Thanks,

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Nystr=C3=B6m <magnusn@gmail.com>
=E6=97=A5=E6=9C=9F: Monday, 6 April, 2015 9:51 am
=E8=87=B3: "= secdir@ietf.org" <se= cdir@ietf.org>, <draft-ietf-scim-use-cases@tools.ietf.org>=E4=B8=BB=E9=A2=98: Secdir review of draft-ietf-= scim-use-cases
=E9=87=8D=E5=8F=91=E5=8F=91=E4=BB=B6=E4=BA=BA: &l= t;magnusn@gmail.com&g= t;
=E9=87=8D=E5=8F=91=E6=94=B6=E4=BB=B6=E4=BA=BA: <draft-ietf-scim-us= e-cases@ietf.org>
=E9=87=8D=E5=8F=91=E6=97=A5=E6=9C=9F: Sun, 5 Apr 2015 18:51:14 -0700 (PDT)


I have reviewed this document as pa= rt of the security directorate's ongoing effort to review all IETF documents being processed by the IE= SG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This memo describes the "System for Cross-domain Identity Man= agement (SCIM)." SCIM is a companion document to the SCIM Schema memo and th= e SCIM Protocol memo.

Section 3.5: Shouldn't there also be= a requirement for the secure transfer of attributes between A and B based o= n matters such as A trusting authentication results from B, a means to provi= de those authentication results securely to B, etc.? Essentially similar to = what was presented in Section 3.3?

Section 3.6: Similar co= mment as for Section 3.5. There seems to be general security requirements mi= ssing for these two scenarios?

Section 4: I only glanced t= he Security Consideration sections referenced here, but they do seem adequat= e, and given that I don't see that this memo's Security Consideration sectio= n need to contain more information. Editorial suggestion: "only authenticate= d entity" -> "only authenticated entities".

-- Magnus



--
-- Magnus
_______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/m= ailman/listinfo/scim --B_3511936146_5815964-- From nobody Thu Apr 16 10:00:00 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 42C6D1B32EA for ; Thu, 16 Apr 2015 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 pop4vV3r__X2 for ; Thu, 16 Apr 2015 09:59:57 -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 CD6521B32E6 for ; Thu, 16 Apr 2015 09:59:57 -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 t3GGxu1w008629 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Apr 2015 16:59:57 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 t3GGxt3f017051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Apr 2015 16:59:56 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3GGxt4g012956 for ; Thu, 16 Apr 2015 16:59:55 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Apr 2015 09:59:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_ED254468-1FC0-4139-AE22-8A1534F1A47C" Message-Id: <44503439-7CC4-4661-9C33-85068265C068@oracle.com> Date: Thu, 16 Apr 2015 09:59:54 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [scim] Typo in core schema 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, 16 Apr 2015 16:59:59 -0000 --Apple-Mail=_ED254468-1FC0-4139-AE22-8A1534F1A47C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just want to note there is a typo in Table 1 of the core schema draft.=20= +----------------+--------------------+-----------------------------+ | SCIM Data Type | SCIM Schema "type" | JSON Type | +----------------+--------------------+-----------------------------+ | String | "string" | String per Sec. 7 [RFC7159 = ] | | Boolean | "boolean" | Value per Sec. 3 [RFC7159 = ] | | Decimal | "decimal" | Number per Sec. 6 [RFC7159 = ] | | Integer | "integer" | Number per Sec. 6 [RFC7159 = ] | | DateTime | "dateTime" | String per Sec. 7 [RFC7159 = ] | | Binary | "string" | Base64 encoded String | | Reference | "reference" | String per Sec. 7 [RFC7159 = ] | | Complex | "complex" | Object per Sec. 4 [RFC7159 = ] | +----------------+--------------------+-----------------------------+ In the above table, the "SCIM Schema type=E2=80=9D for =E2=80=9CBinary=E2=80= =9D should be =E2=80=9Cbinary=E2=80=9D and not =E2=80=9Cstring=E2=80=9D. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_ED254468-1FC0-4139-AE22-8A1534F1A47C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just want to note there is a typo in Table 1 of the core = schema draft. 

 =
+----------------+--------------------+-----------------------------+
   | SCIM Data Type | SCIM Schema "type" | JSON Type                   |
   +----------------+--------------------+-----------------------------+
   | String         | "string"           | String per Sec. 7 [RFC7159] |
   | Boolean        | "boolean"          | Value per Sec. 3 [RFC7159]  |
   | Decimal        | "decimal"          | Number per Sec. 6 [RFC7159] |
   | Integer        | "integer"          | Number per Sec. 6 [RFC7159] |
   | DateTime       | "dateTime"         | String per Sec. 7 [RFC7159] |
   | Binary         | "string"           | Base64 encoded String       |
   | Reference      | "reference"        | String per Sec. 7 [RFC7159] |
   | Complex        | "complex"          | Object per Sec. 4 [RFC7159] |
   =
+----------------+--------------------+-----------------------------+

In the above =
table, the "SCIM Schema type=E2=80=9D for =E2=80=9CBinary=E2=80=9D =
should be =E2=80=9Cbinary=E2=80=9D and not =E2=80=9Cstring=E2=80=9D.
=
= --Apple-Mail=_ED254468-1FC0-4139-AE22-8A1534F1A47C-- From nobody Thu Apr 16 13:58: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 123021A711A for ; Thu, 16 Apr 2015 13:58:53 -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 33u66DVIQard for ; Thu, 16 Apr 2015 13:58:51 -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 AB0D81A6EF0 for ; Thu, 16 Apr 2015 13:58:50 -0700 (PDT) Received: by layy10 with SMTP id y10so66131344lay.0 for ; Thu, 16 Apr 2015 13:58: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=ww/QgSIhqm5BwHMRoyoWNaOtajOhGw5j7ZwXjOnOqLM=; b=YFc0q8dfjFFZA0EaVDixMiH6lMzqGMaqJcvhtKoU3QlrxPj1J3KsYhuA7LAtI6rTLT VQte947lurZpJFLLA5e5nwT1H50mABAm1Adf+IaYL4M44NpPTnMHIGXuMkJdAYe7Q+V3 tL4Xlvq8efRX/V0fFusfy+2AfTYn3QYueJylXCmfk+aJ1Abu6/HD+4BMymYHc6teSwVD SBVh8LTjgeLqd7r3Mds4lnAEgIlLKyRCLtJPvFMVwzOiVyV+/+d8nsUJd5Q79Qi9Yq/F pspwrhJw4puanPw+uZZJYbHwqBoejGTR0jvx+rIlG4/YEB6mhp4oh6nxjYGfpiEjqgJQ y1dQ== X-Gm-Message-State: ALoCoQl0l/TZGa5xVM3GlFCJffQU5X8KmVkE7oNQLm+Ig3Lle1WFTglUX6vgKBA0DaWi4lgStUeL X-Received: by 10.112.151.211 with SMTP id us19mr29511693lbb.120.1429217929118; Thu, 16 Apr 2015 13:58: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 xq2sm1938575lbb.49.2015.04.16.13.58.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 13:58:48 -0700 (PDT) Message-ID: <55302287.1080905@mnt.se> Date: Thu, 16 Apr 2015 22:58:47 +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: <44503439-7CC4-4661-9C33-85068265C068@oracle.com> In-Reply-To: <44503439-7CC4-4661-9C33-85068265C068@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [scim] Typo in core schema 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, 16 Apr 2015 20:58:53 -0000 On 04/16/2015 06:59 PM, Phil Hunt wrote: > Just want to note there is a typo in Table 1 of the core schema draft. > > +----------------+--------------------+-----------------------------+ > | SCIM Data Type | SCIM Schema "type" | JSON Type | > +----------------+--------------------+-----------------------------+ > | String | "string" | String per Sec. 7 [RFC7159 ] | > | Boolean | "boolean" | Value per Sec. 3 [RFC7159 ] | > | Decimal | "decimal" | Number per Sec. 6 [RFC7159 ] | > | Integer | "integer" | Number per Sec. 6 [RFC7159 ] | > | DateTime | "dateTime" | String per Sec. 7 [RFC7159 ] | > | Binary | "string" | Base64 encoded String | > | Reference | "reference" | String per Sec. 7 [RFC7159 ] | > | Complex | "complex" | Object per Sec. 4 [RFC7159 ] | > +----------------+--------------------+-----------------------------+ > > > In the above table, the "SCIM Schema type” for “Binary” should be > “binary” and not “string”. > i guess we can deal with this in the "galleys" > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > From nobody Tue Apr 21 13:02:37 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 557D41A1A75 for ; Tue, 21 Apr 2015 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LjX21gkk5y for ; Tue, 21 Apr 2015 13:02:34 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 9A5641A1A45 for ; Tue, 21 Apr 2015 13:02:33 -0700 (PDT) Received: from [128.118.110.149] (wtrend.ais.psu.edu [128.118.110.149]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3LK2VwI6070404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Apr 2015 16:02:32 -0400 Message-ID: <5536ACD7.1020307@psu.edu> Date: Tue, 21 Apr 2015 16:02:31 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; 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] SCIM Schema specification correction and question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:02:36 -0000 Though it's been a while since I've sent anything to the list, we've been successfully using SCIM 2.0 (with a few differences) since January of 2014. We're looking at bring our installation up to the current specification and so I'm revisiting the documents (draft 17). I'll write a case-study for anyone who's interested - a short description is an OpenLDAP/Fortress-backed system with 2.6M user accounts. Our original components were built from the specifications using first principles and continuing that trend, I've created an object to represent the JSON Schemas (per section 3 and 7 of the SCIM Schema specification), converted the three schemas (in section 8.7.1 of the SCIM Schema specification) to individual JSON objects and then used a JSON parser/mapper to attempt to read the JSON schemas into the Schema object. Reading the User Schema in this way results in an error in User.groups.value as there's a "readOnly" attribute that I believe has been obsoleted by the "mutability" attribute. The User.groups.$ref, User.groups.display and User.groups.type sub-attributes have the same problem. Removing the four instances of the "readOnly" attribute allows the User schema to be parsed according to section 2 of the SCIM Schema specification. For completeness, here are the steps used to convert the published JSON to individual JSON files for the User, Group and EnterpriseUser schemas: 1) Copy the text from the SCIM Schema specification. 2) Delete the page breaks included in the RFC. 3) Split the document into three parts. 4) Eliminate line feeds in all "description" attributes. 5) Delete the "readOnly" attributes (User schema only). I also have a question that I believe should be pretty easy to answer - section 3.1 states: With the exception of "ServiceProviderConfig" and "ResourceType" server discovery endpoints and their associated resources, these attributes MUST be included in all resources, including any extended resource types. I don't think the "externalId" attribute is applicable to the Schema resource type ... when would this be used? I should also note that it's unlikely our system will ever be completely SCIM compliant ... our use cases generally revolve around keeping the university's systems synchronized, so there are many clients of our SCIM system. While our SCIM Service Provider doesn't assign the externalId (there is one external system that is allowed to create this value), our server does enforce uniqueness on this field since only one user in the SCIM system should be allowed with an associated externalId. Finally, I'd like to thank everyone for their efforts in creating these specifications, we've been mostly watching (so far) but will contribute most of our SCIM code back to the community via the Apache Directory project once the appropriate arrangements are made. We'll also provide at least one pass of proof-reading on draft 17 of the specification documents. All the best, Steve Moyer From nobody Tue Apr 21 15:01: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 B8C791B2C66 for ; Tue, 21 Apr 2015 15:01:49 -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 qpDrKnyFkGAn for ; Tue, 21 Apr 2015 15:01: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 DE9C11B2C65 for ; Tue, 21 Apr 2015 15:01:44 -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 t3LM1hT9009773 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Apr 2015 22:01:44 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3LM1he6023630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2015 22:01:43 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3LM1gmB012890; Tue, 21 Apr 2015 22:01:43 GMT Received: from [25.91.88.209] (/24.114.40.175) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Apr 2015 15:01:42 -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: <5536ACD7.1020307@psu.edu> Date: Tue, 21 Apr 2015 15:01:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5536ACD7.1020307@psu.edu> To: Steve Moyer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Schema specification correction and question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 22:01:49 -0000 Steve, Thanks for the feed back. Good luck with your implementation.=20 There are those of us that feel that SCIM on top of LDAP cannot be compliant= . This is in part at least why we dropped the scim ldap mapping. The chief p= roblem being LDAPs lack of complex attribute support. All mappings end up im= posing changes on LDAP clients or compliance issues in SCIM.=20 A few years ago I also proposed a scim directory with ldap legacy support. T= he difference being the underlying data store must support complex data. Da= ta that legacy clients often don't understand or care about.=20 Phil > On Apr 21, 2015, at 13:02, Steve Moyer wrote: >=20 > Though it's been a while since I've sent anything to the list, we've > been successfully using SCIM 2.0 (with a few differences) since January > of 2014. We're looking at bring our installation up to the current > specification and so I'm revisiting the documents (draft 17). I'll > write a case-study for anyone who's interested - a short description is > an OpenLDAP/Fortress-backed system with 2.6M user accounts. >=20 > Our original components were built from the specifications using first > principles and continuing that trend, I've created an object to > represent the JSON Schemas (per section 3 and 7 of the SCIM Schema > specification), converted the three schemas (in section 8.7.1 of the > SCIM Schema specification) to individual JSON objects and then used a > JSON parser/mapper to attempt to read the JSON schemas into the Schema > object. >=20 > Reading the User Schema in this way results in an error in > User.groups.value as there's a "readOnly" attribute that I believe has > been obsoleted by the "mutability" attribute. The User.groups.$ref, > User.groups.display and User.groups.type sub-attributes have the same > problem. Removing the four instances of the "readOnly" attribute allows > the User schema to be parsed according to section 2 of the SCIM Schema > specification. >=20 > For completeness, here are the steps used to convert the published JSON > to individual JSON files for the User, Group and EnterpriseUser schemas: >=20 > 1) Copy the text from the SCIM Schema specification. > 2) Delete the page breaks included in the RFC. > 3) Split the document into three parts. > 4) Eliminate line feeds in all "description" attributes. > 5) Delete the "readOnly" attributes (User schema only). >=20 > I also have a question that I believe should be pretty easy to answer - > section 3.1 states: >=20 > With the exception of "ServiceProviderConfig" and > "ResourceType" server discovery endpoints and their associated > resources, these attributes MUST be included in all resources, > including any extended resource types. >=20 > I don't think the "externalId" attribute is applicable to the Schema > resource type ... when would this be used? >=20 > I should also note that it's unlikely our system will ever be completely > SCIM compliant ... our use cases generally revolve around keeping the > university's systems synchronized, so there are many clients of our SCIM > system. While our SCIM Service Provider doesn't assign the externalId > (there is one external system that is allowed to create this value), our > server does enforce uniqueness on this field since only one user in the > SCIM system should be allowed with an associated externalId. >=20 > Finally, I'd like to thank everyone for their efforts in creating these > specifications, we've been mostly watching (so far) but will contribute > most of our SCIM code back to the community via the Apache Directory > project once the appropriate arrangements are made. We'll also provide > at least one pass of proof-reading on draft 17 of the specification > documents. >=20 > All the best, >=20 > Steve Moyer >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Apr 21 15:15: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 03DAE1B2C76 for ; Tue, 21 Apr 2015 15:15:43 -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 fwyokIy_qqUk for ; Tue, 21 Apr 2015 15:15:41 -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 1D6091B2C66 for ; Tue, 21 Apr 2015 15:15:41 -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 t3LMFa4S027124 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Apr 2015 22:15:40 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 t3LMFZin002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2015 22:15:36 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3LMFZZn029891; Tue, 21 Apr 2015 22:15:35 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Apr 2015 15:15:34 -0700 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Phil Hunt Mime-Version: 1.0 (1.0) Date: Tue, 21 Apr 2015 15:01:40 -0700 Message-Id: References: <5536ACD7.1020307@psu.edu> In-Reply-To: <5536ACD7.1020307@psu.edu> To: Steve Moyer X-Mailer: iPhone Mail (12F70) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Schema specification correction and question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 22:15:43 -0000 Steve, Thanks for the feed back. Good luck with your implementation.=20 There are those of us that feel that SCIM on top of LDAP cannot be compliant= . This is in part at least why we dropped the scim ldap mapping. The chief p= roblem being LDAPs lack of complex attribute support. All mappings end up im= posing changes on LDAP clients or compliance issues in SCIM.=20 A few years ago I also proposed a scim directory with ldap legacy support. T= he difference being the underlying data store must support complex data. Da= ta that legacy clients often don't understand or care about.=20 Phil > On Apr 21, 2015, at 13:02, Steve Moyer wrote: >=20 > Though it's been a while since I've sent anything to the list, we've > been successfully using SCIM 2.0 (with a few differences) since January > of 2014. We're looking at bring our installation up to the current > specification and so I'm revisiting the documents (draft 17). I'll > write a case-study for anyone who's interested - a short description is > an OpenLDAP/Fortress-backed system with 2.6M user accounts. >=20 > Our original components were built from the specifications using first > principles and continuing that trend, I've created an object to > represent the JSON Schemas (per section 3 and 7 of the SCIM Schema > specification), converted the three schemas (in section 8.7.1 of the > SCIM Schema specification) to individual JSON objects and then used a > JSON parser/mapper to attempt to read the JSON schemas into the Schema > object. >=20 > Reading the User Schema in this way results in an error in > User.groups.value as there's a "readOnly" attribute that I believe has > been obsoleted by the "mutability" attribute. The User.groups.$ref, > User.groups.display and User.groups.type sub-attributes have the same > problem. Removing the four instances of the "readOnly" attribute allows > the User schema to be parsed according to section 2 of the SCIM Schema > specification. >=20 > For completeness, here are the steps used to convert the published JSON > to individual JSON files for the User, Group and EnterpriseUser schemas: >=20 > 1) Copy the text from the SCIM Schema specification. > 2) Delete the page breaks included in the RFC. > 3) Split the document into three parts. > 4) Eliminate line feeds in all "description" attributes. > 5) Delete the "readOnly" attributes (User schema only). >=20 > I also have a question that I believe should be pretty easy to answer - > section 3.1 states: >=20 > With the exception of "ServiceProviderConfig" and > "ResourceType" server discovery endpoints and their associated > resources, these attributes MUST be included in all resources, > including any extended resource types. >=20 > I don't think the "externalId" attribute is applicable to the Schema > resource type ... when would this be used? >=20 > I should also note that it's unlikely our system will ever be completely > SCIM compliant ... our use cases generally revolve around keeping the > university's systems synchronized, so there are many clients of our SCIM > system. While our SCIM Service Provider doesn't assign the externalId > (there is one external system that is allowed to create this value), our > server does enforce uniqueness on this field since only one user in the > SCIM system should be allowed with an associated externalId. >=20 > Finally, I'd like to thank everyone for their efforts in creating these > specifications, we've been mostly watching (so far) but will contribute > most of our SCIM code back to the community via the Apache Directory > project once the appropriate arrangements are made. We'll also provide > at least one pass of proof-reading on draft 17 of the specification > documents. >=20 > All the best, >=20 > Steve Moyer >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Apr 21 16:40: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 F39B91B2EC0 for ; Tue, 21 Apr 2015 16:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4z80iuPdYGw for ; Tue, 21 Apr 2015 16:40:41 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 A0C6E1B2EBF for ; Tue, 21 Apr 2015 16:40:40 -0700 (PDT) Received: from [192.168.87.135] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3LNebk56221980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Apr 2015 19:40:39 -0400 Message-ID: <5536DFF4.7030706@psu.edu> Date: Tue, 21 Apr 2015 19:40:36 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "scim@ietf.org" References: <5536ACD7.1020307@psu.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070504060706030206040403" Archived-At: Subject: Re: [scim] SCIM Schema specification correction and question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 23:40:45 -0000 This is a multi-part message in MIME format. --------------070504060706030206040403 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Phil, It's true that LDAP doesn't support but it's also true that LDAP is still the default choice for user directories ... we're tired of writing security into individual applications since it always ends up looking something like this: User ------------------------> Roles ----> Permissions \ / ----> Groups ---- This explains why we're adopting ANSI RBAC (Fortress) for our entire security model and standardizing on how these elements are stored and accessed. I followed your LDAP mapping and even had a couple discussions with you almost 18 months ago ... I believe we've found a solution that, while it's not as elegant as I'd like (a pure mapping solution) is working for 2.6M users and is accessed tens to hundreds of thousands of times per day. I remember you warning against LDAP attribute options (and especially their affect on legacy clients) but we've found a mapping that works. If the SCIM filter wasn't ambiguous in the same way LDAP filters are, I think we'd have also had a hard time with the searching ... specifically on the address complex type. Fortunately these filters are broadly compatible: (&(streetAddress=123 Elm Street)(postalCode=54321)) equals: filter=streetAddress%20eq%20%22123%20Elm%20Street%22&postalCode%20eq%20%2254321%22 The one place our system becomes problematic is actually for LDAPv3 clients ... there are situations where the client will have to de-duplicate the multi-valued attributes. It also mean our SCIM Service Provider does much more than match entries during searches and map attributes back and forth. We will however fail to be completely SCIM compliant since our schema is slightly different than the one published with the specification (e.g. clients can't write userName, uniqueness is enforced server-side on externalId, etc). We'd previously promised the Apache Directory team that I'd publish our "mapping" (which in some cases is a straight map and in other cases is an algorithm) and we'd be happy to share it with this group as well. Perhaps you'll find other holes in our implementation and can help move the entire group forward. Thanks again for all the help and advice ... you've obviously put a ton of time into making this specification successful! Steve On 04/21/2015 06:01 PM, Phil Hunt wrote: > Steve, > > Thanks for the feed back. Good luck with your implementation. > > There are those of us that feel that SCIM on top of LDAP cannot be compliant. This is in part at least why we dropped the scim ldap mapping. The chief problem being LDAPs lack of complex attribute support. All mappings end up imposing changes on LDAP clients or compliance issues in SCIM. > > A few years ago I also proposed a scim directory with ldap legacy support. The difference being the underlying data store must support complex data. Data that legacy clients often don't understand or care about. > > Phil > >> On Apr 21, 2015, at 13:02, Steve Moyer wrote: >> >> Though it's been a while since I've sent anything to the list, we've >> been successfully using SCIM 2.0 (with a few differences) since January >> of 2014. We're looking at bring our installation up to the current >> specification and so I'm revisiting the documents (draft 17). I'll >> write a case-study for anyone who's interested - a short description is >> an OpenLDAP/Fortress-backed system with 2.6M user accounts. >> >> Our original components were built from the specifications using first >> principles and continuing that trend, I've created an object to >> represent the JSON Schemas (per section 3 and 7 of the SCIM Schema >> specification), converted the three schemas (in section 8.7.1 of the >> SCIM Schema specification) to individual JSON objects and then used a >> JSON parser/mapper to attempt to read the JSON schemas into the Schema >> object. >> >> Reading the User Schema in this way results in an error in >> User.groups.value as there's a "readOnly" attribute that I believe has >> been obsoleted by the "mutability" attribute. The User.groups.$ref, >> User.groups.display and User.groups.type sub-attributes have the same >> problem. Removing the four instances of the "readOnly" attribute allows >> the User schema to be parsed according to section 2 of the SCIM Schema >> specification. >> >> For completeness, here are the steps used to convert the published JSON >> to individual JSON files for the User, Group and EnterpriseUser schemas: >> >> 1) Copy the text from the SCIM Schema specification. >> 2) Delete the page breaks included in the RFC. >> 3) Split the document into three parts. >> 4) Eliminate line feeds in all "description" attributes. >> 5) Delete the "readOnly" attributes (User schema only). >> >> I also have a question that I believe should be pretty easy to answer - >> section 3.1 states: >> >> With the exception of "ServiceProviderConfig" and >> "ResourceType" server discovery endpoints and their associated >> resources, these attributes MUST be included in all resources, >> including any extended resource types. >> >> I don't think the "externalId" attribute is applicable to the Schema >> resource type ... when would this be used? >> >> I should also note that it's unlikely our system will ever be completely >> SCIM compliant ... our use cases generally revolve around keeping the >> university's systems synchronized, so there are many clients of our SCIM >> system. While our SCIM Service Provider doesn't assign the externalId >> (there is one external system that is allowed to create this value), our >> server does enforce uniqueness on this field since only one user in the >> SCIM system should be allowed with an associated externalId. >> >> Finally, I'd like to thank everyone for their efforts in creating these >> specifications, we've been mostly watching (so far) but will contribute >> most of our SCIM code back to the community via the Apache Directory >> project once the appropriate arrangements are made. We'll also provide >> at least one pass of proof-reading on draft 17 of the specification >> documents. >> >> All the best, >> >> Steve Moyer >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- "One longs, in reading your code, to walk on all fours" - Voltaire --------------070504060706030206040403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Phil,

It's true that LDAP doesn't support but it's also true that LDAP is still the default choice for user directories ... we're tired of writing security into individual applications since it always ends up looking something like this:

    User ------------------------> Roles ----> Permissions
           \                  /
             ----> Groups ----

This explains why we're adopting ANSI RBAC (Fortress) for our entire security model and standardizing on how these elements are stored and accessed.

I followed your LDAP mapping and even had a couple discussions with you almost 18 months ago ... I believe we've found a solution that, while it's not as elegant as I'd like (a pure mapping solution) is working for 2.6M users and is accessed tens to hundreds of thousands of times per day.  I remember you warning against LDAP attribute options (and especially their affect on legacy clients) but we've found a mapping that works.

If the SCIM filter wasn't ambiguous in the same way LDAP filters are, I think we'd have also had a hard time with the searching ... specifically on the address complex type.  Fortunately these filters are broadly compatible:

    (&(streetAddress=123 Elm Street)(postalCode=54321))

equals:

    filter=streetAddress%20eq%20%22123%20Elm%20Street%22&postalCode%20eq%20%2254321%22

The one place our system becomes problematic is actually for LDAPv3 clients ... there are situations where the client will have to de-duplicate the multi-valued attributes.  It also mean our SCIM Service Provider does much more than match entries during searches and map attributes back and forth.  We will however fail to be completely SCIM compliant since our schema is slightly different than the one published with the specification (e.g. clients can't write userName, uniqueness is enforced server-side on externalId, etc).

We'd previously promised the Apache Directory team that I'd publish our "mapping" (which in some cases is a straight map and in other cases is an algorithm) and we'd be happy to share it with this group as well.  Perhaps you'll find other holes in our implementation and can help move the entire group forward.

Thanks again for all the help and advice ... you've obviously put a ton of time into making this specification successful!

Steve
On 04/21/2015 06:01 PM, Phil Hunt wrote:
Steve,

Thanks for the feed back. Good luck with your implementation. 

There are those of us that feel that SCIM on top of LDAP cannot be compliant. This is in part at least why we dropped the scim ldap mapping. The chief problem being LDAPs lack of complex attribute support. All mappings end up imposing changes on LDAP clients or compliance issues in SCIM. 

A few years ago I also proposed a scim directory with ldap legacy support. The difference being the underlying data store must support complex data.  Data that legacy clients often don't understand or care about. 

Phil


On Apr 21, 2015, at 13:02, Steve Moyer <smoyer@psu.edu> wrote:

Though it's been a while since I've sent anything to the list, we've
been successfully using SCIM 2.0 (with a few differences) since January
of 2014.  We're looking at bring our installation up to the current
specification and so I'm revisiting the documents (draft 17).  I'll
write a case-study for anyone who's interested - a short description is
an OpenLDAP/Fortress-backed system with 2.6M user accounts.

Our original components were built from the specifications using first
principles and continuing that trend, I've created an object to
represent the JSON Schemas (per section 3 and 7 of the SCIM Schema
specification), converted the three schemas (in section 8.7.1 of the
SCIM Schema specification) to individual JSON objects and then used a
JSON parser/mapper to attempt to read the JSON schemas into the Schema
object.

Reading the User Schema in this way results in an error in
User.groups.value as there's a "readOnly" attribute that I believe has
been obsoleted by the "mutability" attribute.  The User.groups.$ref,
User.groups.display and User.groups.type sub-attributes have the same
problem.  Removing the four instances of the "readOnly" attribute allows
the User schema to be parsed according to section 2 of the SCIM Schema
specification.

For completeness, here are the steps used to convert the published JSON
to individual JSON files for the User, Group and EnterpriseUser schemas:

1)  Copy the text from the SCIM Schema specification.
2)  Delete the page breaks included in the RFC.
3)  Split the document into three parts.
4)  Eliminate line feeds in all "description" attributes.
5)  Delete the "readOnly" attributes (User schema only).

I also have a question that I believe should be pretty easy to answer -
section 3.1 states:

     With the exception of "ServiceProviderConfig" and
     "ResourceType" server discovery endpoints and their associated
     resources, these attributes MUST be included in all resources,
     including any extended resource types.

I don't think the "externalId" attribute is applicable to the Schema
resource type ... when would this be used?

I should also note that it's unlikely our system will ever be completely
SCIM compliant ... our use cases generally revolve around keeping the
university's systems synchronized, so there are many clients of our SCIM
system.  While our SCIM Service Provider doesn't assign the externalId
(there is one external system that is allowed to create this value), our
server does enforce uniqueness on this field since only one user in the
SCIM system should be allowed with an associated externalId.

Finally, I'd like to thank everyone for their efforts in creating these
specifications, we've been mostly watching (so far) but will contribute
most of our SCIM code back to the community via the Apache Directory
project once the appropriate arrangements are made.  We'll also provide
at least one pass of proof-reading on draft 17 of the specification
documents.

All the best,

Steve Moyer

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


-- 
"One longs, in reading your code, to walk on all fours" - Voltaire
--------------070504060706030206040403-- From nobody Tue Apr 21 17:17: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 808A11B2F37 for ; Tue, 21 Apr 2015 17:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQyB6ApLRME4 for ; Tue, 21 Apr 2015 17:17:47 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 454951B2F31 for ; Tue, 21 Apr 2015 17:17:47 -0700 (PDT) Received: from [192.168.87.135] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3M0HhnC1315070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Apr 2015 20:17:45 -0400 Message-ID: <5536E8A7.5000907@psu.edu> Date: Tue, 21 Apr 2015 20:17:43 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "scim@ietf.org" References: <5536ACD7.1020307@psu.edu> <5536DFF4.7030706@psu.edu> In-Reply-To: <5536DFF4.7030706@psu.edu> Content-Type: multipart/alternative; boundary="------------000100050608080506010509" Archived-At: Subject: Re: [scim] SCIM Schema specification correction and question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 00:17:50 -0000 This is a multi-part message in MIME format. --------------000100050608080506010509 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit ***** Correction ***** The LDAP filter in my previous e-mail should have been: (&(street=123 Elm Street)(postalCode=54321)) Sorry for any confusion! Steve On 04/21/2015 07:40 PM, Steve Moyer wrote: > Phil, > > It's true that LDAP doesn't support but it's also true that LDAP is > still the default choice for user directories ... we're tired of > writing security into individual applications since it always ends up > looking something like this: > > User ------------------------> Roles ----> Permissions > \ / > ----> Groups ---- > > This explains why we're adopting ANSI RBAC (Fortress) for our entire > security model and standardizing on how these elements are stored and > accessed. > > I followed your LDAP mapping and even had a couple discussions with > you almost 18 months ago ... I believe we've found a solution that, > while it's not as elegant as I'd like (a pure mapping solution) is > working for 2.6M users and is accessed tens to hundreds of thousands > of times per day. I remember you warning against LDAP attribute > options (and especially their affect on legacy clients) but we've > found a mapping that works. > > If the SCIM filter wasn't ambiguous in the same way LDAP filters are, > I think we'd have also had a hard time with the searching ... > specifically on the address complex type. Fortunately these filters > are broadly compatible: > > (&(streetAddress=123 Elm Street)(postalCode=54321)) > > equals: > > > filter=streetAddress%20eq%20%22123%20Elm%20Street%22&postalCode%20eq%20%2254321%22 > > The one place our system becomes problematic is actually for LDAPv3 > clients ... there are situations where the client will have to > de-duplicate the multi-valued attributes. It also mean our SCIM > Service Provider does much more than match entries during searches and > map attributes back and forth. We will however fail to be completely > SCIM compliant since our schema is slightly different than the one > published with the specification (e.g. clients can't write userName, > uniqueness is enforced server-side on externalId, etc). > > We'd previously promised the Apache Directory team that I'd publish > our "mapping" (which in some cases is a straight map and in other > cases is an algorithm) and we'd be happy to share it with this group > as well. Perhaps you'll find other holes in our implementation and > can help move the entire group forward. > > Thanks again for all the help and advice ... you've obviously put a > ton of time into making this specification successful! > > Steve > On 04/21/2015 06:01 PM, Phil Hunt wrote: >> Steve, >> >> Thanks for the feed back. Good luck with your implementation. >> >> There are those of us that feel that SCIM on top of LDAP cannot be compliant. This is in part at least why we dropped the scim ldap mapping. The chief problem being LDAPs lack of complex attribute support. All mappings end up imposing changes on LDAP clients or compliance issues in SCIM. >> >> A few years ago I also proposed a scim directory with ldap legacy support. The difference being the underlying data store must support complex data. Data that legacy clients often don't understand or care about. >> >> Phil >> >>> On Apr 21, 2015, at 13:02, Steve Moyer wrote: >>> >>> Though it's been a while since I've sent anything to the list, we've >>> been successfully using SCIM 2.0 (with a few differences) since January >>> of 2014. We're looking at bring our installation up to the current >>> specification and so I'm revisiting the documents (draft 17). I'll >>> write a case-study for anyone who's interested - a short description is >>> an OpenLDAP/Fortress-backed system with 2.6M user accounts. >>> >>> Our original components were built from the specifications using first >>> principles and continuing that trend, I've created an object to >>> represent the JSON Schemas (per section 3 and 7 of the SCIM Schema >>> specification), converted the three schemas (in section 8.7.1 of the >>> SCIM Schema specification) to individual JSON objects and then used a >>> JSON parser/mapper to attempt to read the JSON schemas into the Schema >>> object. >>> >>> Reading the User Schema in this way results in an error in >>> User.groups.value as there's a "readOnly" attribute that I believe has >>> been obsoleted by the "mutability" attribute. The User.groups.$ref, >>> User.groups.display and User.groups.type sub-attributes have the same >>> problem. Removing the four instances of the "readOnly" attribute allows >>> the User schema to be parsed according to section 2 of the SCIM Schema >>> specification. >>> >>> For completeness, here are the steps used to convert the published JSON >>> to individual JSON files for the User, Group and EnterpriseUser schemas: >>> >>> 1) Copy the text from the SCIM Schema specification. >>> 2) Delete the page breaks included in the RFC. >>> 3) Split the document into three parts. >>> 4) Eliminate line feeds in all "description" attributes. >>> 5) Delete the "readOnly" attributes (User schema only). >>> >>> I also have a question that I believe should be pretty easy to answer - >>> section 3.1 states: >>> >>> With the exception of "ServiceProviderConfig" and >>> "ResourceType" server discovery endpoints and their associated >>> resources, these attributes MUST be included in all resources, >>> including any extended resource types. >>> >>> I don't think the "externalId" attribute is applicable to the Schema >>> resource type ... when would this be used? >>> >>> I should also note that it's unlikely our system will ever be completely >>> SCIM compliant ... our use cases generally revolve around keeping the >>> university's systems synchronized, so there are many clients of our SCIM >>> system. While our SCIM Service Provider doesn't assign the externalId >>> (there is one external system that is allowed to create this value), our >>> server does enforce uniqueness on this field since only one user in the >>> SCIM system should be allowed with an associated externalId. >>> >>> Finally, I'd like to thank everyone for their efforts in creating these >>> specifications, we've been mostly watching (so far) but will contribute >>> most of our SCIM code back to the community via the Apache Directory >>> project once the appropriate arrangements are made. We'll also provide >>> at least one pass of proof-reading on draft 17 of the specification >>> documents. >>> >>> All the best, >>> >>> Steve Moyer >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim > > -- > "One longs, in reading your code, to walk on all fours" - Voltaire -- "One longs, in reading your code, to walk on all fours" - Voltaire --------------000100050608080506010509 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit ***** Correction *****

The LDAP filter in my previous e-mail should have been:

      (&(street=123 Elm Street)(postalCode=54321))

Sorry for any confusion!

Steve

On 04/21/2015 07:40 PM, Steve Moyer wrote:
Phil,

It's true that LDAP doesn't support but it's also true that LDAP is still the default choice for user directories ... we're tired of writing security into individual applications since it always ends up looking something like this:

    User ------------------------> Roles ----> Permissions
           \                  /
             ----> Groups ----

This explains why we're adopting ANSI RBAC (Fortress) for our entire security model and standardizing on how these elements are stored and accessed.

I followed your LDAP mapping and even had a couple discussions with you almost 18 months ago ... I believe we've found a solution that, while it's not as elegant as I'd like (a pure mapping solution) is working for 2.6M users and is accessed tens to hundreds of thousands of times per day.  I remember you warning against LDAP attribute options (and especially their affect on legacy clients) but we've found a mapping that works.

If the SCIM filter wasn't ambiguous in the same way LDAP filters are, I think we'd have also had a hard time with the searching ... specifically on the address complex type.  Fortunately these filters are broadly compatible:

    (&(streetAddress=123 Elm Street)(postalCode=54321))

equals:

    filter=streetAddress%20eq%20%22123%20Elm%20Street%22&postalCode%20eq%20%2254321%22

The one place our system becomes problematic is actually for LDAPv3 clients ... there are situations where the client will have to de-duplicate the multi-valued attributes.  It also mean our SCIM Service Provider does much more than match entries during searches and map attributes back and forth.  We will however fail to be completely SCIM compliant since our schema is slightly different than the one published with the specification (e.g. clients can't write userName, uniqueness is enforced server-side on externalId, etc).

We'd previously promised the Apache Directory team that I'd publish our "mapping" (which in some cases is a straight map and in other cases is an algorithm) and we'd be happy to share it with this group as well.  Perhaps you'll find other holes in our implementation and can help move the entire group forward.

Thanks again for all the help and advice ... you've obviously put a ton of time into making this specification successful!

Steve
On 04/21/2015 06:01 PM, Phil Hunt wrote:
Steve,

Thanks for the feed back. Good luck with your implementation. 

There are those of us that feel that SCIM on top of LDAP cannot be compliant. This is in part at least why we dropped the scim ldap mapping. The chief problem being LDAPs lack of complex attribute support. All mappings end up imposing changes on LDAP clients or compliance issues in SCIM. 

A few years ago I also proposed a scim directory with ldap legacy support. The difference being the underlying data store must support complex data.  Data that legacy clients often don't understand or care about. 

Phil


On Apr 21, 2015, at 13:02, Steve Moyer <smoyer@psu.edu> wrote:

Though it's been a while since I've sent anything to the list, we've
been successfully using SCIM 2.0 (with a few differences) since January
of 2014.  We're looking at bring our installation up to the current
specification and so I'm revisiting the documents (draft 17).  I'll
write a case-study for anyone who's interested - a short description is
an OpenLDAP/Fortress-backed system with 2.6M user accounts.

Our original components were built from the specifications using first
principles and continuing that trend, I've created an object to
represent the JSON Schemas (per section 3 and 7 of the SCIM Schema
specification), converted the three schemas (in section 8.7.1 of the
SCIM Schema specification) to individual JSON objects and then used a
JSON parser/mapper to attempt to read the JSON schemas into the Schema
object.

Reading the User Schema in this way results in an error in
User.groups.value as there's a "readOnly" attribute that I believe has
been obsoleted by the "mutability" attribute.  The User.groups.$ref,
User.groups.display and User.groups.type sub-attributes have the same
problem.  Removing the four instances of the "readOnly" attribute allows
the User schema to be parsed according to section 2 of the SCIM Schema
specification.

For completeness, here are the steps used to convert the published JSON
to individual JSON files for the User, Group and EnterpriseUser schemas:

1)  Copy the text from the SCIM Schema specification.
2)  Delete the page breaks included in the RFC.
3)  Split the document into three parts.
4)  Eliminate line feeds in all "description" attributes.
5)  Delete the "readOnly" attributes (User schema only).

I also have a question that I believe should be pretty easy to answer -
section 3.1 states:

     With the exception of "ServiceProviderConfig" and
     "ResourceType" server discovery endpoints and their associated
     resources, these attributes MUST be included in all resources,
     including any extended resource types.

I don't think the "externalId" attribute is applicable to the Schema
resource type ... when would this be used?

I should also note that it's unlikely our system will ever be completely
SCIM compliant ... our use cases generally revolve around keeping the
university's systems synchronized, so there are many clients of our SCIM
system.  While our SCIM Service Provider doesn't assign the externalId
(there is one external system that is allowed to create this value), our
server does enforce uniqueness on this field since only one user in the
SCIM system should be allowed with an associated externalId.

Finally, I'd like to thank everyone for their efforts in creating these
specifications, we've been mostly watching (so far) but will contribute
most of our SCIM code back to the community via the Apache Directory
project once the appropriate arrangements are made.  We'll also provide
at least one pass of proof-reading on draft 17 of the specification
documents.

All the best,

Steve Moyer

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


-- 
"One longs, in reading your code, to walk on all fours" - Voltaire

-- 
"One longs, in reading your code, to walk on all fours" - Voltaire
--------------000100050608080506010509-- From nobody Wed Apr 22 08:44: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 A65BF1ACE08; Wed, 22 Apr 2015 08:44:15 -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 hwrXM6F7bp-5; Wed, 22 Apr 2015 08:44:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F062A1ACE00; Wed, 22 Apr 2015 08:44:06 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422154406.25657.29730.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 08:44:06 -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] 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 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 15:44:15 -0000 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. - 2.1, "It's intent" - the It's is a little ambiguous. - 2.2.1, last bullet: I don't get that. Are real-time things even in charter I wonder? (CHECK) - 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. - 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. - 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? :-) - 3.3, as per my comment on 3.1, this is unclear as to what is in or out of scope of SCIM. - 3.5 you say "selected attributes" a number of times. Don't you need to say by whom and when? - 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. From nobody Wed Apr 22 15:15: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 B614F1B2B89; Wed, 22 Apr 2015 15:15: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 2I-tUJYFTUl6; Wed, 22 Apr 2015 15:15:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3E1B2B82; Wed, 22 Apr 2015 15:15:37 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422221537.16843.56656.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 15:15:37 -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-06: (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, 22 Apr 2015 22:15:41 -0000 Kathleen Moriarty 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: ---------------------------------------------------------------------- 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 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. 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/ From nobody Thu Apr 23 02:08: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 46A7C1A8ADE; Thu, 23 Apr 2015 02:08:03 -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 neylLemcB9ml; Thu, 23 Apr 2015 02:08:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A97961A8AB7; Thu, 23 Apr 2015 02:07:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 02:07:59 -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] 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 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:08:03 -0000 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" - 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. 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) From nobody Thu Apr 23 03:04: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 A30341A90C5 for ; Thu, 23 Apr 2015 03:04:29 -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 LkeJ7wY6tHLA for ; Thu, 23 Apr 2015 03:04:28 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 B46851A90C6 for ; Thu, 23 Apr 2015 03:04:19 -0700 (PDT) Received: by labbd9 with SMTP id bd9so8983572lab.2 for ; Thu, 23 Apr 2015 03:04: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KqBe90IoyhYfHnjHusnKVGnvjDFbq8CLk8lC+IAnhEo=; b=VUMkWHCkVeXENWGoA5fPG0GmtBKEZU/jwRyyzpgx3EZS3Vu0rTsDBFpGgjiNGReU81 uwfQG4OfUCxcpUuUcm7Kx09vii5eiqeMpPTBWyXlNNYjBZlJssSMK5Y6fnj5pv4CDi4l HGicsqrT8ZgvMXHrcra/e9eYhkhFYkP9I+IT/w9fDerA2GDOSDw3NGuDK+Bgu0lnVxkd mYOo6w4b9PJn7MuD3HVRwoQnN4To75H/+56imopkka9c42cpF+AkAHuygl8d9ydrqP1O 8SNEfb0d3Goq+pLG5IghPPqtg4ayav4Y0Pa69vCLFO4KLwB2hmeasDBYD/TVGJZ7tRec vGyg== X-Gm-Message-State: ALoCoQlvIECEi/t+UTRaU1DvZT4hHBCiy2lpkKUgLWRqfp5dTfdQMadyBWobi7BjPueSk2I2Lr/l X-Received: by 10.152.27.1 with SMTP id p1mr1751125lag.112.1429783458331; Thu, 23 Apr 2015 03:04:18 -0700 (PDT) Received: from [10.1.1.24] ([193.10.248.8]) by mx.google.com with ESMTPSA id n10sm1732591laa.40.2015.04.23.03.04.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 03:04:17 -0700 (PDT) Message-ID: <5538C3A1.7030109@mnt.se> Date: Thu, 23 Apr 2015 12:04:17 +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: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> In-Reply-To: <20150423090759.23148.3214.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: 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: Thu, 23 Apr 2015 10:04:29 -0000 > - 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. > Maybe something like "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)" ? Cheers Leif From nobody Thu Apr 23 08:25: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 2C3301ACAD4; Thu, 23 Apr 2015 08:25:14 -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 hALiTmAl7buu; Thu, 23 Apr 2015 08:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B647C1A8A73; Thu, 23 Apr 2015 08:24:56 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 08:24:56 -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 Discuss on draft-ietf-scim-use-cases-06: (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: Thu, 23 Apr 2015 15:25:14 -0000 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. ---------------------------------------------------------------------- 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 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. 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/ From nobody Thu Apr 23 08:38: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 D72091ACD29 for ; Thu, 23 Apr 2015 08:38:38 -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=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 lvZst72LsLlY for ; Thu, 23 Apr 2015 08:38:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 2A2DF1ACD0B for ; Thu, 23 Apr 2015 08:38:34 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so16230965lbb.0 for ; Thu, 23 Apr 2015 08:38:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Y8ZojI7D8v+VmFc+dA0gsu8FV0wFvM3MafkGX9Uzel8=; b=S7gu+yX6EV/Kgi8DVS8udF2FzcpHpWGV2g0VbhHdC6EwL874pMMXShefTjH//890Zo n0hMtVy8/9dTqpDfLuuBXCZLiYPLOC9kXh0c1yLszzEqI13VQ6xECvjEYkp3V4/j/UgV wOn1m0U8L74+yNXIONXZVhwkqFvWiK+Bz4l4lXZOF+VPjlYRqQHnVp5kSJjS/T7gyBh5 JwZJkRir0sZbDEJSl5TVw7hHiVRfy+gP8cvxM1/poXoKlsz2En4bmSHaaA/N25g1XmYo luHKE9w2mhZXjagqoX0T1508soDCyyi9easO4uoccgwBS2pS/DV3UWhf9XjwmBW/ftLF en2A== X-Gm-Message-State: ALoCoQkT++10yWGDa+ygPORnMe6YNS5rHenBxuv3xbbqbQ6WOg8x1NzwQ77tcPysMH2kAXVsrbLu X-Received: by 10.112.234.163 with SMTP id uf3mr3001343lbc.9.1429803512596; Thu, 23 Apr 2015 08:38:32 -0700 (PDT) Received: from [2.70.203.7] (2.70.203.7.mobile.tre.se. [2.70.203.7]) by mx.google.com with ESMTPSA id k12sm1940579lbg.42.2015.04.23.08.38.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 08:38:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12F70) In-Reply-To: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 17:38:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> To: Kathleen Moriarty Archived-At: Cc: "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" 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: Thu, 23 Apr 2015 15:38:39 -0000 > 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty : >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-scim-use-cases-06: 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 http://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: > http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I had a discuss on section 3.4, that should be quick to clear up on > privacy and security considerations. =20 >=20 > 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.=20= > If that's the case, it would be good to make sure the text and intent is > clear. >=20 > Current text: > Requirements: >=20 > o YourHR must ensure that the personal information generated by the > local 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 > o All operation with identity data must be securely logged. >=20 > o The logs should be available for auditing. >=20 > 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? i think you are right - the word 'globally' should go away probably >=20 > Sorry This was not in my review yesterday, I had a UI error. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 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.=20 >=20 > 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. >=20 > 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/ >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Apr 23 08:49: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 0E1DA1B2E98; Thu, 23 Apr 2015 08:49: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, 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 B5vlvq8O27sL; Thu, 23 Apr 2015 08:49: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 77FF61B2FF9; Thu, 23 Apr 2015 08:49:24 -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 t3NFnH77029483 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Apr 2015 15:49:17 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 t3NFnGLx010219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2015 15:49:17 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3NFnGj0017601; Thu, 23 Apr 2015 15:49:16 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Apr 2015 08:49:16 -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: Thu, 23 Apr 2015 08:49:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> To: Leif Johansson X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "draft-ietf-scim-use-cases.ad@ietf.org" , "scim@ietf.org" , Kathleen Moriarty , 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: Thu, 23 Apr 2015 15:49:34 -0000 Yes. Technically globally suggests scim is a db. Which is a sub case really (= and not the current charter).=20 Better to say as a provisioning protocol, the issue (is better expressed) as= distribution personal info across domains: technically (eg protocols and ap= ps), administratively (eg controlling orgs), and jurisdictionally.=20 Phil > On Apr 23, 2015, at 08:38, Leif Johansson wrote: >=20 >=20 >=20 >> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty : >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-scim-use-cases-06: 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 http://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: >> http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I had a discuss on section 3.4, that should be quick to clear up on >> privacy and security considerations. =20 >>=20 >> 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.=20= >> If that's the case, it would be good to make sure the text and intent is >> clear. >>=20 >> Current text: >> Requirements: >>=20 >> o YourHR must ensure that the personal information generated by the >> local 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 >> o All operation with identity data must be securely logged. >>=20 >> o The logs should be available for auditing. >>=20 >> 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? >=20 > i think you are right - the word 'globally' should go away probably >=20 >=20 >>=20 >> Sorry This was not in my review yesterday, I had a UI error. >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> 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/ >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Apr 23 08:49: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 747041B2E9E; Thu, 23 Apr 2015 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLAZscpDWEEz; Thu, 23 Apr 2015 08:49:35 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 369811A01A8; Thu, 23 Apr 2015 08:49:30 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so16479102lbb.0; Thu, 23 Apr 2015 08:49:28 -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=FNX4yBqJziPAcebaFJTdrZmFmoaXzmvttfB54GRjEik=; b=cXlD7+HAklBVprZiaL8bZX4SyCqq+IrB81Z46aiJzAtLiAFtbGP/RuxpNh7m0+k6kP G+1o/1Vu4DPCgvSFr3JmlF6D0slK++7Vo3BwENKLnwkg3sbGzoBltHc2IHVEgBShVQsr hFKU+0gd/ovz2INrEFCmpP5D7ZxGHqobWwYBZRdPM+RmD7+1sVvEA3fN4nI42dvjT3Vv 1/nnQg5dbu3C9jATqtEv0auuxwcbInL8ja1+9kclyPm3EKkhRigiUQzGh2huyq8Hz7Ki Qw8IDXTMCv2Z0U6JDYqiUzHT/4S9qW6l+eMN6FWXP8fUQNHkAYjjDmgnJLrYKmYvE3DV 4cDw== MIME-Version: 1.0 X-Received: by 10.112.29.36 with SMTP id g4mr3089975lbh.56.1429804168754; Thu, 23 Apr 2015 08:49:28 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 23 Apr 2015 08:49:28 -0700 (PDT) In-Reply-To: References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 11:49:28 -0400 Message-ID: From: Kathleen Moriarty To: Leif Johansson Content-Type: multipart/alternative; boundary=001a1133f99493ba7305146639be Archived-At: Cc: "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" 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: Thu, 23 Apr 2015 15:49:40 -0000 --001a1133f99493ba7305146639be Content-Type: text/plain; charset=UTF-8 Thanks, Leif. I have a question in-line. On Thu, Apr 23, 2015 at 11:38 AM, Leif Johansson wrote: > > > > 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.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 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? > > i think you are right - the word 'globally' should go away probably > > It's not clear how the identity management data and personal data are related. It reads as just identity management data is protected, shouldn't the personal information also be protected? Or maybe it's just not clear how the two are related and clearing that up avoids confusion? Thanks. Kathleen > > > > > 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 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. > > > > 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 > -- Best regards, Kathleen --001a1133f99493ba7305146639be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Leif.

I have a question in-line= .

On Thu, Ap= r 23, 2015 at 11:38 AM, Leif Johansson <leifj@mnt.se> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> 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-case= s/
>
>
>
> ----------------------------------------------------------------------=
> 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<= br> > language issue where I am reading this differently than it was intende= d.
> If that's the case, it would be good to make sure the text and int= ent is
> clear.
>
> Current text:
> Requirements:
>
>=C2=A0 =C2=A0o=C2=A0 YourHR must ensure that the personal information g= enerated by the
>=C2=A0 =C2=A0 =C2=A0 local offices is timely available in a globally-ac= cessible
>=C2=A0 =C2=A0 =C2=A0 database.
>
>=C2=A0 =C2=A0o=C2=A0 Identity management of the personal data must be p= rotected against
>=C2=A0 =C2=A0 =C2=A0 unauthorised access and remain confidential to onl= y authorised
>=C2=A0 =C2=A0 =C2=A0 parties.
>
>=C2=A0 =C2=A0o=C2=A0 All operation with identity data must be securely = logged.
>
>=C2=A0 =C2=A0o=C2=A0 The logs should be available for auditing.
>
> My concern is with bullets 1 & 2.=C2=A0 To me, this reads as thoug= h personal
> information will be globally available and just the identity managemen= t
> information is protected.=C2=A0 What is meant by globally available an= d are
> there some access restrictions?

i think you are right - the word 'globally' should go a= way probably

It's not clear how the id= entity management data and personal data are related.=C2=A0 It reads as jus= t identity management data is protected, shouldn't the personal informa= tion also be protected?=C2=A0 Or maybe it's just not clear how the two = are related and clearing that up avoids confusion?=C2=A0

Thanks.
Kathleen

>
> 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.= =C2=A0 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 section)<= br> > 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).=C2=A0 This also appli= es to
> Section 3.4 (or likely all use cases) as personal information is
> discussed in that use case description.=C2=A0 For section 3.4, you'= ;d need to
> worry about where accounts are provisioned.
>
> Nit:
> Section 2.3.4
>=C2=A0 =C2=A0At the protocol level, this class of scenarios may result = in the use
>=C2=A0 =C2=A0of common protocol exchange patters between CSP-1 & CS= P-2.
> s/patters/patterns/
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim



--

Best regards,
Kath= leen
--001a1133f99493ba7305146639be-- From nobody Thu Apr 23 08:51: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 9BC2A1A03AB; Thu, 23 Apr 2015 08:51:38 -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 wZC9ukWeImyP; Thu, 23 Apr 2015 08:51:36 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 900011A0389; Thu, 23 Apr 2015 08:51:34 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so16535990lbc.1; Thu, 23 Apr 2015 08:51:33 -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=WShPR/NBu2iY5hejtlqbkRNHU7gi4UQ9UOhfwV5mggo=; b=LGXH2ToAIz39EfDkClu2hhibwGphTJ3dAJb9Mh5ekFnbPzBhFbp3rmuJ08kSa63m0F sDxVHE0ZJC0w4nuFV+/Ym7EUJGbZltqce/1N0fo/AAEBpU0awd5hlc8+5ypEGT6xobVy MpYtOrIwP5x4a5kg3FC2/77/048dlKgFWlNWt0CcztB2zLKhoIAKQlCwJBF6ZEBsh09B OQGaq1SMAVvNXYb5WPlQpMxWxbADGYBdK53mGlH5cOWHvjHJFUzxXdhJMmyNmCN28bQi aG6ujiLytOZitl/vrSHgiYqkFreSfOxXu6/a/qFSaGYq/5zwydx1VoO4c3oVqA6EF0VG 3k2g== MIME-Version: 1.0 X-Received: by 10.152.121.42 with SMTP id lh10mr3100458lab.0.1429804293142; Thu, 23 Apr 2015 08:51:33 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 23 Apr 2015 08:51:33 -0700 (PDT) In-Reply-To: References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 11:51:33 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=089e01177485fdbdaa0514664037 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: Thu, 23 Apr 2015 15:51:38 -0000 --089e01177485fdbdaa0514664037 Content-Type: text/plain; charset=UTF-8 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 > really (and not the current charter). > > Better to say as a provisioning protocol, the issue (is better expressed) > as distribution personal info across domains: technically (eg protocols and > apps), administratively (eg controlling orgs), and jurisdictionally. > Could you propose some text and take a look at my response to Leif as well, we sent at the same time. It would be good to get 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 wrote: > > > > > > > >> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.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 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? > > > > 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 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. > >> > >> 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 > -- Best regards, Kathleen --089e01177485fdbdaa0514664037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 11:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Yes. Technically glo= bally suggests scim is a db. Which is a sub case really (and not the curren= t charter).

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

Could you propose some text and take a look a= t my response to Leif as well, we sent at the same time. It would be good t= o get 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@gmail.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/dis= cuss-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 int= ended.
>> If that's the case, it would be good to make sure the text and= intent is
>> clear.
>>
>> Current text:
>> Requirements:
>>
>>=C2=A0 o=C2=A0 YourHR must ensure that the personal information gen= erated by the
>>=C2=A0 =C2=A0 =C2=A0local offices is timely available in a globally= -accessible
>>=C2=A0 =C2=A0 =C2=A0database.
>>
>>=C2=A0 o=C2=A0 Identity management of the personal data must be pro= tected against
>>=C2=A0 =C2=A0 =C2=A0unauthorised access and remain confidential to = only authorised
>>=C2=A0 =C2=A0 =C2=A0parties.
>>
>>=C2=A0 o=C2=A0 All operation with identity data must be securely lo= gged.
>>
>>=C2=A0 o=C2=A0 The logs should be available for auditing.
>>
>> My concern is with bullets 1 & 2.=C2=A0 To me, this reads as t= hough personal
>> information will be globally available and just the identity manag= ement
>> information is protected.=C2=A0 What is meant by globally availabl= e and are
>> there some access restrictions?
>
> i think you are right - the word 'globally' should go away pro= bably
>
>
>>
>> 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 LDA= P.=C2=A0 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).=C2=A0 This also a= pplies to
>> Section 3.4 (or likely all use cases) as personal information is >> discussed in that use case description.=C2=A0 For section 3.4, you= 'd need to
>> worry about where accounts are provisioned.
>>
>> Nit:
>> Section 2.3.4
>>=C2=A0 At the protocol level, this class of scenarios may result in= the use
>>=C2=A0 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



--
=

Best regards,
Kathleen
--089e01177485fdbdaa0514664037-- From nobody Thu Apr 23 09:18: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 41E321A1BC2; Thu, 23 Apr 2015 09:18:18 -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 eOyh69-fIUJb; Thu, 23 Apr 2015 09:18:15 -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 34BA41A1BDD; Thu, 23 Apr 2015 09:18:05 -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 t3NGI1Vh030948 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Apr 2015 16:18:01 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 t3NGI0n0004278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2015 16:18:00 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3NGI0cD030812; Thu, 23 Apr 2015 16:18:00 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Apr 2015 09:17:59 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E188245D-A289-405E-8944-F96C9697B185" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Thu, 23 Apr 2015 09:17:57 -0700 Message-Id: <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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: Thu, 23 Apr 2015 16:18:18 -0000 --Apple-Mail=_E188245D-A289-405E-8944-F96C9697B185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How about this=E2=80=A6 Old Text: 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. New Text:=20 o Your HR must ensure that information generated by the local offices = is provisioned in a timely fashion across systems that may span = technical (e.g., protocols and applications), administrative (e.g., = corporate), and jurisdictional domains. o Management of personal information must be protected against = unauthorized access, eavesdropping, and should be distributed only to = authorized parties and services. Phil @independentid www.independentid.com phil.hunt@oracle.com > 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 = really (and not the current charter). >=20 > Better to say as a provisioning protocol, the issue (is better = expressed) as distribution personal info across domains: technically (eg = protocols and apps), administratively (eg controlling orgs), and = jurisdictionally. >=20 > Could you propose some text and take a look at my response to Leif as = well, we sent at the same time. It would be good to get the privacy = stuff in my 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 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? > > > > 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 = 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. > >> > >> 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 --Apple-Mail=_E188245D-A289-405E-8944-F96C9697B185 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
How about this=E2=80=A6

Old Text:
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.

New Text: 
o  Your HR must ensure that information generated = by the local offices is provisioned in a timely fashion across systems = that may span technical (e.g., protocols and applications), = administrative (e.g., corporate), and jurisdictional = domains.

o  Management of personal = information must be protected against unauthorized access, = eavesdropping, and should be distributed only to authorized parties and = services.


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



On Thu, Apr 23, 2015 at 11:49 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Yes. Technically = globally suggests 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) as distribution personal info across domains: technically (eg = protocols and apps), administratively (eg controlling orgs), and = jurisdictionally.

Could you propose some text and take a = look at my response to Leif as well, we sent at the same time. It would = be good to get 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@gmail.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/<= br class=3D""> >>
>>
>>
>> = ----------------------------------------------------------------------
>> 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?
>
> 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 = 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.
>>
>> 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



--

Best regards,
Kathleen

= --Apple-Mail=_E188245D-A289-405E-8944-F96C9697B185-- From nobody Thu Apr 23 09:57: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 F04D21ACD3E; Thu, 23 Apr 2015 09:57: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 O5EKBHOOeKw5; Thu, 23 Apr 2015 09:57:22 -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 ABCD71ACC85; Thu, 23 Apr 2015 09:57:05 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so17874341lbb.3; Thu, 23 Apr 2015 09:57: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=4Rx0KqNISN+Rp/9xO4Hqx5kI18LQg2kvbXOcC6JGMJM=; b=C0tMDQ4edO9Fy3tQnwH6no6iU7CZx6vaxAFcsWmJk/tc6G6VVuxFf5PN8ekxG5rUGg 5BE84C8iqoAxr3isHtL2IRaf29dlQQCYLJcz+m0K70d16Kvd/mCKyLuTRvilyv/dTWM3 Z+bQRQLezPTFwLPnwQXtA41nwMJJbDlqktZgWwry2fOe8HuZxVLZ5QTUEddrILhRGUg5 HfqD22BCVVx/JHPakGWs9xxv9vH6lRirv5K7gbypvnNhaxq6+4KuWSb/5b7ojI5ub7Qx RXAwYRyukjZX8Ui0D/Md1jFd69D+NS+yi4OZVlbEgvKTtsXiY3sPyWkf8muNr25OExHh mJpA== MIME-Version: 1.0 X-Received: by 10.112.29.36 with SMTP id g4mr3358906lbh.56.1429808224247; Thu, 23 Apr 2015 09:57:04 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 23 Apr 2015 09:57:04 -0700 (PDT) In-Reply-To: <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> Date: Thu, 23 Apr 2015 12:57:04 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1133f9944da51f0514672b0c 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: Thu, 23 Apr 2015 16:57:26 -0000 --001a1133f9944da51f0514672b0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=A6 > > Old Text: > > o YourHR must ensure that the personal information generated by the loca= l offices is timely available in a globally-accessible database. > > o Identity management of the personal data must be protected against una= uthorised access and remain confidential to only authorised parties. > > > New Text: > 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. > > o Management of personal information must be protected against > unauthorized access, eavesdropping, and should be distributed only to > authorized parties 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 > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Apr 23, 2015, at 8:51 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > 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 >> really (and not the current charter). >> >> Better to say as a provisioning protocol, the issue (is better expressed= ) >> as distribution personal info across domains: technically (eg protocols = and >> apps), administratively (eg controlling orgs), and jurisdictionally. >> > > Could you propose some text and take a look at my response to Leif as > well, we sent at the same time. It would be good to get 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 wrote: >> > >> > >> > >> >> 23 apr 2015 kl. 17:24 skrev Kathleen Moriarty < >> Kathleen.Moriarty.ietf@gmail.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 th= is >> >> 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 agains= t >> >> 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 person= al >> >> information will be globally available and just the identity manageme= nt >> >> information is protected. What is meant by globally available and ar= e >> >> 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 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 t= o >> >> 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 >> > https://www.ietf.org/mailman/listinfo/scim >> > > > > -- > > Best regards, > Kathleen > > > --=20 Best regards, Kathleen --001a1133f9944da51f0514672b0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

This looks good, but leaves ou= t security and privacy considerations.=C2=A0 How about a small addition (securely and considers priv= acy requirements), 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 th= is=E2=80=A6

Old Text:
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 unaut=
horised access and remain confidential to only authorised parties.

New Text:=C2=A0
o =C2=A0Your HR must ensure that information generated by the loca=
l offices is provisioned securely and considers privacy requirements in a t=
imely fashion across systems that may span technical (e.g., protocols and a=
pplications), administrative (e.g., corporate), and jurisdictional domains.=


o =C2=A0Management of personal information must be prote=
cted against unauthorized access, eavesdropping, and should be distributed =
only to authorized parties and services.

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


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

<= div dir=3D"ltr">

On Thu, Apr 23, 2015 at 11:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Yes. Technically globally suggests = 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 = apps), administratively (eg controlling orgs), and jurisdictionally.

Could you propose some text and take a look a= t my response to Leif as well, we sent at the same time. It would be good t= o get 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.iet= f@gmail.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/dis= cuss-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 int= ended.
>> If that's the case, it would be good to make sure the text and= intent is
>> clear.
>>
>> Current text:
>> Requirements:
>>
>>=C2=A0 o=C2=A0 YourHR must ensure that the personal information gen= erated by the
>>=C2=A0 =C2=A0 =C2=A0local offices is timely available in a globally= -accessible
>>=C2=A0 =C2=A0 =C2=A0database.
>>
>>=C2=A0 o=C2=A0 Identity management of the personal data must be pro= tected against
>>=C2=A0 =C2=A0 =C2=A0unauthorised access and remain confidential to = only authorised
>>=C2=A0 =C2=A0 =C2=A0parties.
>>
>>=C2=A0 o=C2=A0 All operation with identity data must be securely lo= gged.
>>
>>=C2=A0 o=C2=A0 The logs should be available for auditing.
>>
>> My concern is with bullets 1 & 2.=C2=A0 To me, this reads as t= hough personal
>> information will be globally available and just the identity manag= ement
>> information is protected.=C2=A0 What is meant by globally availabl= e and are
>> there some access restrictions?
>
> i think you are right - the word 'globally' should go away pro= bably
>
>
>>
>> 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 LDA= P.=C2=A0 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).=C2=A0 This also a= pplies to
>> Section 3.4 (or likely all use cases) as personal information is >> discussed in that use case description.=C2=A0 For section 3.4, you= 'd need to
>> worry about where accounts are provisioned.
>>
>> Nit:
>> Section 2.3.4
>>=C2=A0 At the protocol level, this class of scenarios may result in= the use
>>=C2=A0 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



--
=

Best regards,
Kathleen
=



--

Best regards,
Kathleen
--001a1133f9944da51f0514672b0c-- From nobody Thu Apr 23 10:15: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 AAD2F1ACDDD; Thu, 23 Apr 2015 10:15:46 -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 JAYBK95zqJzd; Thu, 23 Apr 2015 10:15:43 -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 2B2D21ACDD0; Thu, 23 Apr 2015 10:15:33 -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 t3NHFTOc009631 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Apr 2015 17:15:29 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 t3NHFSVE010707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2015 17:15:28 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3NHFSOl005468; Thu, 23 Apr 2015 17:15:28 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Apr 2015 10:15:28 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-E52F5351-6EF3-4C75-92F9-C75E654B1DC5 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Thu, 23 Apr 2015 10:15:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> To: Kathleen Moriarty X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: 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" 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: Thu, 23 Apr 2015 17:15:46 -0000 --Apple-Mail-E52F5351-6EF3-4C75-92F9-C75E654B1DC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1=20 Phil > On Apr 23, 2015, at 09:57, Kathleen Moriarty wrote: >=20 > Hi Phil, >=20 > This looks good, but leaves out security and privacy considerations. How a= bout a small addition (securely and considers privacy requirements), include= d in your first new bullet below? >=20 >> On Thu, Apr 23, 2015 at 12:17 PM, Phil Hunt wrote:= >> How about this=E2=80=A6 >>=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 una= uthorised 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 fashion= across systems that may span technical (e.g., protocols and applications), a= dministrative (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 part= ies and services. >=20 > Although the second bullet covers security, it doesn't cover changing regu= latory requirements for privacy based on location. The office might be in a= different country than the CSP. >=20 > 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 a= nd 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 al= l >>>> >> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> >> 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 inten= ded. >>>> >> If that's the case, it would be good to make sure the text and inten= t is >>>> >> clear. >>>> >> >>>> >> Current text: >>>> >> Requirements: >>>> >> >>>> >> o YourHR must ensure that the personal information generated by th= e >>>> >> local offices is timely available in a globally-accessible >>>> >> database. >>>> >> >>>> >> o Identity management of the personal data must be protected again= st >>>> >> 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 perso= nal >>>> >> information will be globally available and just the identity managem= ent >>>> >> information is protected. What is meant by globally available and a= re >>>> >> 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 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 t= o >>>> >> 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 us= e >>>> >> 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 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-E52F5351-6EF3-4C75-92F9-C75E654B1DC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 

Phil

On A= pr 23, 2015, at 09:57, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

=
Hi Phil,

This looks good, but leaves out security and privacy considerations.&n= bsp; How about a small addition (s= ecurely and considers privacy requirements), included in your first n= ew bullet below?

On Thu, Apr 23, 2015 at 12:17 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.co= m> wrote:
How about this=E2=80=A6

Old Text:
o  YourHR must ensure that the personal information generated by the loc=
al offices is timely available in a globally-accessible database.

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

New Text: 
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), and jurisdictional domains.=


o  Management of personal information must be protected agai=
nst unauthorized access, eavesdropping, and should be distributed only to au=
thorized parties and services.
Although the second bullet covers security, it doesn't cover cha= nging regulatory requirements for privacy based on location.  The offic= e might be in a different country than the CSP.

Tha= nks,
Kathleen 

Phil

@independentid
www.independentid.c= om
phil.hunt@oracle.com
=

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



On T= hu, Apr 23, 2015 at 11:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Yes. Technically globally suggests 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) as= distribution personal info across domains: technically (eg protocols and ap= ps), administratively (eg controlling orgs), and jurisdictionally.

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

Thank you,
Kathleen
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex">
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@= gmail.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 a= ll
>> email addresses included in the To and CC lines. (Feel free to cut t= his
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discu= ss-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-ca= ses/
>>
>>
>>
>> -------------------------------------------------------------------= ---
>> 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 inte= nded.
>> If that's the case, it would be good to make sure the text and inte= nt is
>> clear.
>>
>> Current text:
>> Requirements:
>>
>>  o  YourHR must ensure that the personal information gene= rated by the
>>     local offices is timely available in a globally-= accessible
>>     database.
>>
>>  o  Identity management of the personal data must be prot= ected against
>>     unauthorised access and remain confidential to o= nly authorised
>>     parties.
>>
>>  o  All operation with identity data must be securely log= ged.
>>
>>  o  The logs should be available for auditing.
>>
>> My concern is with bullets 1 & 2.  To me, this reads as th= ough personal
>> information will be globally available and just the identity manage= ment
>> 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.&nb= sp; 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 sectio= n)
>> that there should be some mention of regulatory concerns when movin= g
>> identity information between jurisdictional regions (countries,
= >> state-by-state for regulations on privacy, and universities have >> additional regulations on personal information).  This also ap= plies 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 t= he 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



--
<= div>

Best regards,
Kathleen


=

--

Best regards,
Kathleen
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-E52F5351-6EF3-4C75-92F9-C75E654B1DC5-- From nobody Thu Apr 23 10:39: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 530A51ACE38 for ; Thu, 23 Apr 2015 10:39:12 -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=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 Ss3YJQaTb8Xv for ; Thu, 23 Apr 2015 10:39:11 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 521C11B3104 for ; Thu, 23 Apr 2015 10:38:56 -0700 (PDT) Received: by layy10 with SMTP id y10so18114167lay.0 for ; Thu, 23 Apr 2015 10:38:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/Rf17keXCk3deZtCyzIzM6u0Y67ReQL/PsnFIFvWGfY=; b=VyUAjBy2Yy4OjT8iI97kTg1x53p1VNEbjsTSU84POQ6IQvd6n4Od+iFVm/3F6hQVoQ TSd4rob1kOPTf6b2QALUvu16aewbT3XyalXcycMfJ+f15Qhy7qJ3A2bHRAgI1yM+hAD6 mbZpdWMfaiXGHXN8V13giL8BNon9RqdGbkY1fJ/7BhgJ4aAp6pgzOtufxjOG4q+gKt4E oYoBBdA9fXnOC0+/gm9WPiWebZY0Oyx4Md5geeQ3vcIGh5dlv7yQzm6Qq30tfkxEHjw4 RghlElQZGUqNkKxbCUCE2SIIwuLNFAFM/xUp5oMa/+40BqWf6XbwoFjuGN3jaK+CjeSM +lpQ== X-Gm-Message-State: ALoCoQlzHdkV62dKLuMs6ZvjZpWyJ1Nd8obsY7Xh0WpW0qd47sg1XR4CcBPu1xWj/g7lOFvenyL8 X-Received: by 10.112.202.194 with SMTP id kk2mr842465lbc.54.1429810734851; Thu, 23 Apr 2015 10:38:54 -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 ml10sm2009845lbc.29.2015.04.23.10.38.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:38:54 -0700 (PDT) Message-ID: <55392E2D.3000303@mnt.se> Date: Thu, 23 Apr 2015 19:38: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: Kathleen Moriarty References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "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" 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: Thu, 23 Apr 2015 17:39:12 -0000 On 04/23/2015 05:49 PM, Kathleen Moriarty wrote: > Thanks, Leif. > > I have a question in-line. > > On Thu, Apr 23, 2015 at 11:38 AM, 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 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? > > i think you are right - the word 'globally' should go away probably > > It's not clear how the identity management data and personal data are > related. It reads as just identity management data is protected, > shouldn't the personal information also be protected? Or maybe it's > just not clear how the two are related and clearing that up avoids > confusion? or it may not be meaningful to make that distinction... at least legally you are on very thing ice in the EU if you try > > Thanks. > Kathleen > > > > > > 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 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. > > > > 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 > > > > > -- > > Best regards, > Kathleen From nobody Thu Apr 23 10:40: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 F41001B3102 for ; Thu, 23 Apr 2015 10:40:05 -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=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 UEi86YFk3kTx for ; Thu, 23 Apr 2015 10:40:04 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 1E7501B30FE for ; Thu, 23 Apr 2015 10:39:33 -0700 (PDT) Received: by layy10 with SMTP id y10so18125474lay.0 for ; Thu, 23 Apr 2015 10:39:31 -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=kM8AzQkvOuZxHqdYlR1EwHFvAl+npiiDgTDf0xsi7Ws=; b=SM42NsLot3FgcTmp2XwSmfSauyd27WWQVW9ncPljFAQc1AFgd/SVbiZ7WSKK5yutai jrDuXAclbJ4W+qxNhZATeCOONrAUIPdkjFmR0kqr+ekFPHXLNIdoiRuu3/cjAl9+BwKa 5IhcD2c0d88R5jKRixtsue3Un6gThAxy2ddhZKnd1qi2YuBOQZvobhHf++MHhMwL/JJW /O+bDQUYbux9ubX1OF3WaQjwPKwni1QwBqXT3v+dR0R7WDmn7lEUmo+qEyiX/nT17oNd o7V8btVkiYNBhYDrkqnfmk1DQYhSp0d4HZxJjUFhT8tr2wQ4d7GAh0VxHgwxoYTV2QjS KcAg== X-Gm-Message-State: ALoCoQkSGJhjkltv4LXtqt3oa8EoBnvk1rq0uvEqyB5mwBRndwHJs1P/xCPe0pSZiVcNIA0IN8qG X-Received: by 10.112.160.41 with SMTP id xh9mr1312534lbb.96.1429810771671; Thu, 23 Apr 2015 10:39:31 -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 f7sm1128840lbc.9.2015.04.23.10.39.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:39:31 -0700 (PDT) Message-ID: <55392E53.7070002@mnt.se> Date: Thu, 23 Apr 2015 19:39:31 +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 , Kathleen Moriarty References: <20150423152456.14758.30808.idtracker@ietfa.amsl.com> <0FC7AA7E-AB33-4C26-90AA-FBC5913D8D88@oracle.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "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" 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: Thu, 23 Apr 2015 17:40:06 -0000 On 04/23/2015 07:15 PM, Phil Hunt wrote: > +1 > wfm > Phil > > On Apr 23, 2015, at 09:57, Kathleen Moriarty > > wrote: > >> 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… >> >> Old Text: >> >> 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. >> >> >> New Text: >> 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), and >> jurisdictional domains. >> >> o Management of personal information must be protected against >> unauthorized access, eavesdropping, and should be distributed only >> to authorized parties 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 >> >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >>> On Apr 23, 2015, at 8:51 AM, Kathleen Moriarty >>> >> > wrote: >>> >>> >>> >>> 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 really (and not the current charter). >>> >>> Better to say as a provisioning protocol, the issue (is >>> better expressed) as distribution personal info across >>> domains: technically (eg protocols and apps), >>> administratively (eg controlling orgs), and jurisdictionally. >>> >>> >>> Could you propose some text and take a look at my response to >>> Leif as well, we sent at the same time. It would be good to get >>> 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 >> > 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 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? >>> > >>> > 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 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. >>> >> >>> >> 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 >>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From nobody Fri Apr 24 09:26: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 691DA1B3092; Fri, 24 Apr 2015 09:26:13 -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 pbOkOHbNDshM; Fri, 24 Apr 2015 09:26:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 506051ACD59; Fri, 24 Apr 2015 09:26: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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424162611.21167.3624.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 09:26:11 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-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: Fri, 24 Apr 2015 16:26:13 -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-18.txt Pages : 90 Date : 2015-04-24 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-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 Fri Apr 24 09:32: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 D25021A07BD for ; Fri, 24 Apr 2015 09:32: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 It1FpJLFC23c for ; Fri, 24 Apr 2015 09:32:03 -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 160811A0390 for ; Fri, 24 Apr 2015 09:32:03 -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 t3OGW2Ar013398 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Apr 2015 16:32:02 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 t3OGW1fB018345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Apr 2015 16:32:01 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3OGW1du027575 for ; Fri, 24 Apr 2015 16:32:01 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Apr 2015 09:32:01 -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: <20150424162611.21167.3624.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 09:31:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90E6A3CF-82C5-44FE-B389-37387A87EFA5@oracle.com> References: <20150424162611.21167.3624.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-18.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:32:05 -0000 The update below addresses comments received from the Gen-ART and IANA = review. Many thanks to Elwyn and Amanda for their detailed feedback. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Apr 24, 2015, at 9:26 AM, 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-18.txt > Pages : 90 > Date : 2015-04-24 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) = specifications > are designed to make identity management in cloud based applications > and services easier. The specification suite builds upon experience > with existing schemas and deployments, placing specific emphasis on > simplicity of development and integration, while applying existing > authentication, authorization, and privacy models. Its intent is to > reduce the cost and complexity of user management operations by > providing a common user schema and extension model, as well as > binding documents to provide patterns for exchanging this schema > using HTTP protocol. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups and other resource types in JSON > format. This schema is intended for exchange and use with cloud > service providers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-18 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-18 >=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 Fri Apr 24 13:54: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 E24681ABC0F; Fri, 24 Apr 2015 13:54:26 -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 FIBYuTtc6dEy; Fri, 24 Apr 2015 13:54:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68B1A92F2; Fri, 24 Apr 2015 13:54:25 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424205425.21234.87547.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 13:54:25 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-17.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:54:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-17.txt Pages : 84 Date : 2015-04-24 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: http://tools.ietf.org/html/draft-ietf-scim-api-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-17 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 Apr 24 13:58: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 413E61A92F7; Fri, 24 Apr 2015 13:58: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 lH-odZWKF-Is; Fri, 24 Apr 2015 13:58:11 -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 8B0E81A92F3; Fri, 24 Apr 2015 13:58:11 -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 t3OKwAdY015744 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Apr 2015 20:58:10 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 t3OKwA6E002882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2015 20:58:10 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 t3OKw9ER022335; Fri, 24 Apr 2015 20:58:09 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Apr 2015 13:58:09 -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: <20150424205425.21234.87547.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 13:58:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <089ABE7A-B9BC-44C1-A147-C7C2EC3687FD@oracle.com> References: <20150424205425.21234.87547.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: scim@ietf.org, i-d-announce@ietf.org Subject: Re: [scim] I-D Action: draft-ietf-scim-api-17.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:58:13 -0000 This update addresses nits posted during the Gen-ART review by Francis = Dupont. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Apr 24, 2015, at 1: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: = Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Technology Nexus > Chuck Mortimore > Filename : draft-ietf-scim-api-17.txt > Pages : 84 > Date : 2015-04-24 >=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: > http://tools.ietf.org/html/draft-ietf-scim-api-17 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-17 >=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 Fri Apr 24 15:47: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 7053C1B29E3 for ; Fri, 24 Apr 2015 15:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FROM_12LTRDOM=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 7jHD6d9RRTAw for ; Fri, 24 Apr 2015 15:47:20 -0700 (PDT) Received: from heisenberg.jivesoftware.com (heisenberg.jivesoftware.com [204.93.66.11]) by ietfa.amsl.com (Postfix) with ESMTP id 461321A8A66 for ; Fri, 24 Apr 2015 15:47:20 -0700 (PDT) X-ASG-Debug-ID: 1429915634-059a6d270447c20002-bGWiwh Received: from mail.jiveland.com (phxcas01.corp.jiveland.com [10.81.2.11]) by heisenberg.jivesoftware.com with ESMTP id bwpBKmsPYBCUmd5R for ; Fri, 24 Apr 2015 15:47:19 -0700 (PDT) X-Barracuda-Envelope-From: patrick.radtke@jivesoftware.com Received: from MBX02.jiveland.com ([fe80::88ee:fad9:92d9:bdb3]) by PHXCAS01.jiveland.com ([10.81.2.11]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 15:47:19 -0700 From: Patrick Radtke To: SCIM WG Thread-Topic: Manager attribute wording suggestion X-ASG-Orig-Subj: Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Q== Date: Fri, 24 Apr 2015 22:47:18 +0000 Message-ID: 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_D1601605134Apatrickradtkejivesoftwarecom_" MIME-Version: 1.0 X-Barracuda-Connect: phxcas01.corp.jiveland.com[10.81.2.11] X-Barracuda-Start-Time: 1429915637 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.3880 1.0000 -0.0319 X-Barracuda-Spam-Score: -0.03 X-Barracuda-Spam-Status: No, SCORE=-0.03 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.18314 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [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: Fri, 24 Apr 2015 22:47:21 -0000 --_000_D1601605134Apatrickradtkejivesoftwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 --_000_D1601605134Apatrickradtkejivesoftwarecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C24D7DA6552974FBE349DA037BC88A4@jivesoftware.com> Content-Transfer-Encoding: quoted-printable
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 co=
mplex 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 des= cription be adjusted?
Since manager i= s 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




--_000_D1601605134Apatrickradtkejivesoftwarecom_-- From nobody Sat Apr 25 11:06: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 683951B2E6F for ; Sat, 25 Apr 2015 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg5sH1pQkcTn for ; Sat, 25 Apr 2015 11:06:11 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 88A911ACCF8 for ; Sat, 25 Apr 2015 11:06:11 -0700 (PDT) Received: from [192.168.87.158] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3PI69c15415146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 25 Apr 2015 14:06:10 -0400 Message-ID: <553BD78D.1070407@psu.edu> Date: Sat, 25 Apr 2015 14:06:05 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; 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] Schema and representation consistency 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, 25 Apr 2015 18:06:13 -0000 I've been working towards being able to lint SCIM resources against their respective SCIM schemas and have a few comments that would help with consistency: 1) The ResourceType, Schema and ServiceProviderConfiguration schemas are missing a their meta attributes. Without the "meta.resourceType attribute" being set to "Schema" there's no definitive way to declare that these JSON documents are in fact schemas. See number three below. 2) With the exception of the "Service Provider Configuration" schema, schemas with compound names use camel-case (and there are no spaces). I'd suggest changing the name attribute of this schema from "Service Provider Configuration" to "ServiceProviderConfiguration" for consistency. 3) It would be nice to be able to lint all resources against the schema(s) described in their "schemas" attribute. Current, there is no "schemas" attribute in the Schema resource but could schemas perhaps reference "urn:ietf:params:scim:schemas:core:2.0:Schema". 4) The "meta.location" attributes are full URIs in the resource representations but relative URIs in the schema definitions (or missing per number one above). Should they all be relative to the ServiceProvider's path? Thanks again for all the work that went into these specifications, they're really fun to develop against! Steve From nobody Sat Apr 25 12:28: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 67A581A87A5 for ; Sat, 25 Apr 2015 12:28:22 -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 dKY7jQsOPABf for ; Sat, 25 Apr 2015 12:28:21 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 35E4C1A876B for ; Sat, 25 Apr 2015 12:28:21 -0700 (PDT) Received: from [192.168.87.158] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3PJSIVT6041708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 25 Apr 2015 15:28:20 -0400 Message-ID: <553BEACF.3080304@psu.edu> Date: Sat, 25 Apr 2015 15:28:15 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; 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] Schema definition and representation inconsistency 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, 25 Apr 2015 19:28:22 -0000 The Schema Definition in section 7 (page 27) states that the "name" attribute is optional, but the Schema representation in section 8.7.2 defines this attribute (page 69) with: "required" : true, Steve From nobody Sat Apr 25 12:53: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 19E531ACEC1 for ; Sat, 25 Apr 2015 12:53:59 -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 O5in0AlONLx4 for ; Sat, 25 Apr 2015 12:53:57 -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 4E71E1ACEBA for ; Sat, 25 Apr 2015 12:53:57 -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 t3PJrto8002185 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Apr 2015 19:53:56 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 t3PJrtpB007892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 Apr 2015 19:53:55 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 t3PJrtTG027499; Sat, 25 Apr 2015 19:53:55 GMT Received: from [25.86.194.135] (/24.114.45.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Apr 2015 12:53:54 -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: <553BEACF.3080304@psu.edu> Date: Sat, 25 Apr 2015 12:53:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BAE82A7-E543-4714-8386-9C3FDF86570A@oracle.com> References: <553BEACF.3080304@psu.edu> To: Steve Moyer X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema definition and representation inconsistency 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, 25 Apr 2015 19:53:59 -0000 8.7.2 is just a representation. The service provider can alter optionality i= f optional in the normative text.=20 Phil > On Apr 25, 2015, at 12:28, Steve Moyer wrote: >=20 > The Schema Definition in section 7 (page 27) states that the "name" > attribute is optional, but the Schema representation in section 8.7.2 > defines this attribute (page 69) with: >=20 > "required" : true, >=20 > Steve >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sat Apr 25 12:56:37 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 6DCF11B2AA8 for ; Sat, 25 Apr 2015 12:56: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 RLCVNNScLd4n for ; Sat, 25 Apr 2015 12:56:33 -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 05D0D1B29BF for ; Sat, 25 Apr 2015 12:56:32 -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 t3PJuW9j003696 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Apr 2015 19:56:32 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 t3PJuV7e008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 Apr 2015 19:56:32 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3PJuUCS027854; Sat, 25 Apr 2015 19:56:31 GMT Received: from [25.86.194.135] (/24.114.45.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Apr 2015 12:56:30 -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: <553BD78D.1070407@psu.edu> Date: Sat, 25 Apr 2015 12:56:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <553BD78D.1070407@psu.edu> To: Steve Moyer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema and representation consistency 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, 25 Apr 2015 19:56:36 -0000 I believe the WG intent is that these are discovery endpoints not resources. Phil > On Apr 25, 2015, at 11:06, Steve Moyer wrote: > > I've been working towards being able to lint SCIM resources against > their respective SCIM schemas and have a few comments that would help > with consistency: > > 1) The ResourceType, Schema and ServiceProviderConfiguration schemas > are missing a their meta attributes. Without the "meta.resourceType > attribute" being set to "Schema" there's no definitive way to declare > that these JSON documents are in fact schemas. See number three below. > > 2) With the exception of the "Service Provider Configuration" schema, > schemas with compound names use camel-case (and there are no spaces). > I'd suggest changing the name attribute of this schema from "Service > Provider Configuration" to "ServiceProviderConfiguration" for consistency. > > 3) It would be nice to be able to lint all resources against the > schema(s) described in their "schemas" attribute. Current, there is no > "schemas" attribute in the Schema resource but could schemas perhaps > reference "urn:ietf:params:scim:schemas:core:2.0:Schema". > > 4) The "meta.location" attributes are full URIs in the resource > representations but relative URIs in the schema definitions (or missing > per number one above). Should they all be relative to the > ServiceProvider's path? > > Thanks again for all the work that went into these specifications, > they're really fun to develop against! > > Steve > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sat Apr 25 17:42: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 028C41B2FF9 for ; Sat, 25 Apr 2015 17:42: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, 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 3X_Oz6nlLc5V for ; Sat, 25 Apr 2015 17:42:22 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 5F8461ACF17 for ; Sat, 25 Apr 2015 17:42:22 -0700 (PDT) Received: from [192.168.87.158] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3Q0gJC95488710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Apr 2015 20:42:21 -0400 Message-ID: <553C3468.6040600@psu.edu> Date: Sat, 25 Apr 2015 20:42:16 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt References: <553BEACF.3080304@psu.edu> <7BAE82A7-E543-4714-8386-9C3FDF86570A@oracle.com> In-Reply-To: <7BAE82A7-E543-4714-8386-9C3FDF86570A@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema definition and representation inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 00:42:24 -0000 Phil, Sorry for the SPAM ... I see now that all the examples are marked non-normative and will make sure the rest of my development is based on the parts of the specification that are considered normative. Thanks for setting me straight! Steve On 04/25/2015 03:53 PM, Phil Hunt wrote: > 8.7.2 is just a representation. The service provider can alter optionality if optional in the normative text. > > Phil > >> On Apr 25, 2015, at 12:28, Steve Moyer wrote: >> >> The Schema Definition in section 7 (page 27) states that the "name" >> attribute is optional, but the Schema representation in section 8.7.2 >> defines this attribute (page 69) with: >> >> "required" : true, >> >> Steve >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- "One longs, in reading your code, to walk on all fours" - Voltaire From nobody Sat Apr 25 18:34: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 EF01E1B33AB for ; Sat, 25 Apr 2015 18:34:05 -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 gxBGM7tY_F8Y for ; Sat, 25 Apr 2015 18:34:04 -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 56C451B33A4 for ; Sat, 25 Apr 2015 18:33:16 -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 t3Q1XFG2008422 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Apr 2015 01:33:15 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 t3Q1XFUl000568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 26 Apr 2015 01:33:15 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3Q1XFiF011914; Sun, 26 Apr 2015 01:33:15 GMT Received: from [10.97.77.65] (/24.244.23.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Apr 2015 18:33:14 -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: <553C3468.6040600@psu.edu> Date: Sat, 25 Apr 2015 18:33:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <553BEACF.3080304@psu.edu> <7BAE82A7-E543-4714-8386-9C3FDF86570A@oracle.com> <553C3468.6040600@psu.edu> To: Steve Moyer X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema definition and representation inconsistency X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 01:34:06 -0000 Happy to help! Cheers Phil > On Apr 25, 2015, at 17:42, Steve Moyer wrote: >=20 > Phil, >=20 > Sorry for the SPAM ... I see now that all the examples are marked > non-normative and will make sure the rest of my development is based on > the parts of the specification that are considered normative. >=20 > Thanks for setting me straight! >=20 > Steve >=20 >> On 04/25/2015 03:53 PM, Phil Hunt wrote: >> 8.7.2 is just a representation. The service provider can alter optionalit= y if optional in the normative text.=20 >>=20 >> Phil >>=20 >>> On Apr 25, 2015, at 12:28, Steve Moyer wrote: >>>=20 >>> The Schema Definition in section 7 (page 27) states that the "name" >>> attribute is optional, but the Schema representation in section 8.7.2 >>> defines this attribute (page 69) with: >>>=20 >>> "required" : true, >>>=20 >>> Steve >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 > --=20 > "One longs, in reading your code, to walk on all fours" - Voltaire >=20 From nobody Sun Apr 26 06:27: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 846EC1A7001 for ; Sun, 26 Apr 2015 06:27:52 -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 tUptwS65UPfA for ; Sun, 26 Apr 2015 06:27:51 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 334961A6FFE for ; Sun, 26 Apr 2015 06:27:51 -0700 (PDT) Received: from [192.168.87.158] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3QDRmbF3346546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 26 Apr 2015 09:27:50 -0400 Message-ID: <553CE7D1.5040802@psu.edu> Date: Sun, 26 Apr 2015 09:27:45 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; 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] Schema DateTime section edits X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 13:27:52 -0000 Section 2.2.5 of the SCIM schema specification refers to XML-Schema, XML Constraints and a non-existent section 3.3.7. All three appear to be left-overs from previous versions/revisions of the document. The examples all seem to use the ISO 8601 date time format (with timezone) - Is the the expected format for a SCIM DateTime? Thanks! Steve From nobody Sun Apr 26 14:29: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 1B9D01A9153 for ; Sun, 26 Apr 2015 14:29:40 -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 7hUqMawV-v0a for ; Sun, 26 Apr 2015 14:29: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 D61411A90A3 for ; Sun, 26 Apr 2015 14:29:38 -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 t3QLTctY017462 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Apr 2015 21:29:38 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 t3QLTbnQ032762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 26 Apr 2015 21:29:37 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 t3QLTbJJ023502; Sun, 26 Apr 2015 21:29:37 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 26 Apr 2015 14:29:37 -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: <553CE7D1.5040802@psu.edu> Date: Sun, 26 Apr 2015 14:29:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B9182D5-3A9E-4A13-9674-6AEE21B72118@oracle.com> References: <553CE7D1.5040802@psu.edu> To: Steve Moyer X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema DateTime section edits X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 21:29:40 -0000 Steve, My understanding is that XML-Schema is consistent with ISO8601. But the = XML-Schema one is the referenced definition.=20 > In this version of this specification, two changes are made in order = to agree with existing usage. First, =C2=B7year=C2=B7 is permitted to = have the value zero. Second, the interpretation of =C2=B7year=C2=B7 = values is changed accordingly: a =C2=B7year=C2=B7 value of zero = represents 1 BCE, =E2=88=921 represents 2 BCE, etc. This representation = simplifies interval arithmetic and leap-year calculation for dates = before the common era (which may be why astronomers and others = interested in such calculations with the proleptic Gregorian calendar = have adopted it), and is consistent with the current edition of [ISO = 8601]. I suspect you weren=E2=80=99t looking at the correct version of = XML-Schema (this one has section 3.3.7) referenced in the specification: http://www.w3.org/TR/xmlschema11-2/#dateTime Phil @independentid www.independentid.com phil.hunt@oracle.com > On Apr 26, 2015, at 6:27 AM, Steve Moyer wrote: >=20 > Section 2.2.5 of the SCIM schema specification refers to XML-Schema, = XML > Constraints and a non-existent section 3.3.7. All three appear to be > left-overs from previous versions/revisions of the document. >=20 > The examples all seem to use the ISO 8601 date time format (with > timezone) - Is the the expected format for a SCIM DateTime? >=20 > Thanks! >=20 > Steve >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Apr 26 18:21:52 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 C6BB51B2D01 for ; Sun, 26 Apr 2015 18:21: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, 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 0sFZxDV_bmsH for ; Sun, 26 Apr 2015 18:21:50 -0700 (PDT) Received: from tr22n11a.aset.psu.edu (tr22g11a.aset.psu.edu [128.118.146.136]) (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 0A19F1B2CF8 for ; Sun, 26 Apr 2015 18:21:49 -0700 (PDT) Received: from [192.168.87.158] (pool-71-162-44-195.altnpa.east.verizon.net [71.162.44.195]) (authenticated bits=0) by tr22n11a.aset.psu.edu (8.14.3/8.14.3) with ESMTP id t3R1Lll55402828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Apr 2015 21:21:48 -0400 Message-ID: <553D8F29.2030204@psu.edu> Date: Sun, 26 Apr 2015 21:21:45 -0400 From: Steve Moyer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt References: <553CE7D1.5040802@psu.edu> <2B9182D5-3A9E-4A13-9674-6AEE21B72118@oracle.com> In-Reply-To: <2B9182D5-3A9E-4A13-9674-6AEE21B72118@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Schema DateTime section edits 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, 27 Apr 2015 01:21:51 -0000 Phil, Thanks once again for your explanation. I was looking for Section 3.3.7 in the SCIM schema specification because the link on that text points to https://tools.ietf.org/html/draft-ietf-scim-core-schema-18#section-3.3.7 (an anchor within the SCIM specification). Looking at the section you high-lighted, as well as the rest of the XML Schema DateTime section, I agree that this reference is correct (and matches the DateTime values shown in the examples). Steve On 04/26/2015 05:29 PM, Phil Hunt wrote: > Steve, > > My understanding is that XML-Schema is consistent with ISO8601. But the XML-Schema one is the referenced definition. >> In this version of this specification, two changes are made in order to agree with existing usage. First, ·year· is permitted to have the value zero. Second, the interpretation of ·year· values is changed accordingly: a ·year· value of zero represents 1 BCE, −1 represents 2 BCE, etc. This representation simplifies interval arithmetic and leap-year calculation for dates before the common era (which may be why astronomers and others interested in such calculations with the proleptic Gregorian calendar have adopted it), and is consistent with the current edition of [ISO 8601]. > I suspect you weren’t looking at the correct version of XML-Schema (this one has section 3.3.7) referenced in the specification: > http://www.w3.org/TR/xmlschema11-2/#dateTime > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Apr 26, 2015, at 6:27 AM, Steve Moyer wrote: >> >> Section 2.2.5 of the SCIM schema specification refers to XML-Schema, XML >> Constraints and a non-existent section 3.3.7. All three appear to be >> left-overs from previous versions/revisions of the document. >> >> The examples all seem to use the ISO 8601 date time format (with >> timezone) - Is the the expected format for a SCIM DateTime? >> >> Thanks! >> >> Steve >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim -- "One longs, in reading your code, to walk on all fours" - Voltaire From nobody Tue Apr 28 17:54: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 BC7741A9106; Tue, 28 Apr 2015 17:54:51 -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 vOBWWVFvWNR5; Tue, 28 Apr 2015 17:54:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE94C1A9103; Tue, 28 Apr 2015 17:54:48 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 17:54:48 -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 Discuss on draft-ietf-scim-api-17: (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, 29 Apr 2015 00:54:51 -0000 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). 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? 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. 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.). 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. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is really just here to see if better Authentication options are possible in current implementations and guidance for SCIM. 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. Thanks! From nobody Wed Apr 29 10:23:52 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 4230D1ACD83; Wed, 29 Apr 2015 10:23:49 -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, 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 Sn3SWsH6TO7u; Wed, 29 Apr 2015 10:23:47 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 01ACD1ACD78; Wed, 29 Apr 2015 10:23:47 -0700 (PDT) Received: by qgej70 with SMTP id j70so14264273qge.2; Wed, 29 Apr 2015 10:23:46 -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=Zw4ARYPRw4BHinLbiU7HBjepJ1nVy879NEpPurn8sGQ=; b=zat1J+a8eU8ZwkH35hQ3NHNmHoBLBxgav6l4aw5HswXvp4HQnbUuO+WaGuuBifpv2g DgNHAdXFm1zzKi1ThirRWt5FBzH5uaTqG7TRhcYIvgr7PA6xBWt+4TY7zsFuyUGYKddb mJlrWdSqJe0BZCKp5kiGTgurCFDmQdb76g/+mWkYrXt2G96wLtI9PEYoJ0yrgRCQ7xsK 7bu9iqJIA5i4okfENB5jn/ly8UZEGUGy2pcFzGJFJBY0kXlNDzkMFjT6Q9SLEdyGgaZY 4aOPStYZ1HmiMaQuE3gTvx3/+Y2P+nWKPkQG03q/WYRcjb1MBy7nOtQhBykKAx+kcybG wrsA== X-Received: by 10.229.97.138 with SMTP id l10mr153216qcn.25.1430328226321; Wed, 29 Apr 2015 10:23:46 -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 u68sm14937380qhd.36.2015.04.29.10.23.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Apr 2015 10:23:45 -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: <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> Date: Wed, 29 Apr 2015 13:23:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> To: Phil Hunt 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, 29 Apr 2015 17:23:49 -0000 Hi Phil, Just a quick response for now and more later. I'll find the specific refere= nces and registry for authentication used with OAuth. I'm the AD and have b= een reading their drafts carefully. Thanks, Kathleen Sent from my iPhone > 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. In OAut= h terms it is just a resource server. I wonder what we can point to as a ge= neral best practice for authentication and authorization.=20 >=20 > The use of OAuth was in part, a reflection of the growing popularity of OA= uth at the time of writing, and I believe a conscious attempt by the origina= l authors to discourage the use of simple password authentication such as RFC= 2617=E2=80=99s basic authentication. For this reason we did not want to use= Basic in the examples. =20 >=20 > Phil >=20 > phil.hunt@yahoo.com >=20 >> 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). > [PH] =20 >=20 > The text suggests OAuth is recommended but not required reflects what curr= ent implementers have been doing. I am opening to reducing this from =E2=80=9C= RECOMMENDED=E2=80=9D and allowing deployers to use other equally secure mech= anisms and to point out that the text based examples use bearer tokens to il= lustrate 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. O= Auth doesn=E2=80=99t care how authentication happens only that the parties a= re authenticated before authorizing. OAuth and for that matter OIDC both de= pend on using traditional (and emerging) authentication schemes to authentic= ate users. >=20 > That said, I see no reason why SCIM could not work directly with HOBA. SC= IM does not care, it merely assumes clients are authenticated (presumably vi= a session cookie or the authorization header). >=20 > Regarding asymmetric crypto, I believe you are referring to section 7.5. S= ee comment below... >=20 >=20 >>=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? >=20 > [PH] SCIM has no specific attachment to any authorization format. We just h= ad to pick one. =20 >=20 > Probably the one thing we should avoid is the use of Basic Auth as there i= s a strong tendency by deployers to treat SCIM as being the equivalent of LD= AP and perpetuate the mis-use of LDAP Bind as an authentication protocol as w= ell as promoting the use of single-factor authentication. I think a better a= pproach is to emphasize that SCIM is just an HTTP based Protocol (Applicatio= n) and uses HTTP mechanisms for authentication. =20 >=20 > Maybe we need some text indicating the use of =E2=80=9CBearer=E2=80=9D tok= ens 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. >=20 > [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. >=20 > [PH] The core schema draft does have more information on privacy as it is i= n the context of talking about attributes (which often have personal informa= tion) rather than protocol. >=20 > Would it be appropriate to explicitly call out the core schema security co= nsiderations 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. >=20 > [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. >=20 > [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 Aut= h in favour of any other mechanism that uses crypto. For example, Mutual-aut= h TLS would fit. There are many ways to fulfill this, including TLS, HOBA, O= Auth POP tokens and so on. >=20 > BTW=E2=80=A6I know of nothing in OAuth that suggests HTTP Basic is the def= ault. I think the point of using OAuth is to keep SCIM specifically out of d= oing authentication as per the charter. That said, there are many other mec= hanisms equally workable. >=20 >> Thanks! >=20 From nobody Wed Apr 29 13:08: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 B58DD1A07BC; Wed, 29 Apr 2015 13:08:35 -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 eyyrsIRKtE9R; Wed, 29 Apr 2015 13:08:31 -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 2403D1A0423; Wed, 29 Apr 2015 13:08:31 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so28941674lbc.1; Wed, 29 Apr 2015 13:08:29 -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=lUgsmqh9RvIKINeySi7Fm5YK8ZEoN+p408XjrR4ZAyg=; b=i4ufNU9c02kGwMv53ltlMt/H8V7ItSv3ECpsfQjiZeuJfoyXpRvupmRljCr8CIpter FuEMMQg7APNcqvfJ18Yr06FRq9v3hxtQzHx8SOddRscLFjMSH0HmrUvapJxIMzroD9jk pAZ+w/LUK97Jw4BlX/9fCGgIcbsTruo1FXDZ+xNYH3/hqYNRFmDAUwOpyI63JMn/Ok+F E3+IJT75+s0QpNAo3mDq9OCg95D/9Azzy75GOGdXANajG0GSwzZNfL+oKc6XLEI0X90Q l2ytWbYFWDVd7sIRbgKFUhc3b344mbpn79i5CfkTSRleUvRx8FdwitcTMV8xm3QWbfHV 6yOQ== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr640220lbb.75.1430338109608; Wed, 29 Apr 2015 13:08:29 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Wed, 29 Apr 2015 13:08:29 -0700 (PDT) In-Reply-To: References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> Date: Wed, 29 Apr 2015 16:08:29 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c382d0ee99570514e28a93 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, 29 Apr 2015 20:08:35 -0000 --001a11c382d0ee99570514e28a93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 a= nd > 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. I= n > 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 n= ot 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 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 > =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 (presumab= ly > via session cookie or the authorization header). > > > > Regarding asymmetric crypto, I believe you are referring to section 7.5= . > See comment below... > > > > > >> > >> 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. > > > > Probably the one thing we should avoid is the use of Basic Auth as ther= e > is a strong tendency by deployers to treat SCIM as being the equivalent o= f > LDAP and perpetuate the mis-use of LDAP Bind as an authentication protoco= l > 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. > > > > 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. > >> > >> > >> 3. Section 7.1 > >> I'm guessing the text on TLS versions is old and this was overlooked i= n > >> 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 fo= r > >> TLS 1.2 is no longer correct, it's widely implemented and is pretty mu= ch > >> 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. > >> > >> 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 privac= y, > >> 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.= ). > >> RFC6973 will help with current guidance and IETF considerations. If i= t > >> is a per element or attribute consideration, a pointer to that text fr= om > >> the privacy considerations section to the schema draft may be more > >> appropriate than covering the options in this draft. Then a better T= LS > >> 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? > >> > >> 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. > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> This is really just here to see if better Authentication options are > >> possible in current implementations and guidance for SCIM. > >> > >> 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 f= or > >> 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 ho= w > >> 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 doin= g > authentication as per the charter. That said, there are many other > mechanisms equally workable. > > > >> Thanks! > > > --=20 Best regards, Kathleen --001a11c382d0ee99570514e28a93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil and I chatted a bit and he is working up some text wi= th specific authentication options.=C2=A0 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 Moria= rty <kathleen.moriarty.ietf@gmail.com> wrote:=
Hi Phil,

Just a quick response for now and more later.=C2=A0 I'll find the speci= fic references and registry for authentication used with OAuth.=C2=A0 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.=C2=A0 At the end of the day, SCIM is just an HTTP pro= tocol (an application) and as such can use any of the normal HTTP mechanism= s. In OAuth terms it is just a resource server.=C2=A0 I wonder what we can = point to as a general best practice for authentication and authorization.

Yes, the issue I hit was tha= t the text of this draft said that OAuth is the authentication protocol, wh= en it's only an authorization protocol.=C2=A0 As such, a reader might j= ump to a conclusion that HTTP Basic is the way to go since it's the fir= st method (and default) for OAuth in the OAuth 2.0 framework.=C2=A0 Recent = drafts that mention the same registry where the supported authentication pr= otocols from the client to the AS have not updated that short list.=C2=A0 I= f you could rewrite the text to specify recommended authentication types, t= hat would be good.

and the 3 methods defined are stated again in the dyn regis= try draft(https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basica= lly 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 OAut=
h 2.0
         and does not have a client secret.
      *  "client_secret_post": The client uses the HTTP POST para=
meters
         defined in OAuth 2.0 section 2.3.1.
      *  "client_secret_basic": the client uses HTTP Basic define=
d 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 Authenticatio=
n
      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 o= f OAuth at the time of writing, and I believe a conscious attempt by the or= iginal authors to discourage the use of simple password authentication such= as RFC2617=E2=80=99s basic authentication.=C2=A0 For this reason we did no= t want to use Basic in the examples.

<= /div>
It's specified as the default in OAuth 2.0 when using a token= . =C2=A0see above.

Phil and I already chatted and = he's planning to specify recommendations that are more secure since SCI= M can use other authentication methods.

Please tak= e a look at the reference I gave that spells out the security consideration= s for bearer tokens.=C2=A0 They are not secure in of themselves and require= the use of TLS 1.2 to prevent attacks.=C2=A0 This needs to be clearly stat= ed as well with a reference included to the draft I provided that already d= etails the risks with bearer tokens.

Thanks,
=
Kathleen
=C2=A0
>
> Phil
>
> phil.hunt@yahoo.com
>
>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com&g= t; 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/d= iscuss-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.=C2=A0 I have a few items I'= ;d like to
>> discuss and have provided suggestions to help the discussion.=C2= =A0 I think
>> this should be fairly easy to get through.
>>
>> 1. OAuth is used for authorization and is limited to insecure meth= ods of
>> authentication via HTTP supported methods and of those, OAuth only= has a
>> few registered.=C2=A0 HTTP Basic authentication is the default, wh= ich is
>> horrible.=C2=A0 Later in this draft, SCIM encourages the use of as= ymmetric
>> crypto.=C2=A0 Can this be the preferred option and there be more d= etails
>> listed on how to do with (references)?
>>
>> What is specified now is really an authorization protocol, so you&= #39;ll need
>> to say if HTTP Basic is what's used for authentication with OA= uth
>> (default) or something else and then the security considerations f= or
>> OAuth bearer tokens and HHTP Basic.=C2=A0 Here are some links to h= elp:
>>
>> A reference to security considerations from this draft will be nee= ded:
>> see: https://datatracker.ietf.org/doc/draft-ietf-o= auth-assertions
>> Reference to the HTTP Basic draft will be needed to show the secur= ity
>> issues with this option:
>> https://datatracker.ietf.org/doc/draft-i= etf-httpauth-basicauth-update/
>>
>> OAuth can't use something like HOBA in RFC7486, which was desi= gned to
>> avoid the need for passwords when using HTTP Authentication.=C2=A0= Can SCIM
>> work directly with other HTTP Auth methods like HOBA? The OAuth fo= lks are
>> thinking about this problem, but aren't there yet (non-passwor= d 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 s= ecure mechanisms and to point out that the text based examples use bearer t= okens to illustrate the use of the authorization header and are not normati= ve.
>
> Regarding OAuth.=C2=A0 I don=E2=80=99t see why OAuth can=E2=80=99t use= HOBA.=C2=A0 OAuth doesn=E2=80=99t care how authentication happens only tha= t the parties are authenticated before authorizing.=C2=A0 OAuth and for tha= t matter OIDC both depend on using traditional (and emerging) authenticatio= n schemes to authenticate users.
>
> That said, I see no reason why SCIM could not work directly with HOBA.= =C2=A0 SCIM does not care, it merely assumes clients are authenticated (pre= sumably via session cookie or the authorization header).
>
> Regarding asymmetric crypto, I believe you are referring to section 7.= 5. See comment below...
>
>
>>
>> 2. The Holder-of-Key Assertions would get you a lot more security = than
>> the bearer token.=C2=A0 Why are all the examples bearer token?=C2= =A0 Or is there no
>> support for proof of possession of the key?
>
> [PH] SCIM has no specific attachment to any authorization format. We j= ust had to pick one.
>
> Probably the one thing we should avoid is the use of Basic Auth as the= re 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 protoc= ol as well as promoting the use of single-factor authentication.=C2=A0 I th= ink a better approach is to emphasize that SCIM is just an HTTP based Proto= col (Application) and uses HTTP mechanisms for authentication.
>
> 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. >>
>>
>> 3. Section 7.1
>> I'm guessing the text on TLS versions is old and this was over= looked in
>> last call.=C2=A0 The minimum version that should be supported is 1= .2.=C2=A0 TLS 1.0
>> is not considered a good starting point these days and browsers, s= uch as
>> Chrome show it as obsolete.=C2=A0 The text on implementation infor= mation for
>> TLS 1.2 is no longer correct, it's widely implemented and is p= retty much
>> the standard at the moment (1.3 will be soon enough).=C2=A0 Refere= ncing the
>> TLS BCP would be preferred,
>> https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bc= p/.=C2=A0 It not only
>> starts from v1.2, but includes preferred algorithms and other
>> configuration/implementation details to avoid attacks.=C2=A0 It is= close to
>> final publication and is ahead int he queue of this draft.
>
> [PH] Agreed, we should update this.
>>
>> 4. Section 7.2
>> Please review the Privacy Considerations,
>> = https://tools.ietf.org/html/rfc6973.=C2=A0 I was expecting to see more<= br> >> 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.=C2=A0 We care about this for the protection of user= 's privacy,
>> not just because it is required by laws.=C2=A0 You can leave menti= on of the
>> laws out, but it would be helpful to be specific on options to pro= tect
>> 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.).
>> RFC6973 will help with current guidance and IETF considerations.= =C2=A0 If it
>> is a per element or attribute consideration, a pointer to that tex= t from
>> the privacy considerations section to the schema draft may be more=
>> appropriate than covering the options in this draft.=C2=A0 Then=C2= =A0 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 i= nformation) rather than protocol.
>
> Would it be appropriate to explicitly call out the core schema securit= y considerations as foundational to the SCIM Protocol draft?
>>
>> I see there is some text on privacy n the schema draft, but it'= ;s probably
>> not enough.=C2=A0 I'll read that within the next few days and = give feedback to
>> help improve the text.
>
> [PH] I will await your comments.
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> This is really just here to see if better Authentication options a= re
>> possible in current implementations and guidance for SCIM.
>>
>> Section 7.5
>> While I like this bullet:
>>=C2=A0 =C2=A0o Avoid passwords and consider use of asymmetric crypt= ography based
>>=C2=A0 =C2=A0 =C2=A0credentials.
>> Earlier in this draft the use of OAuth is specified, and the defau= lt for
>> that is passwords=C2=A0 via HTTP basic.=C2=A0 If asymmetric crypto= is an option,
>> can that be the preferred option?=C2=A0 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 asy= mmetric crypto approaches. Again this was an attempt to discourage use of B= asic Auth in favour of any other mechanism that uses crypto. For example, M= utual-auth TLS would fit.=C2=A0 There are many ways to fulfill this, includ= ing 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.=C2=A0 That said, there are man= y other mechanisms equally workable.
>
>> Thanks!
>



--
=

Best regards,
Kathleen
--001a11c382d0ee99570514e28a93-- From nobody Wed Apr 29 13:27: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 4356C1A038F; Wed, 29 Apr 2015 13:27:52 -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 DoT-uieFy5kL; Wed, 29 Apr 2015 13:27:43 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 9780A1A1A7C; Wed, 29 Apr 2015 13:27:41 -0700 (PDT) Received: by laat2 with SMTP id t2so29129398laa.1; Wed, 29 Apr 2015 13:27:40 -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=aH11G+WC05PYuKxGRwpigubK31zvZvJnd/vYA0xUksg=; b=BggMqnpD4FS+notHP0xPwTulWh/gLtTCQe0/JCEKpkwbVa9cM2CagfhegUihhvn3vw ZjqRY3W0A+Qa1qTCyvYDkZByEOSnLoVaGAghQT9JZa36v+ucMT5j4kbwU8eImwU5Q1oJ xvJOL/Cbvp1Xbpz4GG+SXyEwVT9ac1vRjcNkW4tiUfE6BgUv19lu6N/SMpIDRz3b1Kjk m0OntSWQXVe5TF2H3pTBg2PpM5HEn71GvAYwqfLPDnFoc/4PTP6+cXEl0/VNtgDIJ3oV jaORua4XNSDGuAez7Wfx5SijmGzHonVT9Bm5xX/5r0t5xnF0Q2cwZROQFuBHFA+aJcYX 8q6Q== MIME-Version: 1.0 X-Received: by 10.112.29.36 with SMTP id g4mr779808lbh.56.1430339260063; Wed, 29 Apr 2015 13:27:40 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Wed, 29 Apr 2015 13:27:39 -0700 (PDT) In-Reply-To: <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> Date: Wed, 29 Apr 2015 16:27:39 -0400 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1133f99481246c0514e2cf0a 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, 29 Apr 2015 20:27:52 -0000 --001a1133f99481246c0514e2cf0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 > charter. The assumption was/is SCIM uses typical http authen/authz scheme= s > 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 an= d > 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 A= D > 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 protoco= l > >> (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 authenticati= on > >> such as RFC2617=E2=80=99s basic authentication. For this reason we di= d 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 clearl= y > > 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 al= l > >>>> 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 thi= nk > >>>> this should be fairly easy to get through. > >>>> > >>>> 1. OAuth is used for authorization and is limited to insecure method= s > 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 asymmetri= c > >>>> 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 neede= d: > >>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions > >>>> Reference to the HTTP Basic draft will be needed to show the securit= y > >>>> 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 t= o > >>>> avoid the need for passwords when using HTTP Authentication. Can SC= IM > >>>> work directly with other HTTP Auth methods like HOBA? The OAuth folk= s > >> 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 fr= om > >> =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use other equa= lly 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 HOB= A. OAuth doesn=E2=80=99t > >> care how authentication happens only that the parties are authenticate= d > >> before authorizing. OAuth and for that matter OIDC both depend on usi= ng > >> traditional (and emerging) authentication schemes to authenticate user= s. > >>> > >>> 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 Best regards, Kathleen --001a1133f99481246c0514e2cf0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

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

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

Good.=C2=A0 This needs to = be stated explicitly because of existing standards.=C2=A0 My concerns are b= ecause 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=C2=
=A0
=C2=A0 =C2=A0(see [RFC6749], [RFC6750]) is RECOMMENDED.=C2=A0

Because it says OAuth2 is recommended for aut= hentication 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 de= fault being HTTP Basic.=C2=A0 In my original discuss, I provided a link to = the updated version of Basic (in the RFC editor queue).=C2=A0 When you reco= mmend against it's use, you should refer to the security considerations= section of that draft, it updates 2617 for Basic.=C2=A0 Digest is in a sep= arate update.

Since bearer tokens are used, I have= to assume all of the security issues with those as well.=C2=A0 First is th= e IETF registered and supported authentication methods, then the lack of se= curity in the token itself.=C2=A0 Holder-of-key tokens require proof of pos= session (there is some crypto to do this).=C2=A0 The only thing you can do = to protect a bearer token is to use TLS and there needs to be a reference t= o 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.=C2=A0

Thank yo= u,
Kathleen


Thanks,

Phil

> On Apr 29, 2015, at 13:08, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wro= te:
>
> Phil and I chatted a bit and he is working up some text with specific<= br> > authentication options.=C2=A0 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 <
> kathleen.moriarty.= ietf@gmail.com> wrote:
>
>> Hi Phil,
>>
>> Just a quick response for now and more later.=C2=A0 I'll find = the specific
>> references and registry for authentication used with OAuth.=C2=A0 = 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.=C2=A0 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.=C2=A0 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.= =C2=A0 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.=C2=A0 Recent drafts that mention the same registry where th= e
> supported authentication protocols from the client to the AS have not<= br> > updated that short list.=C2=A0 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> > 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
>=C2=A0 =C2=A0 =C2=A0 String indicator of the requested authentication m= ethod for the
>=C2=A0 =C2=A0 =C2=A0 token endpoint.=C2=A0 Values defined by this speci= fication are:
>
>=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "none": The client is a public c= lient as defined in OAuth 2.0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and does not have a client secret. >=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "client_secret_post": The client= uses the HTTP POST parameters
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0defined in OAuth 2.0 section 2.3.1. >=C2=A0 =C2=A0 =C2=A0 *=C2=A0 "client_secret_basic": the clien= t uses HTTP Basic defined in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth 2.0 section 2.3.1
>
>=C2=A0 =C2=A0 =C2=A0 Additional values can be defined via the IANA OAut= h Token Endpoint
>=C2=A0 =C2=A0 =C2=A0 Authentication Methods Registry established in Sec= tion 4.2.
>=C2=A0 =C2=A0 =C2=A0 Absolute URIs can also be used as values for this = parameter
>=C2=A0 =C2=A0 =C2=A0 without being registered.=C2=A0 If unspecified or = omitted, the default
>=C2=A0 =C2=A0 =C2=A0 is "client_secret_basic", denoting HTTP = Basic Authentication
>=C2=A0 =C2=A0 =C2=A0 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=E2=80=99s basic authentication.=C2=A0 For this rea= son we did not want to
>> use Basic in the examples.
>
> It's specified as the default in OAuth 2.0 when using a token.=C2= =A0 see above.
>
> Phil and I already chatted and he's planning to specify recommenda= tions
> that are more secure since SCIM can use other authentication methods.<= br> >
> Please take a look at the reference I gave that spells out the securit= y
> considerations for bearer tokens.=C2=A0 They are not secure in of them= selves and
> require the use of TLS 1.2 to prevent attacks.=C2=A0 This needs to be = clearly
> stated as well with a reference included to the draft I provided that<= br> > 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.Moria= rty.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.=C2=A0 I have a few ite= ms I'd like to
>>>> discuss and have provided suggestions to help the discussi= on.=C2=A0 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.=C2=A0 HTTP Basic authentication is the def= ault, which is
>>>> horrible.=C2=A0 Later in this draft, SCIM encourages the u= se of asymmetric
>>>> crypto.=C2=A0 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= with OAuth
>>>> (default) or something else and then the security consider= ations for
>>>> OAuth bearer tokens and HHTP Basic.=C2=A0 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/draf= t-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/
>>>>
>>>> OAuth can't use something like HOBA in RFC7486, which = was designed to
>>>> avoid the need for passwords when using HTTP Authenticatio= n.=C2=A0 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 reflec= ts what
>> current implementers have been doing. I am opening to reducing thi= s 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 normati= ve.
>>>
>>> Regarding OAuth.=C2=A0 I don=E2=80=99t see why OAuth can=E2=80= =99t use HOBA.=C2=A0 OAuth doesn=E2=80=99t
>> care how authentication happens only that the parties are authenti= cated
>> before authorizing.=C2=A0 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 ref= erring to section 7.5=3D



--

Best regards,
Kath= leen
--001a1133f99481246c0514e2cf0a-- From nobody Wed Apr 29 13:31: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 7F3311A1B3D; Wed, 29 Apr 2015 13:31:44 -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 9j8MUpnSYmRa; Wed, 29 Apr 2015 13:31:40 -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 41CBE1A1A8D; Wed, 29 Apr 2015 13:31:40 -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 t3TKVcbI002010 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Apr 2015 20:31:38 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 t3TKVbIL003324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2015 20:31:38 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 t3TKVa13019095; Wed, 29 Apr 2015 20:31:37 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Apr 2015 13:31:36 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-BCDDC859-4167-4715-B1E4-8C8A7EE8D858 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 29 Apr 2015 13:31:33 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7F57BA4C-D4B7-4D62-9C6C-000DA1EE0024@oracle.com> References: <20150429005448.23555.98928.idtracker@ietfa.amsl.com> <0EFA5586-32C7-45DA-98A3-EBF121613C4D@yahoo.com> <87C1180B-5FFC-4ABA-B880-8AC46A22C9F0@yahoo.com> To: Kathleen Moriarty X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "draft-ietf-scim-api.ad@ietf.org" , Phil Hunt , "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:31:44 -0000 --Apple-Mail-BCDDC859-4167-4715-B1E4-8C8A7EE8D858 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks. I think we have a plan! Phil > 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 a= nd does not provide or mandate a method. >>=20 >> That said we have reservations about using 2617 mechanisms and prefer str= onger options. >=20 > Good. This needs to be stated explicitly because of existing standards. M= y 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 o= riginal discuss, I provided a link to the updated version of Basic (in the R= FC editor queue). When you recommend against it's use, you should refer to t= he 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 w= ith those as well. First is the IETF registered and supported authenticatio= n methods, then the lack of security in the token itself. Holder-of-key tok= ens 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 u= sers 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 limi= tations 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 an= d 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 A= D 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 protoco= l >> >> (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 t= o 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 o= f >> >> OAuth at the time of writing, and I believe a conscious attempt by the= >> >> original authors to discourage the use of simple password authenticati= on >> >> such as RFC2617=E2=80=99s basic authentication. For this reason we di= d not want to >> >> use Basic in the examples. >> > >> > It's specified as the default in OAuth 2.0 when using a token. see abo= ve. >> > >> > 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 clearl= y >> > 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 al= l >> >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >> >>>> 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 thi= nk >> >>>> this should be fairly easy to get through. >> >>>> >> >>>> 1. OAuth is used for authorization and is limited to insecure method= s of >> >>>> authentication via HTTP supported methods and of those, OAuth only h= as a >> >>>> few registered. HTTP Basic authentication is the default, which is >> >>>> horrible. Later in this draft, SCIM encourages the use of asymmetri= c >> >>>> 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 neede= d: >> >>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions >> >>>> Reference to the HTTP Basic draft will be needed to show the securit= y >> >>>> issues with this option: >> >>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-updat= e/ >> >>>> >> >>>> OAuth can't use something like HOBA in RFC7486, which was designed t= o >> >>>> avoid the need for passwords when using HTTP Authentication. Can SC= IM >> >>>> work directly with other HTTP Auth methods like HOBA? The OAuth folk= s >> >> 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 fr= om >> >> =E2=80=9CRECOMMENDED=E2=80=9D and allowing deployers to use other equa= lly 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 HOB= A. OAuth doesn=E2=80=99t >> >> care how authentication happens only that the parties are authenticate= d >> >> before authorizing. OAuth and for that matter OIDC both depend on usi= ng >> >> traditional (and emerging) authentication schemes to authenticate user= s. >> >>> >> >>> That said, I see no reason why SCIM could not work directly with HOBA= . >> >> SCIM does not care, it merely assumes clients are authenticated (presu= mably >> >> 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 --Apple-Mail-BCDDC859-4167-4715-B1E4-8C8A7EE8D858 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks. I think we have a plan!
Phil

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

Hi Phil,

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

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

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

2.  Authenticati=
on 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&nbs=
p;
=    (see [RFC6749], [RFC6750]) is RECOMMENDED. 

Because it says OAuth2 is recommended for authentication a= nd 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 HTT= P Basic.  In my original discuss, I provided a link to the updated vers= ion 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 se= curity issues with those as well.  First is the IETF registered and sup= ported authentication methods, then the lack of security in the token itself= .  Holder-of-key tokens require proof of possession (there is some cryp= to 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 ment= ioned in my original post so users know where to look to understand issues w= ith bearer tokens.

I hope that helps.

Is this is the approach we are looking for?
Yes, being e= xplicit would be very helpful as I'll assume defaults and limitations like r= egistered/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 referenc= es and am
> providing them inline here.
>
> On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty <
> kathleen.moriarty.i= etf@gmail.com> wrote:
>
>> Hi Phil,
>>
>> Just a quick response for now and more later.  I'll find the s= pecific
>> 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 H= TTP protocol
>> (an application) and as such can use any of the normal HTTP mechani= sms. In
>> OAuth terms it is just a resource server.  I wonder what we ca= n 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 me= thod for the
>      token endpoint.  Values defined by this specif= ication are:
>
>      *  "none": The client is a public client as de= fined in OAuth 2.0
>         and does not have a client secret.
= >      *  "client_secret_post": The client uses the H= TTP 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 Sect= ion 4.2.
>      Absolute URIs can also be used as values for this p= arameter
>      without being registered.  If unspecified or o= mitted, the default
>      is "client_secret_basic", denoting HTTP Basic Authe= ntication
>      Scheme as specified in Section 2.3.1 of OAuth 2.0.<= br> >
>
>
>
>>
>>> The use of OAuth was in part, a reflection of the growing popul= arity of
>> OAuth at the time of writing, and I believe a conscious attempt by t= he
>> original authors to discourage the use of simple password authentic= ation
>> such as RFC2617=E2=80=99s basic authentication.  For this reas= on we did not want to
>> use Basic in the examples.
>
> It's specified as the default in OAuth 2.0 when using a token.  se= e 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 thems= elves and
> require the use of TLS 1.2 to prevent attacks.  This needs to be c= learly
> 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<= br> >>>
>>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <
>> Kathleen.Moriar= ty.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 re= ply 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.ht= ml
>>>> for more information about IESG DISCUSS and COMMENT positio= ns.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be fou= nd here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-scim-ap= i/
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------------= -----------
>>>> DISCUSS:
>>>> -----------------------------------------------------------= -----------
>>>>
>>>> Thanks for your work on this draft.  I have a few item= s I'd like to
>>>> discuss and have provided suggestions to help the discussio= n.  I think
>>>> this should be fairly easy to get through.
>>>>
>>>> 1. OAuth is used for authorization and is limited to insecu= re methods of
>>>> authentication via HTTP supported methods and of those, OAu= th only has a
>>>> few registered.  HTTP Basic authentication is the defa= ult, which is
>>>> horrible.  Later in this draft, SCIM encourages the us= e 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, s= o you'll
>> need
>>>> to say if HTTP Basic is what's used for authentication with= OAuth
>>>> (default) or something else and then the security considera= tions for
>>>> OAuth bearer tokens and HHTP Basic.  Here are some lin= ks 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 th= e security
>>>> issues with this option:
>>>> https://datatracker.ietf.org/doc/d= raft-ietf-httpauth-basicauth-update/
>>>>
>>>> OAuth can't use something like HOBA in RFC7486, which was d= esigned to
>>>> avoid the need for passwords when using HTTP Authentication= .  Can SCIM
>>>> work directly with other HTTP Auth methods like HOBA? The O= Auth folks
>> are
>>>> thinking about this problem, but aren't there yet (non-pass= word auth
>>>> methods to then use Oauth authorization tokens).
>>> [PH]
>>>
>>> The text suggests OAuth is recommended but not required reflect= s 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 e= qually secure mechanisms
>> and to point out that the text based examples use bearer tokens to<= br> >> illustrate the use of the authorization header and are not normativ= e.
>>>
>>> Regarding OAuth.  I don=E2=80=99t see why OAuth can=E2=80=99= t use HOBA.  OAuth doesn=E2=80=99t
>> care how authentication happens only that the parties are authentic= ated
>> before authorizing.  OAuth and for that matter OIDC both depen= d on using
>> traditional (and emerging) authentication schemes to authenticate u= sers.
>>>
>>> That said, I see no reason why SCIM could not work directly wit= h HOBA.
>> SCIM does not care, it merely assumes clients are authenticated (pr= esumably
>> via session cookie or the authorization header).
>>>
>>> Regarding asymmetric crypto, I believe you are refe= rring to section 7.5=3D



--

Best regards,
Kathleen=
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-BCDDC859-4167-4715-B1E4-8C8A7EE8D858-- From nobody Wed Apr 29 16:06: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 D71681A8AB9 for ; Wed, 29 Apr 2015 16:06:42 -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, 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 1wHWn6_yELCn for ; Wed, 29 Apr 2015 16:06:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BC91A8AB6 for ; Wed, 29 Apr 2015 16:06:39 -0700 (PDT) Received: from BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) by BN1PR04MB251.namprd04.prod.outlook.com (10.255.205.148) with Microsoft SMTP Server (TLS) id 15.1.154.19; Wed, 29 Apr 2015 23:06:38 +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.148.16; Wed, 29 Apr 2015 23:06:35 +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.008; Wed, 29 Apr 2015 23:06:35 +0000 From: Kelly Grizzle To: Patrick Radtke , SCIM WG , "Phil Hunt (phil.hunt@oracle.com)" Thread-Topic: Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zg Date: Wed, 29 Apr 2015 23:06:34 +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: 3280F9B2009B763280FAFF authentication-results: jivesoftware.com; dkim=none (message not signed) header.d=none; x-originating-ip: [72.179.27.78] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB391; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB251; 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: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(164054003)(377454003)(51914003)(19580405001)(66066001)(92566002)(99286002)(2900100001)(87936001)(46102003)(5001960100002)(19580395003)(2950100001)(33656002)(19300405004)(19609705001)(62966003)(15975445007)(54356999)(77156002)(16236675004)(40100003)(5001770100001)(50986999)(76576001)(86362001)(2656002)(102836002)(74316001)(122556002)(106116001)(107886002)(19625215002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB392B1D6CC5322484E3A1C14E2D70BN1PR04MB392namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 23:06:34.9442 (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] 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, 29 Apr 2015 23:06:43 -0000 --_000_BN1PR04MB392B1D6CC5322484E3A1C14E2D70BN1PR04MB392namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Patrick ... 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 "manager" attribute that seem inconsisten= t. 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. " To me that says that a user may have a single manager, and 'value' and '$re= f' attributes are not required. 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. 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 rea= d (or for anyone coming from SCIM 1.1) it is not obvious that it has become= multi-valued. Thanks, Patrick --_000_BN1PR04MB392B1D6CC5322484E3A1C14E2D70BN1PR04MB392namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Patrick … thanks fo= r the feedback.

 <= /p>

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

 <= /p>

manager

   =
;   The user's manager.  A complex type that optionally allo=
ws service
    &nb=
sp; providers to represent organizational hierarchy by referencing the
    =
  "id" attribute of another User.

 <= /p>

Phil, do you agree?<= /o:p>

 <= /p>

--Kelly=

 <= /p>

From: scim [ma= ilto: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 “manager” attribute that seem inconsistent.

 

In 4.3 Enterprise User Sche= ma extension it says

"manager

   =
;   The user's manager.  A complex type that optionally allo=
ws service
    &nb=
sp; providers to represent organizational hierarchy by referencing the=

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

    &nb=
sp; value  The "id" of the SCIM resource representing the us=
er's


    &nb=
sp;    manager.  RECOMMENDED.


 

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


    &nb=
sp;    manager.  RECOMMENDED.




“





To me that says that a user=
 may have a single manager, and ‘value’ and ‘$ref’ =
attributes are not required.






 





However in the Schema secti=
on, manager is listed as "multiValued: true” and though subAttri=
butes of “$ref” and “value” have “required:fa=
lse” the description attribute
 says each is required.






 





If “value” and =
“$ref” aren’t required, can the Manager schema descriptio=
n be adjusted?






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






 






Thanks,






 






Patrick






 





 





 





 
--_000_BN1PR04MB392B1D6CC5322484E3A1C14E2D70BN1PR04MB392namprd_-- From nobody Wed Apr 29 16:22: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 A71C51A8A97 for ; Wed, 29 Apr 2015 16:22:45 -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 XHr6D1xpFhPT for ; Wed, 29 Apr 2015 16:22:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76BC1A8ABB for ; Wed, 29 Apr 2015 16:22:37 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 23:22:17 +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.008; Wed, 29 Apr 2015 23:22:17 +0000 From: Kelly Grizzle To: Samuel Erdtman , Haavar Valeur Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA//+VPgCAAH8NAIAFJmEAgDGOjtA= Date: Wed, 29 Apr 2015 23:22:17 +0000 Message-ID: References: <25626256-27A4-4FC3-8A2F-C56181677759@citrix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 328F58A4009B76328F59F1 authentication-results: erdtman.se; dkim=none (message not signed) header.d=none; x-originating-ip: [72.179.27.78] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB392; 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:BN1PR04MB392; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB392; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43544003)(377454003)(51704005)(479174004)(16236675004)(19625215002)(76576001)(40100003)(2656002)(102836002)(15975445007)(2900100001)(19609705001)(99286002)(19300405004)(77156002)(62966003)(2950100001)(74316001)(106116001)(551544002)(46102003)(19580405001)(66066001)(5001770100001)(575784001)(76176999)(92566002)(93886004)(87936001)(33656002)(19580395003)(86362001)(54356999)(19617315012)(50986999)(122556002)(5001960100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB3929B8118B8CBD99043B892E2D70BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 23:22:17.3085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB392 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Organizational unit SCIM extension 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 23:22:45 -0000 --_000_BN1PR04MB3929B8118B8CBD99043B892E2D70BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFhdmFyIOKApiBJIGRlZmluaXRlbHkgc2VlIHRoZSBiZW5lZml0IGhlcmUgZm9yIHByb3ZpZGVy cyB0aGF0IGFyZSBwdXR0aW5nIFNDSU0gb24gdG9wIG9mIGEgZGlyZWN0b3J5LiAgSSBjYW4gc2Vl IGEgcHJldHR5IHNpbXBsZSBzdGFuZGFyZGl6ZSBleHRlbnNpb24gdGhhdCB3b3VsZCBwcm92aWRl IHRoaXMuICBJdCB3b3VsZCBiZSB0aGUgYWRkaXRpb24gb2YgYSBzaW5nbGUgYXR0cmlidXRlIChp biBhbiBleHRlbnNpb24pIGFuZCBhIG5ldyBlbmRwb2ludCB3aXRoIGFuIGFzc29jaWF0ZWQgc2No ZW1hLiAgVGhlIFVzZXIgKGFuZCBwcm9iYWJseSBHcm91cCkgcmVzb3VyY2VzIHdvdWxkIGFkZCBh biBPVSByZWZlcmVuY2UgdG8gdGhlaXIgc2NoZW1hLiAgRm9yIGV4YW1wbGU6DQoNCnsNCiAgImlk IjogIjgyNzM0MSIsDQogICJ1c2VybmFtZSI6ICJrZ3JpenpsZSIsDQogICJzb21lOmV4dGVuc2lv bjp1cm4iOiB7DQogICAgIm91Ijogew0KICAgICAgInZhbHVlIjogIjA5ODg5ODIzNDAiLA0KICAg ICAgIiRyZWYiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS92Mi9PcmdVbml0cy8wOTg4OTgyMzQwIg0K ICAgIH0NCiAgfQ0KfQ0KDQpUaGUgZW5kcG9pbnQgd291bGQgYmUgYSBmbGF0IGxpc3Qgb2Ygb3Jn IHVuaXRzIChpZSDigJMgdGhleSB3b3VsZCBhbGwgYmUgZGlyZWN0bHkgdW5kZXIgdGhlIC9PcmdV bml0cyBlbmRwb2ludCksIGJ1dCB3b3VsZCBiZSBoaWVyYXJjaGljYWwgdGhyb3VnaCBwYXJlbnQg cmVsYXRpb25zaGlwcy4NCg0KR0VUIC9PcmdVbml0cw0KDQpbDQogIHsNCiAgICAiaWQiOiAiMDk4 NzQ3ODg3MjczNCINCiAgICAibmFtZSI6ICJPVSAwIiwNCiAgfSwNCiAgew0KICAgICJpZCI6ICI4 Nzc5ODcyMzg5NzQiDQogICAgIm5hbWUiOiAiT1UgMSIsDQogICAgInBhcmVudCI6IHsNCiAgICAg ICJ2YWx1ZSI6ICIwOTg3NDc4ODcyNzM0IiwNCiAgICAgICIkcmVmIjogImh0dHBzOi8vZXhhbXBs ZS5jb20vdjIvT3JnVW5pdHMvMDk4NzQ3ODg3MjczNCIsDQogICAgICAiZGlzcGxheU5hbWUiOiAi T1UgMCINCiAgICB9DQogIH0NCl0NCg0KVGhlIG9ubHkgdHJpY2sgaGVyZSB3b3VsZCBiZSBzZWFy Y2ggZm9yIG9iamVjdHMgaW4g4oCcT1UgMOKAnS4gIFNob3VsZCByZXNvdXJjZXMgaW4g4oCcT1Ug MeKAnSBhbHNvIGJlIHJldHVybmVkPyAgUGVyaGFwcyBhIG5ldyBxdWVyeSBwYXJhbWV0ZXIgY291 bGQgdGFrZSBjYXJlIG9mIHdoZXRoZXIgdG8gZG8gYSBzdWItdHJlZSBzZWFyY2ggb3Igbm90Lg0K DQpJIHRoaW5rIFNhbXVlbOKAmXMgaWRlYSB3b3VsZCBtYXAgd2VsbCB0byBhIGRpcmVjdG9yeSwg YnV0IHRoZXJlIGlzbuKAmXQgYSBnb29kIGZhY2lsaXR5IGZvciB0aGF0IHR5cGUgb2YgZXh0ZW5z aW9uIGluIFNDSU0uDQoNCi0tS2VsbHkNCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbXVlbCBFcmR0bWFuDQpTZW50OiBTdW5kYXksIE1h cmNoIDI5LCAyMDE1IDU6MjUgQU0NClRvOiBIYWF2YXIgVmFsZXVyDQpDYzogc2NpbUBpZXRmLm9y ZzsgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKQ0KU3ViamVjdDogUmU6IFtzY2ltXSBPcmdhbml6 YXRpb25hbCB1bml0IFNDSU0gZXh0ZW5zaW9uDQoNCkhpLA0KDQpEb2VzIG5vdCBzZWVtIGxpa2Ug dGhlcmUgaXMgYSBjb25zZW5zdXMgdGhhdCBPVSBoaWVyYXJjaHkgaXMgbmVlZGVkLCBob3dldmVy IGEgc3VnZ2VzdGlvbiBmb3IgYSBzb2x1dGlvbiBjYW1lIHRvIG1pZCBzbyBJIGp1c3QgdGhvdWdo dCBJIHNlbmQgaXQgb3V0IGFuZCBzZSB3aGF0IHBlb3BsZSB0aGluay4NCg0KV2hhdCBhYm91dCB1 c2luZyB0aGUgcGF0aCB0byBjcmVhdGUgdGhlIGhpZXJhcmNoaWNhbCBPVSBzdHJ1Y3R1cmUNCg0K PGJhc2UtcGF0aD4vPG91MT5Vc2Vycw0KPGJhc2UtcGF0aD4vPG91MT5Hcm91cHMNCjxiYXNlLXBh dGg+LzxvdTE+LzxvdTI+VXNlcnMNCjxiYXNlLXBhdGg+LzxvdTE+LzxvdTI+R3JvdXBzDQoNCldo ZW4gc2VhcmNoaW5nIHVuZGVyIDxiYXNlLXBhdGg+LzxvdTE+IHJlc3VsdHMgd291bGQgaW5jbHVk ZSBVc2Vycy9Hcm91cHMgdW5kZXIgPGJhc2UtcGF0aD4vPG91MT4vPG91Mj4gYnV0IG5vdCB0aGUg b3RoZXIgd2F5IGFyb3VuZC4gSSBkb250IGtub3cgaWYgdGhpcyBjcmVhdGVzIGVub3VnaCBmbGV4 aWJpbGl0eSBlLmcNCndpdGggdGhlIGZvbGxvd2luZyBzdHJ1Y3R1cmUNCjxiYXNlLXBhdGg+Lzxv dTE+LzxvdTI+VXNlcnMNCjxiYXNlLXBhdGg+LzxvdTM+LzxvdTQ+VXNlcnMNCkl0IHdvdWxkIGJl IGhhcmQgdG8gc2VhcmNoIGZvciB1c2VycyBpbiBib3RoIG91MiBhbmQgb3U0IHdpdGggb25lIHJl cXVlc3QuDQoNCkJlc3QgcmVnYXJkcw0KLy9TYW11ZWwNCg0KDQoNCg0KDQoNCg0KT24gV2VkLCBN YXIgMjUsIDIwMTUgYXQgOTo0NiBQTSwgSGFhdmFyIFZhbGV1ciA8aGFhdmFyLnZhbGV1ckBjaXRy aXguY29tPG1haWx0bzpoYWF2YXIudmFsZXVyQGNpdHJpeC5jb20+PiB3cm90ZToNCkkgbWlnaHQg YmUgd3JvbmcsIEnigJl2ZSBub3QgZ29uZSB0b28gZGVlcCBpbnRvIHRoZSB1c2VyIGFkbWluaXN0 cmF0aW9uIG9mIGRpZmZlcmVudCBwcm92aWRlcnMsIGJ1dCBteSBmaXJzdCBpbXByZXNzaW9uIGlz IHRoYXQgc2FsZXNmb3JjZSAoYXBwYXJlbnRseSBhY3R1YWxseSBmbGF0LWlzaCksIGdvb2dsZSwg YW1hem9uIGFuZCBTQVAgaGF2ZSBzb21lIHNvcnQgb2YgaGllcmFyY2h5LiBJ4oCZbSBzdXJlIG1l bWJlcnMgb2YgdGhpcyBXRyBoYXZlIG1vcmUgZGV0YWlsZWQga25vd2xlZGdlIG9mIHRoZSBkaWZm ZXJlbnQgcHJvdmlkZXJzLg0KDQpJIGhhdmUgbm90IHB1dCBtdWNoIHRob3VnaHQgaW50byBob3cg dGhpcyBjYW4gYmUgcmVwcmVzZW50ZWQgYXMgYW4gZXh0ZW5zaW9uLiBJIHdhbnRlZCB0byBzZWUg aWYgdGhlcmUgaGFzIGJlZW4gYW55IHdvcmsgaW4gdGhpcyBhcmVhIGFscmVhZHksIG9yIGlmIGl0 4oCZcyBldmVuIG5lZWRlZC4gU2VlbXMgbGlrZSBpZiBpdOKAmXMgZXhwZWN0ZWQgdG8gbWFuYWdl IE9VcyBleHRlcm5hbCB0byBTQ0lNLCBhbmQgdGhlbiBoYXZlIGEgc29mdCByZWZlcmVuY2Ugb24g dGhlIHVzZXIgdXNlciBvYmplY3QsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGhhdmUgYW4gZXh0 ZW5zaW9uIGRhdGEgbW9kZWwgZm9yIE9VcyB0aGF0IGFyZSBub3QgaW50cnVzaXZlIHRvIHRoZSBj b3JlIHNjaGVtYS4NCg0KPiBPbiBNYXIgMjUsIDIwMTUsIGF0IDM6MTEgUE0sIE1vcnRlemEgQW5z YXJpIChtb3JhbnNhcikgPG1vcmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28u Y29tPj4gd3JvdGU6DQo+DQo+IFRvIGJlIGNsZWFyIG15IHByZXZpb3VzIHJlc3BvbnNlIHRvIHlv dXIgZW1haWwgYW5kIHRoaXMgZW1haWwgYXJlIHdpdGggbWUNCj4gd2VhcmluZyBpbXBsZW1lbnRl ciBoYXQgYW5kIG5vdCBzcGVha2luZyBhcyBjaGFpci4NCj4NCj4gSSBjYW7CuXQgc2VlIGhvdyB3 ZSBjb3VsZCBhZGQgdGhlIE9VIGhpZXJhcmNoeSBhcyBhbiBleHRlbnNpb24gb2YgdGhlIFNDSU0u DQo+IFRoYXQgd291bGQgYmUgYSBwcmV0dHkgaW50cnVzaXZlIGNoYW5nZSBhbmQgcmVxdWlyZSBj aGFuZ2VzIHRvIGFsbW9zdA0KPiBldmVyeXRoaW5nIGluIFNDSU0uIEhvd2V2ZXIsIGlmIHlvdSBo YXZlIGlkZWFzIGhvdyB0aGlzIGNvdWxkIGJlIGRvbmUsIEkNCj4gd291bGQgbG92ZSB0byBoZWFy IHRoZW0uDQo+DQo+IEFsc28gaWYgeW91IGtub3cgb2YgU2FhUyBzb2x1dGlvbnMgd2hlcmUgdGhl IGlkZW50aXR5IHNwYWNlIGlzDQo+IGhpZXJhcmNoaWNhbCwgcGxlYXNlIHNoYXJlIHRoYXQuIEkg c3RhcnRlZCB0aGlua2luZyB0aGUgc2FtZSB3YXkgYnV0DQo+IGRpZG7CuXQgZmluZCBhbnkgdmVu ZG9yIHRoYXQgc3VwcG9ydGVkIGl0IG9yIGN1c3RvbWVycyB0aGF0IGFza2VkIGZvciBpdC4NCj4N Cj4NCj4gQ2hlZXJzLA0KPiBNb3J0ZXphDQo+DQo+IE9uIDMvMjUvMTUsIDI6MzMgUE0sICJIYWF2 YXIgVmFsZXVyIiA8aGFhdmFyLnZhbGV1ckBjaXRyaXguY29tPG1haWx0bzpoYWF2YXIudmFsZXVy QGNpdHJpeC5jb20+PiB3cm90ZToNCj4NCj4+IEkgdGhpbmsgaGF2aW5nIHRoZSBPVXMgYmUgaGll cmFyY2hpY2FsIHNob3VsZCBiZSBhbiBvcHRpb24gaWYgYW4NCj4+IGV4dGVuc2lvbiB3YXMgYWRk ZWQsIGJ1dCBldmVuIHdpdGhvdXQgdGhhdCBJIHdvdWxkIHRoaW5rIHRoYXQgaXTCuXMNCj4+IGJl bmVmaWNpYWwgdG8gaGF2ZSBPVXMgaW4gdGhlIEFQSS4gV2l0aG91dCBPVSByZXByZXNlbnRlZCBp biB0aGUgc2NoZW1hDQo+PiB5b3Ugd291bGQgaGF2ZSBsb29zZSByZWZlcmVuY2VzIHRvIG9iamVj dHMgdGhhdCBhcmUgY3JlYXRlZCB3aXRoDQo+PiBwcm9wcmlldGFyeSBBUElzIG9yIHNjaGVtYXMu DQo+Pg0KPj4gScK5bSBhIGxpdHRsZSBzdXJwcmlzZWQgdGhhdCB0aGUgY29uc2Vuc3VzIHdhcyB0 aGF0IFNhYVMgcHJvdmlkZXJzIGhhdmUgYQ0KPj4gZmxhdCBPVSBzdHJ1Y3R1cmUuIEZyb20gd2hh dCBJwrl2ZSBzZWVuLCBhIGxvdCBvZiBwcm92aWRlcnMgc3VwcG9ydCBhDQo+PiBoaWVyYXJjaHkg KHdpdGggYSBzb21lIG5vdGFibGUgZXhjZXB0aW9ucykuIEkgd291bGQgdGhpbmsgaXQgd291bGQg YmUgYQ0KPj4gY29tbW9uIHVzZSBjYXNlIGZvciBsYXJnZXIgY3VzdG9tZXJzIG9mIGEgU2FhUyBw cm92aWRlciB0byBzeW5jIHRoZWlyDQo+PiBlbXBsb3llZSBkaXJlY3RvcnkgdG8gdGhlIHByb3Zp ZGVyLCBpbmNsdWRpbmcgT1VzLiBUaGUgT1VzIHdvdWxkIGJlIHVzZWQNCj4+IHRvIHNldCBwYXNz d29yZCBwb2xpY2VzLCBmZWRlcmF0ZWQgbG9naW4gc2V0dGluZ3MgYW5kIGFkbWluaXN0cmF0aW9u IG9yDQo+PiBwcm9kdWN0IHByaXZpbGVnZXMgb24gdGhlIFNhYVMgcHJvdmlkZXIgc2lkZS4NCj4+ DQo+PiBIYXZlIHRoZSBTYWFTIHByb3ZpZGVycyBjaGFuZ2VkIHRoaXMgb3ZlciB0aGUgeWVhcnMs IG9yIGRvIEkgaGF2ZSB0aGUNCj4+IHdyb25nIGltcHJlc3Npb24/DQo+Pg0KPj4NCj4+PiBPbiBN YXIgMjUsIDIwMTUsIGF0IDExOjQ3IEFNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpDQo+Pj4g PG1vcmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4gd3JvdGU6DQo+ Pj4NCj4+PiBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgaGllcmFyY2hpY2FsIG9yZ2FuaXphdGlv biBvZiByZXNvdXJjZQ0KPj4+IGluc3RhbmNlcywNCj4+PiB3ZSBoYWQgdGhhdCBkaXNjdXNzaW9u IGluIHRoZSB2ZXJ5IGVhcmx5IGRheXMgb2YgU0NJTSAxLjAgd29yay4gSQ0KPj4+IGFjdHVhbGx5 DQo+Pj4gdGhpbmsgSSBicm91Z2h0IHRoYXQgdXAgYXMgYSByZXF1ZXN0IGJ1dCBhZnRlciB0YWxr aW5nIHRvIG90aGVyIHZlbmRvcnMNCj4+PiBpdA0KPj4+IHNlZW1lZCBldmVyeSBTYWFTIHNlcnZp Y2Ugd2FzIGRvaW5nIGEgZmxhdCBuYW1lIHNwYWNlIGZvciB1c2VycyAmIGdyb3Vwcw0KPj4+IGFu ZCBub2JvZHkgaGFkIGEgcmVxdWVzdCBmcm9tIGN1c3RvbWVycyBmb3IgYSBoaWVyYXJjaGljYWwg bW9kZWwgc28gdGhlDQo+Pj4gZmVhdHVyZSB3YXMgZHJvcHBlZC4NCj4+Pg0KPj4+DQo+Pj4gQ2hl ZXJzLA0KPj4+IE1vcnRlemENCj4+Pg0KPj4+IE9uIDMvMjQvMTUsIDY6NTQgUE0sICJIYWF2YXIg VmFsZXVyIiA8aGFhdmFyLnZhbGV1ckBjaXRyaXguY29tPG1haWx0bzpoYWF2YXIudmFsZXVyQGNp dHJpeC5jb20+PiB3cm90ZToNCj4+Pg0KPj4+PiBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lv biBhcm91bmQgYSBzdGFuZGFyZCBTQ0lNIGV4dGVuc2lvbiB0aGF0DQo+Pj4+IGhhbmRsZXMgb3Jn YW5pemF0aW9uYWwgdW5pdHMgKE9VKT8gQSBxdWljayBnb29nbGUgc2VhcmNoIGNhbWUgdXAgd2l0 aCBhDQo+Pj4+IGNvdXBsZSBvZiBlbWFpbHMgZnJvbSAzIHllYXJzIGFnbywgYnV0IG5vIHJlYWwg c3Vic2lkZW5jZS4NCj4+Pj4NCj4+Pj4gSWYgdGhlcmUgaGFzIG5vdCBiZWVuIGFueSBkaXNjdXNz aW9uIGFyb3VuZCB0aGlzLCBpcyB0aGVyZSBhIHJlYXNvbiBmb3INCj4+Pj4gaXQ/DQo+Pj4+DQo+ Pj4+IEJlc3QNCj4+Pj4gSGFhdmFyDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IHNjaW0gbWFpbGluZyBsaXN0DQo+Pj4+IHNjaW1AaWV0 Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQo+Pj4+DQo+Pj4+IGh0dHBzOi8vc2VjdXJlLXdl Yi5jaXNjby5jb20vMU5UNXpXcV9WLXh1OVFDUi02Qi1UdDdYbjBGZVRSWmlfOG42OEQ0ejlTaQ0K Pj4+PiBFSGRjV1hpTjJjeGJ5ZThmNDl3c1h4elBoV0psR19lakIzNDdNcy0xUzU4cnVoVmN3SWRy NEZCcUNlZHJUZURic1hXblpQSEwNCj4+Pj4gMExMbzVhNnRFTUxUUDM1WkJRQ1lBdkliTWROdlA3 SjJHZ0VXNWVkTGtDcHNUTFZDSnppYUVrWHRrL2h0dHBzJTNBJTJGJTJGDQo+Pj4+IGh0dHA6Ly9z ZWN1cmUtd2ViLmNpc2NvLmNvbS8xRXU2X1FHcDdUMjNPeWJneU82UjBZQmNyazJnQTVINl9WcS1B cmJlR1Q3Q09HT2NJQ3dRQnlWQlVwbE1yOE84Q2xISUxpOU82bE5vZlJXaUZXSDZ5d1hnUHdmMEo1 dlpMOFR1SkFZWFJWYWNXbXVocUU3d1VnS2wzNGhmczBmLU1ycHlrMGNaVUVmN2sxZ0ZvdFlXYk1k MF8yQldNUl9OdEdOQUkzcFl2XzZLcnREeDNkSjAwc2VNbVBpZ3NMTlV1L2h0dHAlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltDQo+Pj4NCj4+Pg0KPj4NCj4N Cj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNj aW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_BN1PR04MB3929B8118B8CBD99043B892E2D70BN1PR04MB392namprd_ 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 N0QiPkhhYXZhciDigKYgSSBkZWZpbml0ZWx5IHNlZSB0aGUgYmVuZWZpdCBoZXJlIGZvciBwcm92 aWRlcnMgdGhhdCBhcmUgcHV0dGluZyBTQ0lNIG9uIHRvcCBvZiBhIGRpcmVjdG9yeS4mbmJzcDsg SSBjYW4gc2VlIGEgcHJldHR5IHNpbXBsZSBzdGFuZGFyZGl6ZSBleHRlbnNpb24gdGhhdA0KIHdv dWxkIHByb3ZpZGUgdGhpcy4mbmJzcDsgSXQgd291bGQgYmUgdGhlIGFkZGl0aW9uIG9mIGEgc2lu Z2xlIGF0dHJpYnV0ZSAoaW4gYW4gZXh0ZW5zaW9uKSBhbmQgYSBuZXcgZW5kcG9pbnQgd2l0aCBh biBhc3NvY2lhdGVkIHNjaGVtYS4mbmJzcDsgVGhlIFVzZXIgKGFuZCBwcm9iYWJseSBHcm91cCkg cmVzb3VyY2VzIHdvdWxkIGFkZCBhbiBPVSByZWZlcmVuY2UgdG8gdGhlaXIgc2NoZW1hLiZuYnNw OyBGb3IgZXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OiAmcXVvdDs4MjczNDEmcXVvdDssPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmcXVvdDt1c2VybmFtZSZxdW90OzogJnF1b3Q7a2dyaXp6 bGUmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmcXVvdDtzb21l OmV4dGVuc2lvbjp1cm4mcXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O291JnF1b3Q7OiB7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt2YWx1ZSZxdW90Ozog JnF1b3Q7MDk4ODk4MjM0MCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OyRyZWYmcXVvdDs6ICZxdW90O2h0dHBz Oi8vZXhhbXBsZS5jb20vdjIvT3JnVW5pdHMvMDk4ODk4MjM0MCZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj59PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgZW5kcG9pbnQgd291bGQgYmUgYSBmbGF0IGxpc3Qgb2Ygb3JnIHVuaXRzIChpZSDi gJMgdGhleSB3b3VsZCBhbGwgYmUgZGlyZWN0bHkgdW5kZXIgdGhlIC9PcmdVbml0cyBlbmRwb2lu dCksIGJ1dCB3b3VsZCBiZSBoaWVyYXJjaGljYWwgdGhyb3VnaCBwYXJlbnQgcmVsYXRpb25zaGlw cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkdFVCAvT3JnVW5pdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPls8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OiAmcXVvdDswOTg3NDc4ODcyNzM0JnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtuYW1l JnF1b3Q7OiAmcXVvdDtPVSAwJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsgfSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OiAm cXVvdDs4Nzc5ODcyMzg5NzQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O09VIDEmcXVvdDssPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtwYXJlbnQm cXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDswOTg3NDc4ODcyNzM0JnF1b3Q7 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7JHJlZiZxdW90OzogJnF1b3Q7aHR0cHM6Ly9leGFtcGxlLmNvbS92Mi9PcmdV bml0cy8wOTg3NDc4ODcyNzM0JnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGlzcGxheU5hbWUmcXVvdDs6ICZx dW90O09VIDAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IH08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG9ubHkgdHJpY2sgaGVyZSB3b3Vs ZCBiZSBzZWFyY2ggZm9yIG9iamVjdHMgaW4g4oCcT1UgMOKAnS4mbmJzcDsgU2hvdWxkIHJlc291 cmNlcyBpbiDigJxPVSAx4oCdIGFsc28gYmUgcmV0dXJuZWQ/Jm5ic3A7IFBlcmhhcHMgYSBuZXcg cXVlcnkgcGFyYW1ldGVyIGNvdWxkIHRha2UgY2FyZSBvZiB3aGV0aGVyDQogdG8gZG8gYSBzdWIt dHJlZSBzZWFyY2ggb3Igbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBTYW11ZWzigJlzIGlkZWEgd291 bGQgbWFwIHdlbGwgdG8gYSBkaXJlY3RvcnksIGJ1dCB0aGVyZSBpc27igJl0IGEgZ29vZCBmYWNp bGl0eSBmb3IgdGhhdCB0eXBlIG9mIGV4dGVuc2lvbiBpbiBTQ0lNLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1LZWxs eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2NpbSBbbWFpbHRv OnNjaW0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2FtdWVsIEVyZHRt YW48YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAyOSwgMjAxNSA1OjI1IEFNPGJyPg0K PGI+VG86PC9iPiBIYWF2YXIgVmFsZXVyPGJyPg0KPGI+Q2M6PC9iPiBzY2ltQGlldGYub3JnOyBN b3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0g T3JnYW5pemF0aW9uYWwgdW5pdCBTQ0lNIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RG9lcyBub3Qgc2VlbSBsaWtlIHRoZXJlIGlzIGEgY29uc2Vuc3VzIHRoYXQgT1Ug aGllcmFyY2h5IGlzIG5lZWRlZCwgaG93ZXZlciBhIHN1Z2dlc3Rpb24gZm9yIGEgc29sdXRpb24g Y2FtZSB0byBtaWQgc28gSSBqdXN0IHRob3VnaHQgSSBzZW5kIGl0IG91dCBhbmQgc2Ugd2hhdCBw ZW9wbGUgdGhpbmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldoYXQgYWJvdXQgdXNpbmcgdGhlIHBhdGggdG8gY3JlYXRlIHRoZSBoaWVyYXJj aGljYWwgT1Ugc3RydWN0dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZsdDtiYXNlLXBhdGgmZ3Q7LyZsdDtvdTEmZ3Q7VXNlcnM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtiYXNlLXBh dGgmZ3Q7LyZsdDtvdTEmZ3Q7R3JvdXBzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0Oy8mbHQ7b3Uy Jmd0O1VzZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbHQ7YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0Oy8mbHQ7b3UyJmd0O0dyb3VwczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHNl YXJjaGluZyB1bmRlciAmbHQ7YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0OyByZXN1bHRzIHdvdWxk IGluY2x1ZGUgVXNlcnMvR3JvdXBzIHVuZGVyICZsdDtiYXNlLXBhdGgmZ3Q7LyZsdDtvdTEmZ3Q7 LyZsdDtvdTImZ3Q7IGJ1dCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuIEkgZG9udCBrbm93IGlm IHRoaXMgY3JlYXRlcyBlbm91Z2ggZmxleGliaWxpdHkgZS5nPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoIHRoZSBmb2xsb3dpbmcgc3RydWN0 dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmx0O2Jhc2UtcGF0aCZndDsvJmx0O291MSZndDsvJmx0O291MiZndDtVc2VyczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmx0O2Jhc2UtcGF0aCZndDsvJmx0O291MyZndDsvJmx0O291NCZndDtVc2VyczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQg YmUgaGFyZCB0byBzZWFyY2ggZm9yIHVzZXJzIGluIGJvdGggb3UyIGFuZCBvdTQgd2l0aCBvbmUg cmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8vU2FtdWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDI1LCAy MDE1IGF0IDk6NDYgUE0sIEhhYXZhciBWYWxldXIgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWF2YXIu dmFsZXVyQGNpdHJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5oYWF2YXIudmFsZXVyQGNpdHJpeC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg bWlnaHQgYmUgd3JvbmcsIEnigJl2ZSBub3QgZ29uZSB0b28gZGVlcCBpbnRvIHRoZSB1c2VyIGFk bWluaXN0cmF0aW9uIG9mIGRpZmZlcmVudCBwcm92aWRlcnMsIGJ1dCBteSBmaXJzdCBpbXByZXNz aW9uIGlzIHRoYXQgc2FsZXNmb3JjZSAoYXBwYXJlbnRseSBhY3R1YWxseSBmbGF0LWlzaCksIGdv b2dsZSwgYW1hem9uIGFuZCBTQVAgaGF2ZSBzb21lIHNvcnQgb2YgaGllcmFyY2h5LiBJ4oCZbSBz dXJlIG1lbWJlcnMNCiBvZiB0aGlzIFdHIGhhdmUgbW9yZSBkZXRhaWxlZCBrbm93bGVkZ2Ugb2Yg dGhlIGRpZmZlcmVudCBwcm92aWRlcnMuPGJyPg0KPGJyPg0KSSBoYXZlIG5vdCBwdXQgbXVjaCB0 aG91Z2h0IGludG8gaG93IHRoaXMgY2FuIGJlIHJlcHJlc2VudGVkIGFzIGFuIGV4dGVuc2lvbi4g SSB3YW50ZWQgdG8gc2VlIGlmIHRoZXJlIGhhcyBiZWVuIGFueSB3b3JrIGluIHRoaXMgYXJlYSBh bHJlYWR5LCBvciBpZiBpdOKAmXMgZXZlbiBuZWVkZWQuIFNlZW1zIGxpa2UgaWYgaXTigJlzIGV4 cGVjdGVkIHRvIG1hbmFnZSBPVXMgZXh0ZXJuYWwgdG8gU0NJTSwgYW5kIHRoZW4gaGF2ZSBhIHNv ZnQgcmVmZXJlbmNlDQogb24gdGhlIHVzZXIgdXNlciBvYmplY3QsIGl0IHdvdWxkIGJlIHBvc3Np YmxlIHRvIGhhdmUgYW4gZXh0ZW5zaW9uIGRhdGEgbW9kZWwgZm9yIE9VcyB0aGF0IGFyZSBub3Qg aW50cnVzaXZlIHRvIHRoZSBjb3JlIHNjaGVtYS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyBPbiBNYXIgMjUsIDIwMTUsIGF0IDM6 MTEgUE0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgJmx0OzxhIGhyZWY9Im1haWx0bzptb3Jh bnNhckBjaXNjby5jb20iPm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDs8YnI+DQomZ3Q7IFRvIGJlIGNsZWFyIG15IHByZXZpb3VzIHJlc3BvbnNlIHRvIHlvdXIgZW1h aWwgYW5kIHRoaXMgZW1haWwgYXJlIHdpdGggbWU8YnI+DQomZ3Q7IHdlYXJpbmcgaW1wbGVtZW50 ZXIgaGF0IGFuZCBub3Qgc3BlYWtpbmcgYXMgY2hhaXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBj YW7CuXQgc2VlIGhvdyB3ZSBjb3VsZCBhZGQgdGhlIE9VIGhpZXJhcmNoeSBhcyBhbiBleHRlbnNp b24gb2YgdGhlIFNDSU0uPGJyPg0KJmd0OyBUaGF0IHdvdWxkIGJlIGEgcHJldHR5IGludHJ1c2l2 ZSBjaGFuZ2UgYW5kIHJlcXVpcmUgY2hhbmdlcyB0byBhbG1vc3Q8YnI+DQomZ3Q7IGV2ZXJ5dGhp bmcgaW4gU0NJTS4gSG93ZXZlciwgaWYgeW91IGhhdmUgaWRlYXMgaG93IHRoaXMgY291bGQgYmUg ZG9uZSwgSTxicj4NCiZndDsgd291bGQgbG92ZSB0byBoZWFyIHRoZW0uPGJyPg0KJmd0Ozxicj4N CiZndDsgQWxzbyBpZiB5b3Uga25vdyBvZiBTYWFTIHNvbHV0aW9ucyB3aGVyZSB0aGUgaWRlbnRp dHkgc3BhY2UgaXM8YnI+DQomZ3Q7IGhpZXJhcmNoaWNhbCwgcGxlYXNlIHNoYXJlIHRoYXQuIEkg c3RhcnRlZCB0aGlua2luZyB0aGUgc2FtZSB3YXkgYnV0PGJyPg0KJmd0OyBkaWRuwrl0IGZpbmQg YW55IHZlbmRvciB0aGF0IHN1cHBvcnRlZCBpdCBvciBjdXN0b21lcnMgdGhhdCBhc2tlZCBmb3Ig aXQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IE1vcnRl emE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAzLzI1LzE1LCAyOjMzIFBNLCAmcXVvdDtIYWF2YXIg VmFsZXVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGFhdmFyLnZhbGV1ckBjaXRyaXguY29t Ij5oYWF2YXIudmFsZXVyQGNpdHJpeC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDsgSSB0aGluayBoYXZpbmcgdGhlIE9VcyBiZSBoaWVyYXJjaGljYWwgc2hvdWxkIGJl IGFuIG9wdGlvbiBpZiBhbjxicj4NCiZndDsmZ3Q7IGV4dGVuc2lvbiB3YXMgYWRkZWQsIGJ1dCBl dmVuIHdpdGhvdXQgdGhhdCBJIHdvdWxkIHRoaW5rIHRoYXQgaXTCuXM8YnI+DQomZ3Q7Jmd0OyBi ZW5lZmljaWFsIHRvIGhhdmUgT1VzIGluIHRoZSBBUEkuIFdpdGhvdXQgT1UgcmVwcmVzZW50ZWQg aW4gdGhlIHNjaGVtYTxicj4NCiZndDsmZ3Q7IHlvdSB3b3VsZCBoYXZlIGxvb3NlIHJlZmVyZW5j ZXMgdG8gb2JqZWN0cyB0aGF0IGFyZSBjcmVhdGVkIHdpdGg8YnI+DQomZ3Q7Jmd0OyBwcm9wcmll dGFyeSBBUElzIG9yIHNjaGVtYXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJwrltIGEg bGl0dGxlIHN1cnByaXNlZCB0aGF0IHRoZSBjb25zZW5zdXMgd2FzIHRoYXQgU2FhUyBwcm92aWRl cnMgaGF2ZSBhPGJyPg0KJmd0OyZndDsgZmxhdCBPVSBzdHJ1Y3R1cmUuIEZyb20gd2hhdCBJwrl2 ZSBzZWVuLCBhIGxvdCBvZiBwcm92aWRlcnMgc3VwcG9ydCBhPGJyPg0KJmd0OyZndDsgaGllcmFy Y2h5ICh3aXRoIGEgc29tZSBub3RhYmxlIGV4Y2VwdGlvbnMpLiBJIHdvdWxkIHRoaW5rIGl0IHdv dWxkIGJlIGE8YnI+DQomZ3Q7Jmd0OyBjb21tb24gdXNlIGNhc2UgZm9yIGxhcmdlciBjdXN0b21l cnMgb2YgYSBTYWFTIHByb3ZpZGVyIHRvIHN5bmMgdGhlaXI8YnI+DQomZ3Q7Jmd0OyBlbXBsb3ll ZSBkaXJlY3RvcnkgdG8gdGhlIHByb3ZpZGVyLCBpbmNsdWRpbmcgT1VzLiBUaGUgT1VzIHdvdWxk IGJlIHVzZWQ8YnI+DQomZ3Q7Jmd0OyB0byBzZXQgcGFzc3dvcmQgcG9saWNlcywgZmVkZXJhdGVk IGxvZ2luIHNldHRpbmdzIGFuZCBhZG1pbmlzdHJhdGlvbiBvcjxicj4NCiZndDsmZ3Q7IHByb2R1 Y3QgcHJpdmlsZWdlcyBvbiB0aGUgU2FhUyBwcm92aWRlciBzaWRlLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgSGF2ZSB0aGUgU2FhUyBwcm92aWRlcnMgY2hhbmdlZCB0aGlzIG92ZXIgdGhl IHllYXJzLCBvciBkbyBJIGhhdmUgdGhlPGJyPg0KJmd0OyZndDsgd3JvbmcgaW1wcmVzc2lvbj88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIE1hciAyNSwg MjAxNSwgYXQgMTE6NDcgQU0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcik8YnI+DQomZ3Q7Jmd0 OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iPm1vcmFuc2FyQGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgaGllcmFyY2hpY2FsIG9yZ2FuaXphdGlvbiBvZiBy ZXNvdXJjZTxicj4NCiZndDsmZ3Q7Jmd0OyBpbnN0YW5jZXMsPGJyPg0KJmd0OyZndDsmZ3Q7IHdl IGhhZCB0aGF0IGRpc2N1c3Npb24gaW4gdGhlIHZlcnkgZWFybHkgZGF5cyBvZiBTQ0lNIDEuMCB3 b3JrLiBJPGJyPg0KJmd0OyZndDsmZ3Q7IGFjdHVhbGx5PGJyPg0KJmd0OyZndDsmZ3Q7IHRoaW5r IEkgYnJvdWdodCB0aGF0IHVwIGFzIGEgcmVxdWVzdCBidXQgYWZ0ZXIgdGFsa2luZyB0byBvdGhl ciB2ZW5kb3JzPGJyPg0KJmd0OyZndDsmZ3Q7IGl0PGJyPg0KJmd0OyZndDsmZ3Q7IHNlZW1lZCBl dmVyeSBTYWFTIHNlcnZpY2Ugd2FzIGRvaW5nIGEgZmxhdCBuYW1lIHNwYWNlIGZvciB1c2VycyAm YW1wOyBncm91cHM8YnI+DQomZ3Q7Jmd0OyZndDsgYW5kIG5vYm9keSBoYWQgYSByZXF1ZXN0IGZy b20gY3VzdG9tZXJzIGZvciBhIGhpZXJhcmNoaWNhbCBtb2RlbCBzbyB0aGU8YnI+DQomZ3Q7Jmd0 OyZndDsgZmVhdHVyZSB3YXMgZHJvcHBlZC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7Jmd0OyBNb3J0ZXph PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDMvMjQvMTUsIDY6NTQgUE0s ICZxdW90O0hhYXZhciBWYWxldXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWF2YXIudmFs ZXVyQGNpdHJpeC5jb20iPmhhYXZhci52YWxldXJAY2l0cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSGFzIHRoZXJlIGJlZW4gYW55 IGRpc2N1c3Npb24gYXJvdW5kIGEgc3RhbmRhcmQgU0NJTSBleHRlbnNpb24gdGhhdDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgaGFuZGxlcyBvcmdhbml6YXRpb25hbCB1bml0cyAoT1UpPyBBIHF1aWNr IGdvb2dsZSBzZWFyY2ggY2FtZSB1cCB3aXRoIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvdXBs ZSBvZiBlbWFpbHMgZnJvbSAzIHllYXJzIGFnbywgYnV0IG5vIHJlYWwgc3Vic2lkZW5jZS48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGVyZSBoYXMgbm90 IGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5kIHRoaXMsIGlzIHRoZXJlIGEgcmVhc29uIGZvcjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgaXQ/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgQmVzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSGFhdmFyPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vc2VjdXJlLXdlYi5jaXNjby5jb20vMU5UNXpXcV9WLXh1OVFDUi02Qi1UdDdYbjBGZVRSWmlf OG42OEQ0ejlTaSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNv bS8xTlQ1eldxX1YteHU5UUNSLTZCLVR0N1huMEZlVFJaaV84bjY4RDR6OVNpPC9hPjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgRUhkY1dYaU4yY3hieWU4ZjQ5d3NYeHpQaFdKbEdfZWpCMzQ3TXMtMVM1 OHJ1aFZjd0lkcjRGQnFDZWRyVGVEYnNYV25aUEhMPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAwTExv NWE2dEVNTFRQMzVaQlFDWUF2SWJNZE52UDdKMkdnRVc1ZWRMa0Nwc1RMVkNKemlhRWtYdGsvaHR0 cHMlM0ElMkYlMkY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9zZWN1cmUtd2ViLmNpc2Nv LmNvbS8xRXU2X1FHcDdUMjNPeWJneU82UjBZQmNyazJnQTVINl9WcS1BcmJlR1Q3Q09HT2NJQ3dR QnlWQlVwbE1yOE84Q2xISUxpOU82bE5vZlJXaUZXSDZ5d1hnUHdmMEo1dlpMOFR1SkFZWFJWYWNX bXVocUU3d1VnS2wzNGhmczBmLU1ycHlrMGNaVUVmN2sxZ0ZvdFlXYk1kMF8yQldNUl9OdEdOQUkz cFl2XzZLcnREeDNkSjAwc2VNbVBpZ3NMTlV1L2h0dHAlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vc2VjdXJl LXdlYi5jaXNjby5jb20vMUV1Nl9RR3A3VDIzT3liZ3lPNlIwWUJjcmsyZ0E1SDZfVnEtQXJiZUdU N0NPR09jSUN3UUJ5VkJVcGxNcjhPOENsSElMaTlPNmxOb2ZSV2lGV0g2eXdYZ1B3ZjBKNXZaTDhU dUpBWVhSVmFjV211aHFFN3dVZ0tsMzRoZnMwZi1NcnB5azBjWlVFZjdrMWdGb3RZV2JNZDBfMkJX TVJfTnRHTkFJM3BZdl82S3J0RHgzZEowMHNlTW1QaWdzTE5VdS9odHRwJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN1PR04MB3929B8118B8CBD99043B892E2D70BN1PR04MB392namprd_-- From nobody Wed Apr 29 16:41: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 0B13C1A8ACC for ; Wed, 29 Apr 2015 16:41:21 -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 GG_OKhvXgTcj for ; Wed, 29 Apr 2015 16:41:19 -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 2D7301A8ACB for ; Wed, 29 Apr 2015 16:41:19 -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 t3TNfITM029432 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Apr 2015 23:41:18 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 t3TNfH6c027348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2015 23:41:18 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3TNfH5L022698; Wed, 29 Apr 2015 23:41:17 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Apr 2015 16:41:17 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_51960AF6-CE18-4EBC-A39C-2D985CE78F54" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Phil Hunt In-Reply-To: Date: Wed, 29 Apr 2015 16:41:15 -0700 Message-Id: References: To: Kelly Grizzle X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Patrick Radtke , SCIM WG 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, 29 Apr 2015 23:41:21 -0000 --Apple-Mail=_51960AF6-CE18-4EBC-A39C-2D985CE78F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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: >=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 --Apple-Mail=_51960AF6-CE18-4EBC-A39C-2D985CE78F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.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

 

 

 

 


= --Apple-Mail=_51960AF6-CE18-4EBC-A39C-2D985CE78F54-- From nobody Wed Apr 29 17:05: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 AB79E1A8F3F for ; Wed, 29 Apr 2015 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 KfJII0omkA5G for ; Wed, 29 Apr 2015 17:05:17 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C341A8BB3 for ; Wed, 29 Apr 2015 17:05:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,673,1422921600"; d="scan'208,217";a="257979713" From: Haavar Valeur To: Kelly Grizzle Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA//+VPgCAAH8NAIAFm7oAgDGRbICAAAv7gA== Date: Thu, 30 Apr 2015 00:05:10 +0000 Message-ID: <9A06244C-AB73-4AAA-8E8F-26229B1CA5C7@citrix.com> References: <25626256-27A4-4FC3-8A2F-C56181677759@citrix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9A06244CAB734AAA8E8F26229B1CA5C7citrixcom_" MIME-Version: 1.0 X-DLP: MIA2 Archived-At: Cc: Samuel Erdtman , "Morteza Ansari \(moransar\)" , "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension 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, 30 Apr 2015 00:05:21 -0000 --_000_9A06244CAB734AAA8E8F26229B1CA5C7citrixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIGlzIGVzc2VudGlhbGx5IHdoYXQgSSBoYWQgaW4gbWluZC4NCg0KSSB0aGluayBz b21ldGltZXMgeW91IHdvdWxkIHdhbnQgdG8gZG8gYSByZWN1cnNpdmUgc2VhcmNoIHRyb3VnaCB0 aGUgaGllcmFyY2h5LCBhbmQgb3RoZXIgdGltZXMgeW91IG1pZ2h0IG5vdC4gQXMgeW91IHNhaWQg aXQgY291bGQgYmUgY29udHJvbGxlZCBieSBhIHF1ZXJ5IHBhcmFtZXRlci4NCg0KVGhlcmUgc2hv dWxkIHByb2JhYmx5IGFsc28gYmUgc29tZSB3YXkgdG8gZmlsdGVyIHRoZSByZXN1bHRzIHRoYXQg YXJlIHJldHVuZWQgdW5kZXIgdGhlIC9PcmdVbml0cyBlbmRwb2ludC4NCg0KDQpPbiBBcHIgMjks IDIwMTUsIGF0IDQ6MjIgUE0sIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQoNCkhhYXZh ciDigKYgSSBkZWZpbml0ZWx5IHNlZSB0aGUgYmVuZWZpdCBoZXJlIGZvciBwcm92aWRlcnMgdGhh dCBhcmUgcHV0dGluZyBTQ0lNIG9uIHRvcCBvZiBhIGRpcmVjdG9yeS4gIEkgY2FuIHNlZSBhIHBy ZXR0eSBzaW1wbGUgc3RhbmRhcmRpemUgZXh0ZW5zaW9uIHRoYXQgd291bGQgcHJvdmlkZSB0aGlz LiAgSXQgd291bGQgYmUgdGhlIGFkZGl0aW9uIG9mIGEgc2luZ2xlIGF0dHJpYnV0ZSAoaW4gYW4g ZXh0ZW5zaW9uKSBhbmQgYSBuZXcgZW5kcG9pbnQgd2l0aCBhbiBhc3NvY2lhdGVkIHNjaGVtYS4g IFRoZSBVc2VyIChhbmQgcHJvYmFibHkgR3JvdXApIHJlc291cmNlcyB3b3VsZCBhZGQgYW4gT1Ug cmVmZXJlbmNlIHRvIHRoZWlyIHNjaGVtYS4gIEZvciBleGFtcGxlOg0KDQp7DQogICJpZCI6ICI4 MjczNDEiLA0KICAidXNlcm5hbWUiOiAia2dyaXp6bGUiLA0KICAic29tZTpleHRlbnNpb246dXJu Ijogew0KICAgICJvdSI6IHsNCiAgICAgICJ2YWx1ZSI6ICIwOTg4OTgyMzQwIiwNCiAgICAgICIk cmVmIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdjIvT3JnVW5pdHMvMDk4ODk4MjM0MCINCiAgICB9 DQogIH0NCn0NCg0KVGhlIGVuZHBvaW50IHdvdWxkIGJlIGEgZmxhdCBsaXN0IG9mIG9yZyB1bml0 cyAoaWUg4oCTIHRoZXkgd291bGQgYWxsIGJlIGRpcmVjdGx5IHVuZGVyIHRoZSAvT3JnVW5pdHMg ZW5kcG9pbnQpLCBidXQgd291bGQgYmUgaGllcmFyY2hpY2FsIHRocm91Z2ggcGFyZW50IHJlbGF0 aW9uc2hpcHMuDQoNCkdFVCAvT3JnVW5pdHMNCg0KWw0KICB7DQogICAgImlkIjogIjA5ODc0Nzg4 NzI3MzQiDQogICAgIm5hbWUiOiAiT1UgMCIsDQogIH0sDQogIHsNCiAgICAiaWQiOiAiODc3OTg3 MjM4OTc0Ig0KICAgICJuYW1lIjogIk9VIDEiLA0KICAgICJwYXJlbnQiOiB7DQogICAgICAidmFs dWUiOiAiMDk4NzQ3ODg3MjczNCIsDQogICAgICAiJHJlZiI6ICJodHRwczovL2V4YW1wbGUuY29t L3YyL09yZ1VuaXRzLzA5ODc0Nzg4NzI3MzQiLA0KICAgICAgImRpc3BsYXlOYW1lIjogIk9VIDAi DQogICAgfQ0KICB9DQpdDQoNClRoZSBvbmx5IHRyaWNrIGhlcmUgd291bGQgYmUgc2VhcmNoIGZv ciBvYmplY3RzIGluIOKAnE9VIDDigJ0uICBTaG91bGQgcmVzb3VyY2VzIGluIOKAnE9VIDHigJ0g YWxzbyBiZSByZXR1cm5lZD8gIFBlcmhhcHMgYSBuZXcgcXVlcnkgcGFyYW1ldGVyIGNvdWxkIHRh a2UgY2FyZSBvZiB3aGV0aGVyIHRvIGRvIGEgc3ViLXRyZWUgc2VhcmNoIG9yIG5vdC4NCg0KSSB0 aGluayBTYW11ZWzigJlzIGlkZWEgd291bGQgbWFwIHdlbGwgdG8gYSBkaXJlY3RvcnksIGJ1dCB0 aGVyZSBpc27igJl0IGEgZ29vZCBmYWNpbGl0eSBmb3IgdGhhdCB0eXBlIG9mIGV4dGVuc2lvbiBp biBTQ0lNLg0KDQotLUtlbGx5DQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW11ZWwgRXJkdG1hbg0KU2VudDogU3VuZGF5LCBNYXJjaCAy OSwgMjAxNSA1OjI1IEFNDQpUbzogSGFhdmFyIFZhbGV1cg0KQ2M6IHNjaW1AaWV0Zi5vcmc8bWFp bHRvOnNjaW1AaWV0Zi5vcmc+OyBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpDQpTdWJqZWN0OiBS ZTogW3NjaW1dIE9yZ2FuaXphdGlvbmFsIHVuaXQgU0NJTSBleHRlbnNpb24NCg0KSGksDQoNCkRv ZXMgbm90IHNlZW0gbGlrZSB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0aGF0IE9VIGhpZXJhcmNoeSBp cyBuZWVkZWQsIGhvd2V2ZXIgYSBzdWdnZXN0aW9uIGZvciBhIHNvbHV0aW9uIGNhbWUgdG8gbWlk IHNvIEkganVzdCB0aG91Z2h0IEkgc2VuZCBpdCBvdXQgYW5kIHNlIHdoYXQgcGVvcGxlIHRoaW5r Lg0KDQpXaGF0IGFib3V0IHVzaW5nIHRoZSBwYXRoIHRvIGNyZWF0ZSB0aGUgaGllcmFyY2hpY2Fs IE9VIHN0cnVjdHVyZQ0KDQo8YmFzZS1wYXRoPi88b3UxPlVzZXJzDQo8YmFzZS1wYXRoPi88b3Ux Pkdyb3Vwcw0KPGJhc2UtcGF0aD4vPG91MT4vPG91Mj5Vc2Vycw0KPGJhc2UtcGF0aD4vPG91MT4v PG91Mj5Hcm91cHMNCg0KV2hlbiBzZWFyY2hpbmcgdW5kZXIgPGJhc2UtcGF0aD4vPG91MT4gcmVz dWx0cyB3b3VsZCBpbmNsdWRlIFVzZXJzL0dyb3VwcyB1bmRlciA8YmFzZS1wYXRoPi88b3UxPi88 b3UyPiBidXQgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLiBJIGRvbnQga25vdyBpZiB0aGlzIGNy ZWF0ZXMgZW5vdWdoIGZsZXhpYmlsaXR5IGUuZw0Kd2l0aCB0aGUgZm9sbG93aW5nIHN0cnVjdHVy ZQ0KPGJhc2UtcGF0aD4vPG91MT4vPG91Mj5Vc2Vycw0KPGJhc2UtcGF0aD4vPG91Mz4vPG91ND5V c2Vycw0KSXQgd291bGQgYmUgaGFyZCB0byBzZWFyY2ggZm9yIHVzZXJzIGluIGJvdGggb3UyIGFu ZCBvdTQgd2l0aCBvbmUgcmVxdWVzdC4NCg0KQmVzdCByZWdhcmRzDQovL1NhbXVlbA0KDQoNCg0K DQoNCg0KDQpPbiBXZWQsIE1hciAyNSwgMjAxNSBhdCA5OjQ2IFBNLCBIYWF2YXIgVmFsZXVyIDxo YWF2YXIudmFsZXVyQGNpdHJpeC5jb208bWFpbHRvOmhhYXZhci52YWxldXJAY2l0cml4LmNvbT4+ IHdyb3RlOg0KSSBtaWdodCBiZSB3cm9uZywgSeKAmXZlIG5vdCBnb25lIHRvbyBkZWVwIGludG8g dGhlIHVzZXIgYWRtaW5pc3RyYXRpb24gb2YgZGlmZmVyZW50IHByb3ZpZGVycywgYnV0IG15IGZp cnN0IGltcHJlc3Npb24gaXMgdGhhdCBzYWxlc2ZvcmNlIChhcHBhcmVudGx5IGFjdHVhbGx5IGZs YXQtaXNoKSwgZ29vZ2xlLCBhbWF6b24gYW5kIFNBUCBoYXZlIHNvbWUgc29ydCBvZiBoaWVyYXJj aHkuIEnigJltIHN1cmUgbWVtYmVycyBvZiB0aGlzIFdHIGhhdmUgbW9yZSBkZXRhaWxlZCBrbm93 bGVkZ2Ugb2YgdGhlIGRpZmZlcmVudCBwcm92aWRlcnMuDQoNCkkgaGF2ZSBub3QgcHV0IG11Y2gg dGhvdWdodCBpbnRvIGhvdyB0aGlzIGNhbiBiZSByZXByZXNlbnRlZCBhcyBhbiBleHRlbnNpb24u IEkgd2FudGVkIHRvIHNlZSBpZiB0aGVyZSBoYXMgYmVlbiBhbnkgd29yayBpbiB0aGlzIGFyZWEg YWxyZWFkeSwgb3IgaWYgaXTigJlzIGV2ZW4gbmVlZGVkLiBTZWVtcyBsaWtlIGlmIGl04oCZcyBl eHBlY3RlZCB0byBtYW5hZ2UgT1VzIGV4dGVybmFsIHRvIFNDSU0sIGFuZCB0aGVuIGhhdmUgYSBz b2Z0IHJlZmVyZW5jZSBvbiB0aGUgdXNlciB1c2VyIG9iamVjdCwgaXQgd291bGQgYmUgcG9zc2li bGUgdG8gaGF2ZSBhbiBleHRlbnNpb24gZGF0YSBtb2RlbCBmb3IgT1VzIHRoYXQgYXJlIG5vdCBp bnRydXNpdmUgdG8gdGhlIGNvcmUgc2NoZW1hLg0KDQo+IE9uIE1hciAyNSwgMjAxNSwgYXQgMzox MSBQTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSA8bW9yYW5zYXJAY2lzY28uY29tPG1haWx0 bzptb3JhbnNhckBjaXNjby5jb20+PiB3cm90ZToNCj4NCj4gVG8gYmUgY2xlYXIgbXkgcHJldmlv dXMgcmVzcG9uc2UgdG8geW91ciBlbWFpbCBhbmQgdGhpcyBlbWFpbCBhcmUgd2l0aCBtZQ0KPiB3 ZWFyaW5nIGltcGxlbWVudGVyIGhhdCBhbmQgbm90IHNwZWFraW5nIGFzIGNoYWlyLg0KPg0KPiBJ IGNhbsK5dCBzZWUgaG93IHdlIGNvdWxkIGFkZCB0aGUgT1UgaGllcmFyY2h5IGFzIGFuIGV4dGVu c2lvbiBvZiB0aGUgU0NJTS4NCj4gVGhhdCB3b3VsZCBiZSBhIHByZXR0eSBpbnRydXNpdmUgY2hh bmdlIGFuZCByZXF1aXJlIGNoYW5nZXMgdG8gYWxtb3N0DQo+IGV2ZXJ5dGhpbmcgaW4gU0NJTS4g SG93ZXZlciwgaWYgeW91IGhhdmUgaWRlYXMgaG93IHRoaXMgY291bGQgYmUgZG9uZSwgSQ0KPiB3 b3VsZCBsb3ZlIHRvIGhlYXIgdGhlbS4NCj4NCj4gQWxzbyBpZiB5b3Uga25vdyBvZiBTYWFTIHNv bHV0aW9ucyB3aGVyZSB0aGUgaWRlbnRpdHkgc3BhY2UgaXMNCj4gaGllcmFyY2hpY2FsLCBwbGVh c2Ugc2hhcmUgdGhhdC4gSSBzdGFydGVkIHRoaW5raW5nIHRoZSBzYW1lIHdheSBidXQNCj4gZGlk bsK5dCBmaW5kIGFueSB2ZW5kb3IgdGhhdCBzdXBwb3J0ZWQgaXQgb3IgY3VzdG9tZXJzIHRoYXQg YXNrZWQgZm9yIGl0Lg0KPg0KPg0KPiBDaGVlcnMsDQo+IE1vcnRlemENCj4NCj4gT24gMy8yNS8x NSwgMjozMyBQTSwgIkhhYXZhciBWYWxldXIiIDxoYWF2YXIudmFsZXVyQGNpdHJpeC5jb208bWFp bHRvOmhhYXZhci52YWxldXJAY2l0cml4LmNvbT4+IHdyb3RlOg0KPg0KPj4gSSB0aGluayBoYXZp bmcgdGhlIE9VcyBiZSBoaWVyYXJjaGljYWwgc2hvdWxkIGJlIGFuIG9wdGlvbiBpZiBhbg0KPj4g ZXh0ZW5zaW9uIHdhcyBhZGRlZCwgYnV0IGV2ZW4gd2l0aG91dCB0aGF0IEkgd291bGQgdGhpbmsg dGhhdCBpdMK5cw0KPj4gYmVuZWZpY2lhbCB0byBoYXZlIE9VcyBpbiB0aGUgQVBJLiBXaXRob3V0 IE9VIHJlcHJlc2VudGVkIGluIHRoZSBzY2hlbWENCj4+IHlvdSB3b3VsZCBoYXZlIGxvb3NlIHJl ZmVyZW5jZXMgdG8gb2JqZWN0cyB0aGF0IGFyZSBjcmVhdGVkIHdpdGgNCj4+IHByb3ByaWV0YXJ5 IEFQSXMgb3Igc2NoZW1hcy4NCj4+DQo+PiBJwrltIGEgbGl0dGxlIHN1cnByaXNlZCB0aGF0IHRo ZSBjb25zZW5zdXMgd2FzIHRoYXQgU2FhUyBwcm92aWRlcnMgaGF2ZSBhDQo+PiBmbGF0IE9VIHN0 cnVjdHVyZS4gRnJvbSB3aGF0IEnCuXZlIHNlZW4sIGEgbG90IG9mIHByb3ZpZGVycyBzdXBwb3J0 IGENCj4+IGhpZXJhcmNoeSAod2l0aCBhIHNvbWUgbm90YWJsZSBleGNlcHRpb25zKS4gSSB3b3Vs ZCB0aGluayBpdCB3b3VsZCBiZSBhDQo+PiBjb21tb24gdXNlIGNhc2UgZm9yIGxhcmdlciBjdXN0 b21lcnMgb2YgYSBTYWFTIHByb3ZpZGVyIHRvIHN5bmMgdGhlaXINCj4+IGVtcGxveWVlIGRpcmVj dG9yeSB0byB0aGUgcHJvdmlkZXIsIGluY2x1ZGluZyBPVXMuIFRoZSBPVXMgd291bGQgYmUgdXNl ZA0KPj4gdG8gc2V0IHBhc3N3b3JkIHBvbGljZXMsIGZlZGVyYXRlZCBsb2dpbiBzZXR0aW5ncyBh bmQgYWRtaW5pc3RyYXRpb24gb3INCj4+IHByb2R1Y3QgcHJpdmlsZWdlcyBvbiB0aGUgU2FhUyBw cm92aWRlciBzaWRlLg0KPj4NCj4+IEhhdmUgdGhlIFNhYVMgcHJvdmlkZXJzIGNoYW5nZWQgdGhp cyBvdmVyIHRoZSB5ZWFycywgb3IgZG8gSSBoYXZlIHRoZQ0KPj4gd3JvbmcgaW1wcmVzc2lvbj8N Cj4+DQo+Pg0KPj4+IE9uIE1hciAyNSwgMjAxNSwgYXQgMTE6NDcgQU0sIE1vcnRlemEgQW5zYXJp IChtb3JhbnNhcikNCj4+PiA8bW9yYW5zYXJAY2lzY28uY29tPG1haWx0bzptb3JhbnNhckBjaXNj by5jb20+PiB3cm90ZToNCj4+Pg0KPj4+IElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBoaWVyYXJj aGljYWwgb3JnYW5pemF0aW9uIG9mIHJlc291cmNlDQo+Pj4gaW5zdGFuY2VzLA0KPj4+IHdlIGhh ZCB0aGF0IGRpc2N1c3Npb24gaW4gdGhlIHZlcnkgZWFybHkgZGF5cyBvZiBTQ0lNIDEuMCB3b3Jr LiBJDQo+Pj4gYWN0dWFsbHkNCj4+PiB0aGluayBJIGJyb3VnaHQgdGhhdCB1cCBhcyBhIHJlcXVl c3QgYnV0IGFmdGVyIHRhbGtpbmcgdG8gb3RoZXIgdmVuZG9ycw0KPj4+IGl0DQo+Pj4gc2VlbWVk IGV2ZXJ5IFNhYVMgc2VydmljZSB3YXMgZG9pbmcgYSBmbGF0IG5hbWUgc3BhY2UgZm9yIHVzZXJz ICYgZ3JvdXBzDQo+Pj4gYW5kIG5vYm9keSBoYWQgYSByZXF1ZXN0IGZyb20gY3VzdG9tZXJzIGZv ciBhIGhpZXJhcmNoaWNhbCBtb2RlbCBzbyB0aGUNCj4+PiBmZWF0dXJlIHdhcyBkcm9wcGVkLg0K Pj4+DQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4gTW9ydGV6YQ0KPj4+DQo+Pj4gT24gMy8yNC8xNSwg Njo1NCBQTSwgIkhhYXZhciBWYWxldXIiIDxoYWF2YXIudmFsZXVyQGNpdHJpeC5jb208bWFpbHRv OmhhYXZhci52YWxldXJAY2l0cml4LmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhhcyB0aGVyZSBi ZWVuIGFueSBkaXNjdXNzaW9uIGFyb3VuZCBhIHN0YW5kYXJkIFNDSU0gZXh0ZW5zaW9uIHRoYXQN Cj4+Pj4gaGFuZGxlcyBvcmdhbml6YXRpb25hbCB1bml0cyAoT1UpPyBBIHF1aWNrIGdvb2dsZSBz ZWFyY2ggY2FtZSB1cCB3aXRoIGENCj4+Pj4gY291cGxlIG9mIGVtYWlscyBmcm9tIDMgeWVhcnMg YWdvLCBidXQgbm8gcmVhbCBzdWJzaWRlbmNlLg0KPj4+Pg0KPj4+PiBJZiB0aGVyZSBoYXMgbm90 IGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5kIHRoaXMsIGlzIHRoZXJlIGEgcmVhc29uIGZvcg0K Pj4+PiBpdD8NCj4+Pj4NCj4+Pj4gQmVzdA0KPj4+PiBIYWF2YXINCj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2NpbSBtYWlsaW5nIGxp c3QNCj4+Pj4gc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj4+Pj4NCj4+Pj4g aHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xTlQ1eldxX1YteHU5UUNSLTZCLVR0N1huMEZl VFJaaV84bjY4RDR6OVNpDQo+Pj4+IEVIZGNXWGlOMmN4YnllOGY0OXdzWHh6UGhXSmxHX2VqQjM0 N01zLTFTNThydWhWY3dJZHI0RkJxQ2VkclRlRGJzWFduWlBITA0KPj4+PiAwTExvNWE2dEVNTFRQ MzVaQlFDWUF2SWJNZE52UDdKMkdnRVc1ZWRMa0Nwc1RMVkNKemlhRWtYdGsvaHR0cHMlM0ElMkYl MkYNCj4+Pj4gaHR0cDovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFFdTZfUUdwN1QyM095Ymd5TzZS MFlCY3JrMmdBNUg2X1ZxLUFyYmVHVDdDT0dPY0lDd1FCeVZCVXBsTXI4TzhDbEhJTGk5TzZsTm9m UldpRldINnl3WGdQd2YwSjV2Wkw4VHVKQVlYUlZhY1dtdWhxRTd3VWdLbDM0aGZzMGYtTXJweWsw Y1pVRWY3azFnRm90WVdiTWQwXzJCV01SX050R05BSTNwWXZfNktydER4M2RKMDBzZU1tUGlnc0xO VXUvaHR0cCUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNjaW0N Cj4+Pg0KPj4+DQo+Pg0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNj aW1AaWV0Zi5vcmc+DQpodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFUbVBnMk5TaHB2YmVO RXlsMDBrVDBDbzVBR1JzNEFQZFprOTB4bnJBTUMzTk1rRzlPemJxSFRwdkFHaXBvVjJJWlB4ZWFT V0hlUnNWczRJZ04tUXFBR3JSV2VlNElXVnN4bFFXdnZiVUFuSEJ0QWJaVUo1MTJRX1NFOGpVSWVV ZUNUaEM2SEZjVWFXdWoxejNLUktWRWhqcE1SZjdkdGNTRVlhUU02dFRwNFlxNWcwWlpySzF1V0xj bE0tU0E1LU0vaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZzY2ltDQoNCg== --_000_9A06244CAB734AAA8E8F26229B1CA5C7citrixcom_ Content-Type: text/html; charset="utf-8" Content-ID: <1B8FA29297DA8E439A01E797A4812CEE@citrix.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KWWVzLCB0aGlzIGlzIGVzc2VudGlh bGx5IHdoYXQgSSBoYWQgaW4gbWluZC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsgc29tZXRpbWVzIHlvdSB3b3VsZCB3YW50IHRvIGRv IGEgcmVjdXJzaXZlIHNlYXJjaCB0cm91Z2ggdGhlIGhpZXJhcmNoeSwgYW5kIG90aGVyIHRpbWVz IHlvdSBtaWdodCBub3QuIEFzIHlvdSBzYWlkIGl0IGNvdWxkIGJlIGNvbnRyb2xsZWQgYnkgYSBx dWVyeSBwYXJhbWV0ZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBzaG91bGQgcHJvYmFibHkgYWxzbyBiZSBzb21lIHdheSB0 byBmaWx0ZXIgdGhlIHJlc3VsdHMgdGhhdCBhcmUgcmV0dW5lZCB1bmRlciB0aGUgL09yZ1VuaXRz IGVuZHBvaW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDI5 LCAyMDE1LCBhdCA0OjIyIFBNLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86a2Vs bHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiBjbGFzcz0iIj5rZWxseS5ncml6emxlQHNhaWxwb2lu dC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHls ZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SGFhdmFyIOKApiBJIGRlZmluaXRlbHkgc2VlIHRo ZSBiZW5lZml0IGhlcmUgZm9yIHByb3ZpZGVycyB0aGF0IGFyZSBwdXR0aW5nIFNDSU0gb24gdG9w IG9mIGEgZGlyZWN0b3J5LiZuYnNwOyBJIGNhbiBzZWUgYSBwcmV0dHkgc2ltcGxlIHN0YW5kYXJk aXplIGV4dGVuc2lvbiB0aGF0IHdvdWxkDQogcHJvdmlkZSB0aGlzLiZuYnNwOyBJdCB3b3VsZCBi ZSB0aGUgYWRkaXRpb24gb2YgYSBzaW5nbGUgYXR0cmlidXRlIChpbiBhbiBleHRlbnNpb24pIGFu ZCBhIG5ldyBlbmRwb2ludCB3aXRoIGFuIGFzc29jaWF0ZWQgc2NoZW1hLiZuYnNwOyBUaGUgVXNl ciAoYW5kIHByb2JhYmx5IEdyb3VwKSByZXNvdXJjZXMgd291bGQgYWRkIGFuIE9VIHJlZmVyZW5j ZSB0byB0aGVpciBzY2hlbWEuJm5ic3A7IEZvciBleGFtcGxlOjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj57PG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OiAmcXVvdDs4MjczNDEmcXVvdDssPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7ICZxdW90O3VzZXJuYW1lJnF1b3Q7OiAmcXVvdDtrZ3JpenpsZSZxdW90Oyw8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj4mbmJzcDsgJnF1b3Q7c29tZTpleHRlbnNpb246dXJuJnF1b3Q7OiB7PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O291JnF1b3Q7OiB7PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDswOTg4OTgyMzQw JnF1b3Q7LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDsk cmVmJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3YyL09yZ1VuaXRz LzA5ODg5ODIzNDAiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZXhhbXBsZS5jb20vdjIvT3JnVW5pdHMvMDk4ODk4MjM0 MDwvYT4mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZu YnNwOyB9PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+fTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGUgZW5kcG9pbnQgd291bGQgYmUgYSBmbGF0 IGxpc3Qgb2Ygb3JnIHVuaXRzIChpZSDigJMgdGhleSB3b3VsZCBhbGwgYmUgZGlyZWN0bHkgdW5k ZXIgdGhlIC9PcmdVbml0cyBlbmRwb2ludCksIGJ1dCB3b3VsZCBiZSBoaWVyYXJjaGljYWwgdGhy b3VnaCBwYXJlbnQgcmVsYXRpb25zaGlwcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+R0VUIC9PcmdVbml0czxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij5bPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+Jm5ic3A7IHs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7aWQmcXVvdDs6ICZxdW90OzA5ODc0Nzg4NzI3MzQmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7bmFtZSZxdW90OzogJnF1b3Q7T1UgMCZxdW90Oyw8bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij4mbmJzcDsgfSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsgezxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtpZCZxdW90OzogJnF1b3Q7ODc3OTg3MjM4OTc0JnF1b3Q7PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O09VIDEmcXVvdDssPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3BhcmVudCZxdW90OzogezxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt2YWx1ZSZxdW90OzogJnF1 b3Q7MDk4NzQ3ODg3MjczNCZxdW90Oyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7JHJlZiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxl LmNvbS92Mi9PcmdVbml0cy8wOTg3NDc4ODcyNzM0IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2V4YW1wbGUuY29tL3Yy L09yZ1VuaXRzLzA5ODc0Nzg4NzI3MzQ8L2E+JnF1b3Q7LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtkaXNwbGF5TmFtZSZxdW90OzogJnF1b3Q7T1UgMCZx dW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7IH08 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj5dPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoZSBvbmx5IHRyaWNrIGhlcmUgd291bGQgYmUgc2VhcmNo IGZvciBvYmplY3RzIGluIOKAnE9VIDDigJ0uJm5ic3A7IFNob3VsZCByZXNvdXJjZXMgaW4g4oCc T1UgMeKAnSBhbHNvIGJlIHJldHVybmVkPyZuYnNwOyBQZXJoYXBzIGEgbmV3IHF1ZXJ5IHBhcmFt ZXRlciBjb3VsZCB0YWtlIGNhcmUgb2Ygd2hldGhlcg0KIHRvIGRvIGEgc3ViLXRyZWUgc2VhcmNo IG9yIG5vdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+SSB0aGluayBTYW11ZWzigJlzIGlkZWEgd291bGQgbWFwIHdlbGwg dG8gYSBkaXJlY3RvcnksIGJ1dCB0aGVyZSBpc27igJl0IGEgZ29vZCBmYWNpbGl0eSBmb3IgdGhh dCB0eXBlIG9mIGV4dGVuc2lvbiBpbiBTQ0lNLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4tLUtlbGx5PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5zY2ltIFs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiBzdHls ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5t YWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24NCiBCZWhhbGYgT2Y8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlNhbXVlbCBFcmR0 bWFuPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlN1bmRheSwgTWFyY2ggMjksIDIwMTUgNToy NSBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SGFhdmFyIFZhbGV1cjxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNjaW1AaWV0Zi5v cmc8L2E+OyBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBbc2NpbV0gT3JnYW5pemF0aW9uYWwgdW5pdCBTQ0lNIGV4dGVuc2lvbjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCkhpLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KRG9lcyBub3Qgc2VlbSBsaWtl IHRoZXJlIGlzIGEgY29uc2Vuc3VzIHRoYXQgT1UgaGllcmFyY2h5IGlzIG5lZWRlZCwgaG93ZXZl ciBhIHN1Z2dlc3Rpb24gZm9yIGEgc29sdXRpb24gY2FtZSB0byBtaWQgc28gSSBqdXN0IHRob3Vn aHQgSSBzZW5kIGl0IG91dCBhbmQgc2Ugd2hhdCBwZW9wbGUgdGhpbmsuPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCldoYXQgYWJvdXQgdXNpbmcgdGhlIHBhdGggdG8gY3JlYXRl IHRoZSBoaWVyYXJjaGljYWwgT1Ugc3RydWN0dXJlPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiZsdDtiYXNlLXBhdGgmZ3Q7LyZsdDtvdTEmZ3Q7VXNlcnM8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZsdDtiYXNlLXBhdGgmZ3Q7LyZsdDtvdTEm Z3Q7R3JvdXBzPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombHQ7 YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0Oy8mbHQ7b3UyJmd0O1VzZXJzPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombHQ7YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0 Oy8mbHQ7b3UyJmd0O0dyb3VwczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpX aGVuIHNlYXJjaGluZyB1bmRlciAmbHQ7YmFzZS1wYXRoJmd0Oy8mbHQ7b3UxJmd0OyByZXN1bHRz IHdvdWxkIGluY2x1ZGUgVXNlcnMvR3JvdXBzIHVuZGVyICZsdDtiYXNlLXBhdGgmZ3Q7LyZsdDtv dTEmZ3Q7LyZsdDtvdTImZ3Q7IGJ1dCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuIEkgZG9udCBr bm93IGlmIHRoaXMgY3JlYXRlcyBlbm91Z2ggZmxleGliaWxpdHkgZS5nPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgc3RydWN0dXJl PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KJmx0O2Jhc2UtcGF0aCZndDsvJmx0O291MSZndDsvJmx0O291MiZndDtVc2VyczxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KJmx0O2Jhc2UtcGF0aCZndDsvJmx0O291MyZndDsvJmx0O291NCZndDtVc2VyczxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSXQgd291bGQgYmUgaGFyZCB0byBz ZWFyY2ggZm9yIHVzZXJzIGluIGJvdGggb3UyIGFuZCBvdTQgd2l0aCBvbmUgcmVxdWVzdC48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpCZXN0IHJlZ2FyZHM8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCi8vU2FtdWVsPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIFdlZCwgTWFyIDI1 LCAyMDE1IGF0IDk6NDYgUE0sIEhhYXZhciBWYWxldXIgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWF2 YXIudmFsZXVyQGNpdHJpeC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5oYWF2YXIudmFsZXVyQGNp dHJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkkgbWlnaHQgYmUgd3Jv bmcsIEnigJl2ZSBub3QgZ29uZSB0b28gZGVlcCBpbnRvIHRoZSB1c2VyIGFkbWluaXN0cmF0aW9u IG9mIGRpZmZlcmVudCBwcm92aWRlcnMsIGJ1dCBteSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQg c2FsZXNmb3JjZSAoYXBwYXJlbnRseSBhY3R1YWxseSBmbGF0LWlzaCksIGdvb2dsZSwgYW1hem9u IGFuZCBTQVAgaGF2ZSBzb21lIHNvcnQgb2YgaGllcmFyY2h5LiBJ4oCZbSBzdXJlIG1lbWJlcnMg b2YgdGhpcyBXRyBoYXZlIG1vcmUNCiBkZXRhaWxlZCBrbm93bGVkZ2Ugb2YgdGhlIGRpZmZlcmVu dCBwcm92aWRlcnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBoYXZlIG5vdCBwdXQg bXVjaCB0aG91Z2h0IGludG8gaG93IHRoaXMgY2FuIGJlIHJlcHJlc2VudGVkIGFzIGFuIGV4dGVu c2lvbi4gSSB3YW50ZWQgdG8gc2VlIGlmIHRoZXJlIGhhcyBiZWVuIGFueSB3b3JrIGluIHRoaXMg YXJlYSBhbHJlYWR5LCBvciBpZiBpdOKAmXMgZXZlbiBuZWVkZWQuIFNlZW1zIGxpa2UgaWYgaXTi gJlzIGV4cGVjdGVkIHRvIG1hbmFnZSBPVXMgZXh0ZXJuYWwgdG8gU0NJTSwgYW5kIHRoZW4gaGF2 ZSBhIHNvZnQgcmVmZXJlbmNlDQogb24gdGhlIHVzZXIgdXNlciBvYmplY3QsIGl0IHdvdWxkIGJl IHBvc3NpYmxlIHRvIGhhdmUgYW4gZXh0ZW5zaW9uIGRhdGEgbW9kZWwgZm9yIE9VcyB0aGF0IGFy ZSBub3QgaW50cnVzaXZlIHRvIHRoZSBjb3JlIHNjaGVtYS48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBPbiBNYXIg MjUsIDIwMTUsIGF0IDM6MTEgUE0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgJmx0OzxhIGhy ZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFRvIGJlIGNs ZWFyIG15IHByZXZpb3VzIHJlc3BvbnNlIHRvIHlvdXIgZW1haWwgYW5kIHRoaXMgZW1haWwgYXJl IHdpdGggbWU8YnIgY2xhc3M9IiI+DQomZ3Q7IHdlYXJpbmcgaW1wbGVtZW50ZXIgaGF0IGFuZCBu b3Qgc3BlYWtpbmcgYXMgY2hhaXIuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgSSBjYW7CuXQgc2VlIGhvdyB3ZSBjb3VsZCBhZGQgdGhlIE9VIGhpZXJhcmNoeSBhcyBhbiBl eHRlbnNpb24gb2YgdGhlIFNDSU0uPGJyIGNsYXNzPSIiPg0KJmd0OyBUaGF0IHdvdWxkIGJlIGEg cHJldHR5IGludHJ1c2l2ZSBjaGFuZ2UgYW5kIHJlcXVpcmUgY2hhbmdlcyB0byBhbG1vc3Q8YnIg Y2xhc3M9IiI+DQomZ3Q7IGV2ZXJ5dGhpbmcgaW4gU0NJTS4gSG93ZXZlciwgaWYgeW91IGhhdmUg aWRlYXMgaG93IHRoaXMgY291bGQgYmUgZG9uZSwgSTxiciBjbGFzcz0iIj4NCiZndDsgd291bGQg bG92ZSB0byBoZWFyIHRoZW0uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg QWxzbyBpZiB5b3Uga25vdyBvZiBTYWFTIHNvbHV0aW9ucyB3aGVyZSB0aGUgaWRlbnRpdHkgc3Bh Y2UgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7IGhpZXJhcmNoaWNhbCwgcGxlYXNlIHNoYXJlIHRoYXQu IEkgc3RhcnRlZCB0aGlua2luZyB0aGUgc2FtZSB3YXkgYnV0PGJyIGNsYXNzPSIiPg0KJmd0OyBk aWRuwrl0IGZpbmQgYW55IHZlbmRvciB0aGF0IHN1cHBvcnRlZCBpdCBvciBjdXN0b21lcnMgdGhh dCBhc2tlZCBmb3IgaXQuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7IENoZWVycyw8YnIgY2xhc3M9IiI+DQomZ3Q7IE1vcnRlemE8YnIgY2xh c3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBPbiAzLzI1LzE1LCAyOjMzIFBNLCAmcXVv dDtIYWF2YXIgVmFsZXVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGFhdmFyLnZhbGV1ckBj aXRyaXguY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5oYWF2YXIudmFsZXVyQGNpdHJpeC5jb208L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSSB0aGluayBoYXZpbmcgdGhl IE9VcyBiZSBoaWVyYXJjaGljYWwgc2hvdWxkIGJlIGFuIG9wdGlvbiBpZiBhbjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IGV4dGVuc2lvbiB3YXMgYWRkZWQsIGJ1dCBldmVuIHdpdGhvdXQgdGhhdCBJ IHdvdWxkIHRoaW5rIHRoYXQgaXTCuXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBiZW5lZmljaWFs IHRvIGhhdmUgT1VzIGluIHRoZSBBUEkuIFdpdGhvdXQgT1UgcmVwcmVzZW50ZWQgaW4gdGhlIHNj aGVtYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHlvdSB3b3VsZCBoYXZlIGxvb3NlIHJlZmVyZW5j ZXMgdG8gb2JqZWN0cyB0aGF0IGFyZSBjcmVhdGVkIHdpdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyBwcm9wcmlldGFyeSBBUElzIG9yIHNjaGVtYXMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBJwrltIGEgbGl0dGxlIHN1cnByaXNlZCB0aGF0IHRoZSBjb25z ZW5zdXMgd2FzIHRoYXQgU2FhUyBwcm92aWRlcnMgaGF2ZSBhPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgZmxhdCBPVSBzdHJ1Y3R1cmUuIEZyb20gd2hhdCBJwrl2ZSBzZWVuLCBhIGxvdCBvZiBwcm92 aWRlcnMgc3VwcG9ydCBhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgaGllcmFyY2h5ICh3aXRoIGEg c29tZSBub3RhYmxlIGV4Y2VwdGlvbnMpLiBJIHdvdWxkIHRoaW5rIGl0IHdvdWxkIGJlIGE8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBjb21tb24gdXNlIGNhc2UgZm9yIGxhcmdlciBjdXN0b21lcnMg b2YgYSBTYWFTIHByb3ZpZGVyIHRvIHN5bmMgdGhlaXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBl bXBsb3llZSBkaXJlY3RvcnkgdG8gdGhlIHByb3ZpZGVyLCBpbmNsdWRpbmcgT1VzLiBUaGUgT1Vz IHdvdWxkIGJlIHVzZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB0byBzZXQgcGFzc3dvcmQgcG9s aWNlcywgZmVkZXJhdGVkIGxvZ2luIHNldHRpbmdzIGFuZCBhZG1pbmlzdHJhdGlvbiBvcjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IHByb2R1Y3QgcHJpdmlsZWdlcyBvbiB0aGUgU2FhUyBwcm92aWRl ciBzaWRlLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGF2 ZSB0aGUgU2FhUyBwcm92aWRlcnMgY2hhbmdlZCB0aGlzIG92ZXIgdGhlIHllYXJzLCBvciBkbyBJ IGhhdmUgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgd3JvbmcgaW1wcmVzc2lvbj88YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7IE9uIE1hciAyNSwgMjAxNSwgYXQgMTE6NDcgQU0sIE1vcnRlemEgQW5zYXJpICht b3JhbnNhcik8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt b3JhbnNhckBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBJZiB5 b3UgYXJlIHRhbGtpbmcgYWJvdXQgaGllcmFyY2hpY2FsIG9yZ2FuaXphdGlvbiBvZiByZXNvdXJj ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBpbnN0YW5jZXMsPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7IHdlIGhhZCB0aGF0IGRpc2N1c3Npb24gaW4gdGhlIHZlcnkgZWFybHkgZGF5cyBv ZiBTQ0lNIDEuMCB3b3JrLiBJPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IGFjdHVhbGx5PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IHRoaW5rIEkgYnJvdWdodCB0aGF0IHVwIGFzIGEgcmVx dWVzdCBidXQgYWZ0ZXIgdGFsa2luZyB0byBvdGhlciB2ZW5kb3JzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7IGl0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IHNlZW1lZCBldmVyeSBTYWFT IHNlcnZpY2Ugd2FzIGRvaW5nIGEgZmxhdCBuYW1lIHNwYWNlIGZvciB1c2VycyAmYW1wOyBncm91 cHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgYW5kIG5vYm9keSBoYWQgYSByZXF1ZXN0IGZy b20gY3VzdG9tZXJzIGZvciBhIGhpZXJhcmNoaWNhbCBtb2RlbCBzbyB0aGU8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsgZmVhdHVyZSB3YXMgZHJvcHBlZC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZn dDsgQ2hlZXJzLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBNb3J0ZXphPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IE9uIDMvMjQvMTUsIDY6 NTQgUE0sICZxdW90O0hhYXZhciBWYWxldXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWF2 YXIudmFsZXVyQGNpdHJpeC5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPmhhYXZhci52YWxldXJAY2l0cml4LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jmd0OyZndDsgSGFzIHRoZXJlIGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5kIGEgc3RhbmRhcmQg U0NJTSBleHRlbnNpb24gdGhhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgaGFuZGxl cyBvcmdhbml6YXRpb25hbCB1bml0cyAoT1UpPyBBIHF1aWNrIGdvb2dsZSBzZWFyY2ggY2FtZSB1 cCB3aXRoIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvdXBsZSBvZiBlbWFpbHMg ZnJvbSAzIHllYXJzIGFnbywgYnV0IG5vIHJlYWwgc3Vic2lkZW5jZS48YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGVyZSBo YXMgbm90IGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5kIHRoaXMsIGlzIHRoZXJlIGEgcmVhc29u IGZvcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgaXQ/PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgQmVzdDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgSGFhdmFyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgc2NpbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zY2ltQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vc2VjdXJlLXdlYi5jaXNjby5jb20vMU5UNXpXcV9WLXh1OVFDUi02 Qi1UdDdYbjBGZVRSWmlfOG42OEQ0ejlTaSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vc2Vj dXJlLXdlYi5jaXNjby5jb20vMU5UNXpXcV9WLXh1OVFDUi02Qi1UdDdYbjBGZVRSWmlfOG42OEQ0 ejlTaTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEVIZGNXWGlOMmN4YnllOGY0 OXdzWHh6UGhXSmxHX2VqQjM0N01zLTFTNThydWhWY3dJZHI0RkJxQ2VkclRlRGJzWFduWlBITDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsgMExMbzVhNnRFTUxUUDM1WkJRQ1lBdkliTWRO dlA3SjJHZ0VXNWVkTGtDcHNUTFZDSnppYUVrWHRrL2h0dHBzJTNBJTJGJTJGPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VjdXJlLXdl Yi5jaXNjby5jb20vMUV1Nl9RR3A3VDIzT3liZ3lPNlIwWUJjcmsyZ0E1SDZfVnEtQXJiZUdUN0NP R09jSUN3UUJ5VkJVcGxNcjhPOENsSElMaTlPNmxOb2ZSV2lGV0g2eXdYZ1B3ZjBKNXZaTDhUdUpB WVhSVmFjV211aHFFN3dVZ0tsMzRoZnMwZi1NcnB5azBjWlVFZjdrMWdGb3RZV2JNZDBfMkJXTVJf TnRHTkFJM3BZdl82S3J0RHgzZEowMHNlTW1QaWdzTE5VdS9odHRwJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2NpbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHA6 Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xRXU2X1FHcDdUMjNPeWJneU82UjBZQmNyazJnQTVINl9W cS1BcmJlR1Q3Q09HT2NJQ3dRQnlWQlVwbE1yOE84Q2xISUxpOU82bE5vZlJXaUZXSDZ5d1hnUHdm MEo1dlpMOFR1SkFZWFJWYWNXbXVocUU3d1VnS2wzNGhmczBmLU1ycHlrMGNaVUVmN2sxZ0ZvdFlX Yk1kMF8yQldNUl9OdEdOQUkzcFl2XzZLcnREeDNkSjAwc2VNbVBpZ3NMTlV1L2h0dHAlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltPC9hPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9 IiI+DQpzY2ltIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzY2lt QGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5zY2ltQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0 dHBzOi8vc2VjdXJlLXdlYi5jaXNjby5jb20vMVRtUGcyTlNocHZiZU5FeWwwMGtUMENvNUFHUnM0 QVBkWms5MHhuckFNQzNOTWtHOU96YnFIVHB2QUdpcG9WMklaUHhlYVNXSGVSc1ZzNElnTi1RcUFH clJXZWU0SVdWc3hsUVd2dmJVQW5IQnRBYlpVSjUxMlFfU0U4alVJZVVlQ1RoQzZIRmNVYVd1ajF6 M0tSS1ZFaGpwTVJmN2R0Y1NFWWFRTTZ0VHA0WXE1ZzBaWnJLMXVXTGNsTS1TQTUtTS9odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNjaW0iIHRhcmdldD0i X2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5odHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFUbVBnMk5TaHB2YmVORXls MDBrVDBDbzVBR1JzNEFQZFprOTB4bnJBTUMzTk1rRzlPemJxSFRwdkFHaXBvVjJJWlB4ZWFTV0hl UnNWczRJZ04tUXFBR3JSV2VlNElXVnN4bFFXdnZiVUFuSEJ0QWJaVUo1MTJRX1NFOGpVSWVVZUNU aEM2SEZjVWFXdWoxejNLUktWRWhqcE1SZjdkdGNTRVlhUU02dFRwNFlxNWcwWlpySzF1V0xjbE0t U0E1LU0vaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz Y2ltPC9hPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9A06244CAB734AAA8E8F26229B1CA5C7citrixcom_-- From nobody Wed Apr 29 19:31: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 3FBEC1A90BF for ; Wed, 29 Apr 2015 19:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 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, 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 SxA1De-N4PwK for ; Wed, 29 Apr 2015 19:31:31 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 C7E9F1A90B8 for ; Wed, 29 Apr 2015 19:31:30 -0700 (PDT) Received: by wief7 with SMTP id f7so2695604wie.0 for ; Wed, 29 Apr 2015 19:31:29 -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=XtjRR//+s5U9UKsR5h4OJDAe3pxEezoLrVjHkRcb8bk=; b=sszIwKlLL9oC60bx1IRUTGhz/NEqO8flBQ7w1txp7oHGCbVAdHg93XGFlc3wLMw1Y1 fkLGGd79icb8nrsN8DQbI37fcA1zUjX9riQq1QxYXyiGNlZhXVEe+lKCIRs5zfeG0Doy z9GhxYYJqL1ls2i2i9EYEkQHBpisHBBOtXtUPq9DL9yRmbe59xNYr1qQhpOt0CbmtAfl +wqaZc+YSu7urWnT9wpMn4URUV8jyEMiROF1eM/qmU/CuYSI9mlz8yBaoyk78ziYGx1U cCc1ykJCEBEv9IfuDYJBj/7Arzl7ylEq8YZfa/gVnE0OtovrNEdwUdqfyGwpD6Hm+0HW 5FWA== MIME-Version: 1.0 X-Received: by 10.181.11.227 with SMTP id el3mr1029884wid.87.1430361089608; Wed, 29 Apr 2015 19:31:29 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.6.2 with HTTP; Wed, 29 Apr 2015 19:31:29 -0700 (PDT) Date: Thu, 30 Apr 2015 12:31:29 +1000 X-Google-Sender-Auth: 4FMFJrdt0AIpDuw1DmlI1xIdAfk Message-ID: From: Grahame Grieve To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=f46d043be25ea592400514e7e4c9 Archived-At: Subject: [scim] Standard security response 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, 30 Apr 2015 02:31:32 -0000 --f46d043be25ea592400514e7e4c9 Content-Type: text/plain; charset=UTF-8 If a client tries to use a SCIM (2.0) interface, and it must use authenticate to the service first, is there a standard response to tell clients how to go about doing that? thanks Grahame -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --f46d043be25ea592400514e7e4c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If a client tries to use a SCIM (2.0) interface, and it mu= st use authenticate to the service first, is there a standard response to t= ell clients how to go about doing that?=C2=A0

--f46d043be25ea592400514e7e4c9-- From nobody Wed Apr 29 19:41: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 427281A90D5 for ; Wed, 29 Apr 2015 19:41:46 -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 GA1mkMzEemVp for ; Wed, 29 Apr 2015 19:41:44 -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 AE7B61A90D3 for ; Wed, 29 Apr 2015 19:41:44 -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 t3U2fcFH031319 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 02:41:38 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t3U2fca0027994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2015 02:41:38 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3U2fb08010074; Thu, 30 Apr 2015 02:41:37 GMT Received: from [25.91.163.112] (/24.114.39.234) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Apr 2015 19:41:37 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-3D78BA8E-6799-475E-BC8C-8A9DAA7E10C3 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 29 Apr 2015 19:41:35 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Grahame Grieve X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Standard security response 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, 30 Apr 2015 02:41:46 -0000 --Apple-Mail-3D78BA8E-6799-475E-BC8C-8A9DAA7E10C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The spec follows 7235 which means status 401 is returned with www-authentica= te headers listing supported authen schemes.=20 Phil > On Apr 29, 2015, at 19:31, Grahame Grieve wrote: >=20 > If a client tries to use a SCIM (2.0) interface, and it must use authentic= ate to the service first, is there a standard response to tell clients how t= o go about doing that?=20 >=20 > thanks > Grahame >=20 >=20 > --=20 > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.au= / +61 411 867 065 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-3D78BA8E-6799-475E-BC8C-8A9DAA7E10C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The spec follows 7235 which means stat= us 401 is returned with www-authenticate headers listing supported authen sc= hemes. 

Phil

On Apr 29, 2015, at 19:31, Grahame Gr= ieve <grahame@healt= hintersections.com.au> wrote:

=
If a client tries to use a SCIM (2.0) interface, and i= t must use authenticate to the service first, is there a standard response t= o tell clients how to go about doing that? 

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-3D78BA8E-6799-475E-BC8C-8A9DAA7E10C3-- From nobody Wed Apr 29 19:57: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 668101A86E8 for ; Wed, 29 Apr 2015 19:57:11 -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 X3VSNaV7xpmd for ; Wed, 29 Apr 2015 19:57:10 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 B209B1A6FFA for ; Wed, 29 Apr 2015 19:57:09 -0700 (PDT) Received: by wizk4 with SMTP id k4so2436678wiz.1 for ; Wed, 29 Apr 2015 19:57:08 -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=G1+ltVoaXfKFhiZpQ5FsbcGlCn4mmXyx2DGmegbCbgM=; b=XdUiQBDcntKThWAHK6uDwAubnNkfhZPniZgp2/70n2/v2R/4gyDZBLCaW1jIc9u+5z xzSMjM+mChmcZeKKvR2u42mnA3dsVDs+u95+TxJuXtaP7jYjlnwfFCHS0WJbWQNiQ2Ke R2TPmTAXwlP3OHZCGMAdB1wgB34E6AcV+xLb5mGP1ealD8QHbSt/KUsuGSLnt26OK8tV QdijqY/NmvwvQNh5YraYUc8tFJAPShYTzoFrHXoS0tFRMf8YKgQBf4hzhfkCTXBQrKUm vkQjDU0UC7MkWEoz68J4t8AlqZ5mjPYdI49Lnf1tAQ6sbjfcQEKb4l60mg6Wop6bVXF7 N0+Q== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr4173892wjc.14.1430362628479; Wed, 29 Apr 2015 19:57:08 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.6.2 with HTTP; Wed, 29 Apr 2015 19:57:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Apr 2015 12:57:08 +1000 X-Google-Sender-Auth: Gx9DaWUxAlO8WkNtOjRd_NNowek Message-ID: From: Grahame Grieve To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7bb70c585ede4f0514e840b7 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Standard security response 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, 30 Apr 2015 02:57:11 -0000 --047d7bb70c585ede4f0514e840b7 Content-Type: text/plain; charset=UTF-8 thanks. This was my real question: http://stackoverflow.com/questions/940206/what-should-i-pass-for-the-www-authenticate-header-on-401s-if-im-only-using-ope ..and whether there is a SCIM specific answer for this. But it's probably the wrong place to ask this. sorry Grahame On Thu, Apr 30, 2015 at 12:41 PM, Phil Hunt wrote: > The spec follows 7235 which means status 401 is returned with > www-authenticate headers listing supported authen schemes. > > Phil > > On Apr 29, 2015, at 19:31, Grahame Grieve < > grahame@healthintersections.com.au> wrote: > > If a client tries to use a SCIM (2.0) interface, and it must use > authenticate to the service first, is there a standard response to tell > clients how to go about doing that? > > thanks > Grahame > > > -- > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.au > / +61 411 867 065 > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --047d7bb70c585ede4f0514e840b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
thanks. This was my real question:=C2=A0http://stackoverflow.com/questions= /940206/what-should-i-pass-for-the-www-authenticate-header-on-401s-if-im-on= ly-using-ope

..and whether there is a SCIM specific = answer for this. But it's probably the wrong place to ask this. sorry

Grahame




On T= hu, Apr 30, 2015 at 12:41 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
The s= pec follows 7235 which means status 401 is returned with www-authenticate h= eaders listing supported authen schemes.=C2=A0

Phil

On Apr 29, 2015, at 19:31, Grahame Grieve <grahame@he= althintersections.com.au> wrote:

If a client tries to use a SCIM (2.0) interface, = and it must use authenticate to the service first, is there a standard resp= onse to tell clients how to go about doing that?=C2=A0

t= hanks
Grahame
_______= ________________________________________
scim mailing list<= /span>
scim@iet= f.org
https://www.ietf.org/mailman/listinfo/scim



--
-----
http://www.healthinters= ections.com.au / grahame@healthintersections.com.au / +61 411 867 065<= /div>
--047d7bb70c585ede4f0514e840b7-- From nobody Wed Apr 29 20:15: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 E4BDE1A8FD4 for ; Wed, 29 Apr 2015 20:15:03 -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 ihpwvdCDl9Gn for ; Wed, 29 Apr 2015 20:15: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 378E11A8F4B for ; Wed, 29 Apr 2015 20:15:02 -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 t3U3ExQO011801 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 03:14:59 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 t3U3Ewau030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2015 03:14:59 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 t3U3EwHJ021018; Thu, 30 Apr 2015 03:14:58 GMT Received: from [25.91.163.112] (/24.114.39.234) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Apr 2015 20:14:58 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-F06A8B92-852D-4252-824D-2FE66746CC6D Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 29 Apr 2015 20:14:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Grahame Grieve X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Standard security response 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, 30 Apr 2015 03:15:04 -0000 --Apple-Mail-F06A8B92-852D-4252-824D-2FE66746CC6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes. That would be defined by the OIDC specs.=20 Phil > On Apr 29, 2015, at 19:57, Grahame Grieve wrote: >=20 > thanks. This was my real question: http://stackoverflow.com/questions/9402= 06/what-should-i-pass-for-the-www-authenticate-header-on-401s-if-im-only-usi= ng-ope >=20 > ..and whether there is a SCIM specific answer for this. But it's probably t= he wrong place to ask this. sorry >=20 > Grahame >=20 >=20 >=20 >=20 >> On Thu, Apr 30, 2015 at 12:41 PM, Phil Hunt wrote:= >> The spec follows 7235 which means status 401 is returned with www-authent= icate headers listing supported authen schemes.=20 >>=20 >> Phil >>=20 >>> On Apr 29, 2015, at 19:31, Grahame Grieve wrote: >>>=20 >>> If a client tries to use a SCIM (2.0) interface, and it must use authent= icate to the service first, is there a standard response to tell clients how= to go about doing that?=20 >>>=20 >>> thanks >>> Grahame >>>=20 >>>=20 >>> --=20 >>> ----- >>> http://www.healthintersections.com.au / grahame@healthintersections.com.= au / +61 411 867 065 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > ----- > http://www.healthintersections.com.au / grahame@healthintersections.com.au= / +61 411 867 065 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-F06A8B92-852D-4252-824D-2FE66746CC6D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. That would be defined by the OIDC= specs. 

Phil

On Apr 29, 2015, at 19:57, Grahame G= rieve <grahame@heal= thintersections.com.au> wrote:

thanks. This was my real question: http://stackoverflow.com/questi= ons/940206/what-should-i-pass-for-the-www-authenticate-header-on-401s-if-im-= only-using-ope

..and whether there is a SCIM specific= answer for this. But it's probably the wrong place to ask this. sorry
=

Grahame




On Thu, Ap= r 30, 2015 at 12:41 PM, Phil Hunt <phil.hunt@oracle.com> wr= ote:
The spec follow= s 7235 which means status 401 is returned with www-authenticate headers list= ing supported authen schemes. 

Phil
=

On Apr 29, 2015, at 19:31, Grahame Grieve <grahame@healthintersectio= ns.com.au> wrote:

If a client tries to use a SCIM (2.0) interface, and it must use a= uthenticate to the service first, is there a standard response to tell clien= ts how to go about doing that? 

thanks
Gra= hame
________= _______________________________________
scim mailing list
scim@ietf.o= rg
https://www.ietf.org/mailman/listinfo/scim



=
--
-----
http://www.healthintersections.= com.au / grahame@healthintersections.com.au / +61 411 867 065
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-F06A8B92-852D-4252-824D-2FE66746CC6D-- From nobody Thu Apr 30 06:42: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 816E01B2A28 for ; Thu, 30 Apr 2015 06:42:00 -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 HdN84tGFQjh8 for ; Thu, 30 Apr 2015 06:41:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607C51B2A22 for ; Thu, 30 Apr 2015 06:41:57 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB390.namprd04.prod.outlook.com (10.141.60.147) with Microsoft SMTP Server (TLS) id 15.1.148.16; Thu, 30 Apr 2015 13:41:37 +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.008; Thu, 30 Apr 2015 13:41:37 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAAKSYCAAOjR4A== Date: Thu, 30 Apr 2015 13:41:36 +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: 35A21972009B7635A21ABF authentication-results: oracle.com; 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:BN1PR04MB390; 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:BN1PR04MB390; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB390; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(51444003)(24454002)(377454003)(19609705001)(19617315012)(92566002)(99286002)(74316001)(15975445007)(46102003)(106116001)(33656002)(16236675004)(5001960100002)(40100003)(76576001)(66066001)(19625215002)(16601075003)(86362001)(2950100001)(102836002)(2900100001)(2656002)(87936001)(76176999)(54356999)(19580405001)(50986999)(122556002)(77156002)(19580395003)(19300405004)(110136002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB390; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB39256D787E65BC06C1ACD28E2D60BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2015 13:41:36.8768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB390 Archived-At: Cc: Patrick Radtke , SCIM WG 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: Thu, 30 Apr 2015 13:42:00 -0000 --_000_BN1PR04MB39256D787E65BC06C1ACD28E2D60BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYWQgZm9yZ290dGVuIGFib3V0IHRoYXQuICBUaGUgbW9zdCBkaXNjdXNzaW9uIHRoYXQgSSBm b3VuZCB3YXMgaW4gdGhpcyBlbWFpbCAtIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zY2ltL2N1cnJlbnQvbXNnMDIwMDcuaHRtbC4NCg0KICAgTm90ZSwgdGhlIHNjaGVtYSBh bHNvIG5lZWRzIHRvIGJlIHVwZGF0ZWQuIEl0IGxvb2tzIGxpa2UgaXQgc2hvdWxkIGJlIG11bHRp LXZhbHVlZA0KICBzaW5jZSBtYW55IG9yZ3MgaGF2ZSBwZW9wbGUgd2l0aCBtdWx0aXBsZSByZXBv cnRpbmcgcmVsYXRpb25zaGlwcy4NCg0KSSBkb27igJl0IHJlbWVtYmVyIGV2ZXIgZGlzY3Vzc2lu ZyB0aGlzIGFueSBmdXJ0aGVyIG9yIGlmIHdlIGFjaGlldmVkIGNvbnNlbnN1cyBvbiBjaGFuZ2lu ZyB0aGlzLiAgVGhlIGVtYWlsIHRocmVhZCBkb2VzbuKAmXQgaGF2ZSBhbnkgbW9yZSBkaXNjdXNz aW9uLg0KDQpJ4oCZbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBt dWx0aXZhbHVlZC4gIElmIGFueXRoaW5nIGVsc2UsIEkgd291bGQgbmV2ZXIgd2lzaCBtdWx0aXBs ZSBtYW5hZ2VycyB1cG9uIGFueW9uZS4gOykgIEJlaW5nIHNlcmlvdXMsIHRob3VnaCwgdGhpcyBt aWdodCBmaXQgYmV0dGVyIGFzIGEgc2Vjb25kIGF0dHJpYnV0ZSB0aGF0IGRlc2NyaWJlcyBvdGhl ciByZXBvcnRpbmcgcmVsYXRpb25zaGlwcy4NCg0KQW55b25lIGVsc2UgcmVtZW1iZXIgdGhpcz8N Cg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDI5LCAyMDE1IDY6NDEgUE0NClRvOiBLZWxseSBHcml6emxlDQpDYzog UGF0cmljayBSYWR0a2U7IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBNYW5hZ2VyIGF0dHJpYnV0ZSB3 b3JkaW5nIHN1Z2dlc3Rpb24NCg0KSSBiZWxpZXZlIEkgcmFpc2VkIHRoaXMgaXNzdWUgYmVmb3Jl IGFuZCB0aGUgY29uc2Vuc3VzIHdhcyB0byBsZWF2ZSBpdC4gIE1heWJlIEkgYW0gbWlzdGFrZW4/ DQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8v d3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPg0KDQpPbiBBcHIgMjksIDIwMTUsIGF0IDQ6MDYgUE0sIEtlbGx5IEdy aXp6bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBz YWlscG9pbnQuY29tPj4gd3JvdGU6DQoNClBhdHJpY2sg4oCmIHRoYW5rcyBmb3IgdGhlIGZlZWRi YWNrLg0KDQpJIHRoaW5rIHRoYXQgdGhlIHNjaGVtYSBzZWN0aW9uIGlzIGluY29ycmVjdC4gIFRo ZSAkcmVmIGFuZCB2YWx1ZSBhcmUgcmVxdWlyZWQgYW5kIG1hbmFnZXIgaXMgc3RpbGwgc2luZ2xl IHZhbHVlZC4gIEkgdGhpbmsgdGhlIHRleHQgaW4gNC4zIHNob3VsZCBzYXk6DQoNCm1hbmFnZXIN Cg0KICAgICAgVGhlIHVzZXIncyBtYW5hZ2VyLiAgQSBjb21wbGV4IHR5cGUgdGhhdCBvcHRpb25h bGx5IGFsbG93cyBzZXJ2aWNlDQoNCiAgICAgIHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5p emF0aW9uYWwgaGllcmFyY2h5IGJ5IHJlZmVyZW5jaW5nIHRoZQ0KDQogICAgICAiaWQiIGF0dHJp YnV0ZSBvZiBhbm90aGVyIFVzZXIuDQoNClBoaWwsIGRvIHlvdSBhZ3JlZT8NCg0KLS1LZWxseQ0K DQpGcm9tOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UGF0cmljayBSYWR0a2UNClNlbnQ6IEZyaWRheSwgQXByaWwgMjQsIDIwMTUgNTo0NyBQTQ0KVG86 IFNDSU0gV0cNClN1YmplY3Q6IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dl c3Rpb24NCg0KVGhlcmUgYXJlIGEgY291cGxlIGFzcGVjdHMgb2YgdGhlIOKAnG1hbmFnZXLigJ0g YXR0cmlidXRlIHRoYXQgc2VlbSBpbmNvbnNpc3RlbnQuDQoNCkluIDQuMyBFbnRlcnByaXNlIFVz ZXIgU2NoZW1hIGV4dGVuc2lvbiBpdCBzYXlzDQoibWFuYWdlcg0KDQogICAgICBUaGUgdXNlcidz IG1hbmFnZXIuICBBIGNvbXBsZXggdHlwZSB0aGF0IG9wdGlvbmFsbHkgYWxsb3dzIHNlcnZpY2UN Cg0KICAgICAgcHJvdmlkZXJzIHRvIHJlcHJlc2VudCBvcmdhbml6YXRpb25hbCBoaWVyYXJjaHkg YnkgcmVmZXJlbmNpbmcgdGhlDQoNCiAgICAgICJpZCIgYXR0cmlidXRlIG9mIGFub3RoZXIgVXNl ci4NCg0KDQoNCiAgICAgIHZhbHVlICBUaGUgImlkIiBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXBy ZXNlbnRpbmcgdGhlIHVzZXIncw0KDQogICAgICAgICBtYW5hZ2VyLiAgUkVDT01NRU5ERUQuDQoN Cg0KDQogICAgICAkcmVmICBUaGUgVVJJIG9mIHRoZSBTQ0lNIHJlc291cmNlIHJlcHJlc2VudGlu ZyB0aGUgVXNlcidzDQoNCiAgICAgICAgIG1hbmFnZXIuICBSRUNPTU1FTkRFRC4NCuKAnA0KVG8g bWUgdGhhdCBzYXlzIHRoYXQgYSB1c2VyIG1heSBoYXZlIGEgc2luZ2xlIG1hbmFnZXIsIGFuZCDi gJh2YWx1ZeKAmSBhbmQg4oCYJHJlZuKAmSBhdHRyaWJ1dGVzIGFyZSBub3QgcmVxdWlyZWQuDQoN Ckhvd2V2ZXIgaW4gdGhlIFNjaGVtYSBzZWN0aW9uLCBtYW5hZ2VyIGlzIGxpc3RlZCBhcyAibXVs dGlWYWx1ZWQ6IHRydWXigJ0gYW5kIHRob3VnaCBzdWJBdHRyaWJ1dGVzIG9mIOKAnCRyZWbigJ0g YW5kIOKAnHZhbHVl4oCdIGhhdmUg4oCccmVxdWlyZWQ6ZmFsc2XigJ0gdGhlIGRlc2NyaXB0aW9u IGF0dHJpYnV0ZSBzYXlzIGVhY2ggaXMgcmVxdWlyZWQuDQoNCklmIOKAnHZhbHVl4oCdIGFuZCDi gJwkcmVm4oCdIGFyZW7igJl0IHJlcXVpcmVkLCBjYW4gdGhlIE1hbmFnZXIgc2NoZW1hIGRlc2Ny aXB0aW9uIGJlIGFkanVzdGVkPw0KU2luY2UgbWFuYWdlciBpcyBtdWx0aS12YWx1ZWQsIGNhbiBz ZWN0aW9uIDQuMyBiZSB1cGRhdGVkIHRvIHNheS4gIlRoZSB1c2VyJ3MgbWFuYWdlcnMuICBBIG11 bHRpLXZhbHVlZCBjb21wbGV4IHR5cGUgdGhhdOKApuKAnSAgT3RoZXJ3aXNlLCBhdCBmaXJzdCBy ZWFkIChvciBmb3IgYW55b25lIGNvbWluZyBmcm9tIFNDSU0gMS4xKSBpdCBpcyBub3Qgb2J2aW91 cyB0aGF0IGl0IGhhcyBiZWNvbWUgbXVsdGktdmFsdWVkLg0KDQpUaGFua3MsDQoNClBhdHJpY2sN Cg0KDQoNCg0KDQo= --_000_BN1PR04MB39256D787E65BC06C1ACD28E2D60BN1PR04MB392namprd_ 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 aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFw cGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgaGFkIGZvcmdvdHRlbiBhYm91dCB0aGF0LiZuYnNwOyBUaGUgbW9zdCBkaXNjdXNz aW9uIHRoYXQgSSBmb3VuZCB3YXMgaW4gdGhpcyBlbWFpbCAtDQo8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2NpbS9jdXJyZW50L21zZzAyMDA3Lmh0bWwiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQvbXNnMDIwMDcu aHRtbDwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+Tm90ZSwgdGhlIHNjaGVtYSBhbHNvIG5lZWRzIHRv IGJlIHVwZGF0ZWQuIEl0IGxvb2tzIGxpa2UgaXQgc2hvdWxkIGJlIG11bHRpLXZhbHVlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgc2luY2UgbWFueSBvcmdzIGhhdmUgcGVv cGxlIHdpdGggbXVsdGlwbGUgcmVwb3J0aW5nIHJlbGF0aW9uc2hpcHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRv buKAmXQgcmVtZW1iZXIgZXZlciBkaXNjdXNzaW5nIHRoaXMgYW55IGZ1cnRoZXIgb3IgaWYgd2Ug YWNoaWV2ZWQgY29uc2Vuc3VzIG9uIGNoYW5naW5nIHRoaXMuJm5ic3A7IFRoZSBlbWFpbCB0aHJl YWQgZG9lc27igJl0IGhhdmUgYW55IG1vcmUgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIG5v dCBzdXJlIHRoYXQgSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIG11bHRpdmFsdWVkLiZuYnNw OyBJZiBhbnl0aGluZyBlbHNlLCBJIHdvdWxkIG5ldmVyIHdpc2ggbXVsdGlwbGUgbWFuYWdlcnMg dXBvbiBhbnlvbmUuIDspJm5ic3A7IEJlaW5nIHNlcmlvdXMsIHRob3VnaCwgdGhpcw0KIG1pZ2h0 IGZpdCBiZXR0ZXIgYXMgYSBzZWNvbmQgYXR0cmlidXRlIHRoYXQgZGVzY3JpYmVzIG90aGVyIHJl cG9ydGluZyByZWxhdGlvbnNoaXBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55b25lIGVsc2UgcmVtZW1iZXIgdGhp cz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMTUgNjo0 MSBQTTxicj4NCjxiPlRvOjwvYj4gS2VsbHkgR3JpenpsZTxicj4NCjxiPkNjOjwvYj4gUGF0cmlj ayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1hbmFnZXIgYXR0cmli dXRlIHdvcmRpbmcgc3VnZ2VzdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSBJIHJhaXNlZCB0aGlzIGlzc3VlIGJlZm9yZSBhbmQgdGhl IGNvbnNlbnN1cyB3YXMgdG8gbGVhdmUgaXQuICZuYnNwO01heWJlIEkgYW0gbWlzdGFrZW4/PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j b20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEFwciAyOSwgMjAxNSwgYXQgNDowNiBQTSwgS2VsbHkgR3JpenpsZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+a2VsbHkuZ3Jp enpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UGF0cmljayDigKYgdGhhbmtzIGZvciB0aGUgZmVlZGJhY2suPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHRoaW5rIHRoYXQgdGhlIHNjaGVtYSBzZWN0aW9uIGlzIGluY29ycmVjdC4mbmJzcDsgVGhlICRy ZWYgYW5kIHZhbHVlIGFyZSByZXF1aXJlZCBhbmQgbWFuYWdlciBpcyBzdGlsbCBzaW5nbGUgdmFs dWVkLiZuYnNwOyBJIHRoaW5rIHRoZSB0ZXh0IGluIDQuMyBzaG91bGQgc2F5Ojwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1hbmFnZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7d2lk b3dzOiAxIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHVz ZXIncyBtYW5hZ2VyLiZuYnNwOyBBIGNvbXBsZXggdHlwZSB0aGF0IG9wdGlvbmFsbHkgYWxsb3dz IHNlcnZpY2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5IGJ5IHJlZmVy ZW5jaW5nIDxzPnRoZTwvcz48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7IGF0dHJpYnV0ZSBvZjwvc3Bhbj48L3M+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IGFub3RoZXIgVXNlci48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGhpbCwgZG8geW91IGFncmVlPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LS1LZWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gWzxhIGhyZWY9Im1haWx0bzpz Y2ltLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5QYXRyaWNrIFJhZHRrZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEFwcmlsIDI0LCAyMDE1IDU6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNDSU0gV0c8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3NjaW1dIE1hbmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGFyZSBhIGNvdXBsZSBhc3BlY3RzIG9m IHRoZSDigJxtYW5hZ2Vy4oCdIGF0dHJpYnV0ZSB0aGF0IHNlZW0gaW5jb25zaXN0ZW50Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JbiA0LjMgRW50ZXJwcmlzZSBVc2VyIFNjaGVtYSBleHRlbnNpb24gaXQgc2F5czwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+bWFuYWdlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzO3dpZG93czogMSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSB1c2VyJ3MgbWFuYWdlci4mbmJzcDsg QSBjb21wbGV4IHR5cGUgdGhhdCBvcHRpb25hbGx5IGFsbG93cyBzZXJ2aWNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlcnMgdG8gcmVwcmVz ZW50IG9yZ2FuaXphdGlvbmFsIGhpZXJhcmNoeSBieSByZWZlcmVuY2luZyB0aGU8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7IGF0 dHJpYnV0ZSBvZiBhbm90aGVyIFVzZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUmbmJzcDsgVGhl ICZxdW90O2lkJnF1b3Q7IG9mIHRoZSBTQ0lNIHJlc291cmNlIHJlcHJlc2VudGluZyB0aGUgdXNl cidzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBtYW5hZ2VyLiZuYnNwOyBSRUNPTU1FTkRFRC48L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAkcmVmJm5ic3A7IFRoZSBVUkkgb2YgdGhlIFNDSU0gcmVzb3VyY2UgcmVwcmVzZW50aW5nIHRo ZSBVc2VyJ3M8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFnZXIuJm5ic3A7IFJFQ09NTUVOREVELjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+4oCcPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBtZSB0 aGF0IHNheXMgdGhhdCBhIHVzZXIgbWF5IGhhdmUgYSBzaW5nbGUgbWFuYWdlciwgYW5kIOKAmHZh bHVl4oCZIGFuZCDigJgkcmVm4oCZIGF0dHJpYnV0ZXMgYXJlIG5vdCByZXF1aXJlZC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SG93ZXZlciBpbiB0aGUgU2NoZW1hIHNlY3Rpb24sIG1hbmFnZXIgaXMgbGlzdGVkIGFz ICZxdW90O211bHRpVmFsdWVkOiB0cnVl4oCdIGFuZCB0aG91Z2ggc3ViQXR0cmlidXRlcyBvZiDi gJwkcmVm4oCdIGFuZCDigJx2YWx1ZeKAnSBoYXZlIOKAnHJlcXVpcmVkOmZhbHNl4oCdIHRoZSBk ZXNjcmlwdGlvbiBhdHRyaWJ1dGUgc2F5cw0KIGVhY2ggaXMgcmVxdWlyZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PklmIOKAnHZhbHVl4oCdIGFuZCDigJwkcmVm4oCdIGFyZW7igJl0IHJlcXVpcmVkLCBjYW4gdGhl IE1hbmFnZXIgc2NoZW1hIGRlc2NyaXB0aW9uIGJlIGFkanVzdGVkPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNp bmNlIG1hbmFnZXIgaXMgbXVsdGktdmFsdWVkLCBjYW4gc2VjdGlvbiA0LjMgYmUgdXBkYXRlZCB0 byBzYXkuICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSB1c2Vy J3MgbWFuYWdlcnMuICZuYnNwO0EgbXVsdGktdmFsdWVkIGNvbXBsZXggdHlwZQ0KIHRoYXTigKbi gJ0gJm5ic3A7T3RoZXJ3aXNlLCBhdCBmaXJzdCByZWFkIChvciBmb3IgYW55b25lIGNvbWluZyBm cm9tIFNDSU0gMS4xKSBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IGl0IGhhcyBiZWNvbWUgbXVsdGkt dmFsdWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBhdHJpY2s8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB39256D787E65BC06C1ACD28E2D60BN1PR04MB392namprd_-- From nobody Thu Apr 30 08:28: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 7A4641A6F87 for ; Thu, 30 Apr 2015 08:28:18 -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 4grdQ6zk4A_a for ; Thu, 30 Apr 2015 08:28: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 5AC9E1B2CA4 for ; Thu, 30 Apr 2015 08:28:10 -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 t3UFS8dP031226 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 15:28:09 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t3UFS8ke002281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2015 15:28:08 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 t3UFS7Go021362; Thu, 30 Apr 2015 15:28:07 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Apr 2015 08:28:07 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-FD2C64FF-1DC4-495E-9B21-2148D7C852C2 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Thu, 30 Apr 2015 08:28:05 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Kelly Grizzle X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Patrick Radtke , SCIM WG 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: Thu, 30 Apr 2015 15:28:18 -0000 --Apple-Mail-FD2C64FF-1DC4-495E-9B21-2148D7C852C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I recall your comment and given lack of input at the time, it was clear ther= e was no consensus for change. I had to leave it as is despite thinking it n= eeded to be multi-valued.=20 Phil > 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 --Apple-Mail-FD2C64FF-1DC4-495E-9B21-2148D7C852C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I recall your comment and given lack o= f input at the time, it was clear there was no consensus for change. I had t= o leave it as is despite thinking it needed to be multi-valued. 
<= div>
Phil

On Apr 30, 2015, at 06:41, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; 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 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=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@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 consensu= s was to leave it.  Maybe I am mistaken?

 

 

On Apr 29, 2015, at 4:06 PM, Kelly Grizzle <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

      T=
he user's manager.  A complex type that optionally allows service
      providers t=
o represent organizational hierarchy by referencing the
      "id" at=
tribute of another User.

 

Phil, do you agree?<= o:p>

 

--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=9C= manager=E2=80=9D attribute that seem inconsistent.

 

In 4.3 Enterprise User Schema extension i= t says

"manager

      T=
he user's manager.  A complex type that optionally allows service
      providers t=
o represent organizational hierarchy by referencing the

      "id" attri=
bute 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 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 section 4.3 be updated t=
o 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






 






 






 






 

 

= --Apple-Mail-FD2C64FF-1DC4-495E-9B21-2148D7C852C2-- From nobody Thu Apr 30 10:28: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 460EC1A8894 for ; Thu, 30 Apr 2015 10:28:29 -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 b--VGJ8DejTt for ; Thu, 30 Apr 2015 10:28:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EB41A1A15 for ; Thu, 30 Apr 2015 10:28:23 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.1.148.16; Thu, 30 Apr 2015 17:28:21 +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.008; Thu, 30 Apr 2015 17:28:21 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAAKSYCAAOjR4IAAH7qAgAAhU9A= Date: Thu, 30 Apr 2015 17:28:21 +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: 3671B410009B8E3671B55D authentication-results: oracle.com; 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:BN1PR04MB392; 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:BN1PR04MB392; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB392; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(164054003)(16236675004)(19625215002)(15975445007)(102836002)(2656002)(19300405004)(110136002)(2900100001)(19609705001)(16601075003)(77156002)(99286002)(62966003)(2950100001)(40100003)(76576001)(74316001)(106116001)(46102003)(19580405001)(66066001)(76176999)(92566002)(93886004)(86362001)(33656002)(19617315012)(50986999)(19580395003)(87936001)(54356999)(122556002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB3923BDEDBF0627E18E78A09E2D60BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2015 17:28:21.7930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB392 Archived-At: Cc: Patrick Radtke , SCIM WG 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: Thu, 30 Apr 2015 17:28:29 -0000 --_000_BN1PR04MB3923BDEDBF0627E18E78A09E2D60BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyBhbnlvbmUgaGF2ZSBhbnkgc3Ryb25nIG9waW5pb25zIGFib3V0IG1ha2luZyBtYW5hZ2Vy IG11bHRpLXZhbHVlZCBvciBsZWF2aW5nIGl0IGFzLWlzPw0KDQpFaXRoZXIgd2F5IHdlIHNob3Vs ZCBwcm9iYWJseSBjbGVhbiB1cCB0aGUgdGV4dCBpbiBzZWN0aW9uIDQuMyBhbmQgdGhlIHNjaGVt YSBkZWZpbml0aW9uLg0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAxNSAxMDoyOCBBTQ0KVG86IEtlbGx5 IEdyaXp6bGUNCkNjOiBQYXRyaWNrIFJhZHRrZTsgU0NJTSBXRw0KU3ViamVjdDogUmU6IE1hbmFn ZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbg0KDQpJIHJlY2FsbCB5b3VyIGNvbW1lbnQg YW5kIGdpdmVuIGxhY2sgb2YgaW5wdXQgYXQgdGhlIHRpbWUsIGl0IHdhcyBjbGVhciB0aGVyZSB3 YXMgbm8gY29uc2Vuc3VzIGZvciBjaGFuZ2UuIEkgaGFkIHRvIGxlYXZlIGl0IGFzIGlzIGRlc3Bp dGUgdGhpbmtpbmcgaXQgbmVlZGVkIHRvIGJlIG11bHRpLXZhbHVlZC4NCg0KUGhpbA0KDQpPbiBB cHIgMzAsIDIwMTUsIGF0IDA2OjQxLCBLZWxseSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxw b2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+IHdyb3RlOg0KSSBo YWQgZm9yZ290dGVuIGFib3V0IHRoYXQuICBUaGUgbW9zdCBkaXNjdXNzaW9uIHRoYXQgSSBmb3Vu ZCB3YXMgaW4gdGhpcyBlbWFpbCAtIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9zY2ltL2N1cnJlbnQvbXNnMDIwMDcuaHRtbC4NCg0KICAgTm90ZSwgdGhlIHNjaGVtYSBhbHNv IG5lZWRzIHRvIGJlIHVwZGF0ZWQuIEl0IGxvb2tzIGxpa2UgaXQgc2hvdWxkIGJlIG11bHRpLXZh bHVlZA0KICBzaW5jZSBtYW55IG9yZ3MgaGF2ZSBwZW9wbGUgd2l0aCBtdWx0aXBsZSByZXBvcnRp bmcgcmVsYXRpb25zaGlwcy4NCg0KSSBkb27igJl0IHJlbWVtYmVyIGV2ZXIgZGlzY3Vzc2luZyB0 aGlzIGFueSBmdXJ0aGVyIG9yIGlmIHdlIGFjaGlldmVkIGNvbnNlbnN1cyBvbiBjaGFuZ2luZyB0 aGlzLiAgVGhlIGVtYWlsIHRocmVhZCBkb2VzbuKAmXQgaGF2ZSBhbnkgbW9yZSBkaXNjdXNzaW9u Lg0KDQpJ4oCZbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBtdWx0 aXZhbHVlZC4gIElmIGFueXRoaW5nIGVsc2UsIEkgd291bGQgbmV2ZXIgd2lzaCBtdWx0aXBsZSBt YW5hZ2VycyB1cG9uIGFueW9uZS4gOykgIEJlaW5nIHNlcmlvdXMsIHRob3VnaCwgdGhpcyBtaWdo dCBmaXQgYmV0dGVyIGFzIGEgc2Vjb25kIGF0dHJpYnV0ZSB0aGF0IGRlc2NyaWJlcyBvdGhlciBy ZXBvcnRpbmcgcmVsYXRpb25zaGlwcy4NCg0KQW55b25lIGVsc2UgcmVtZW1iZXIgdGhpcz8NCg0K RnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDI5LCAyMDE1IDY6NDEgUE0NClRvOiBLZWxseSBHcml6emxlDQpDYzogUGF0 cmljayBSYWR0a2U7IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3Jk aW5nIHN1Z2dlc3Rpb24NCg0KSSBiZWxpZXZlIEkgcmFpc2VkIHRoaXMgaXNzdWUgYmVmb3JlIGFu ZCB0aGUgY29uc2Vuc3VzIHdhcyB0byBsZWF2ZSBpdC4gIE1heWJlIEkgYW0gbWlzdGFrZW4/DQoN ClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPg0KDQpPbiBBcHIgMjksIDIwMTUsIGF0IDQ6MDYgUE0sIEtlbGx5IEdyaXp6 bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWls cG9pbnQuY29tPj4gd3JvdGU6DQoNClBhdHJpY2sg4oCmIHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIHNjaGVtYSBzZWN0aW9uIGlzIGluY29ycmVjdC4gIFRoZSAk cmVmIGFuZCB2YWx1ZSBhcmUgcmVxdWlyZWQgYW5kIG1hbmFnZXIgaXMgc3RpbGwgc2luZ2xlIHZh bHVlZC4gIEkgdGhpbmsgdGhlIHRleHQgaW4gNC4zIHNob3VsZCBzYXk6DQoNCm1hbmFnZXINCg0K ICAgICAgVGhlIHVzZXIncyBtYW5hZ2VyLiAgQSBjb21wbGV4IHR5cGUgdGhhdCBvcHRpb25hbGx5 IGFsbG93cyBzZXJ2aWNlDQoNCiAgICAgIHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0 aW9uYWwgaGllcmFyY2h5IGJ5IHJlZmVyZW5jaW5nIHRoZQ0KDQogICAgICAiaWQiIGF0dHJpYnV0 ZSBvZiBhbm90aGVyIFVzZXIuDQoNClBoaWwsIGRvIHlvdSBhZ3JlZT8NCg0KLS1LZWxseQ0KDQpG cm9tOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF0 cmljayBSYWR0a2UNClNlbnQ6IEZyaWRheSwgQXByaWwgMjQsIDIwMTUgNTo0NyBQTQ0KVG86IFND SU0gV0cNClN1YmplY3Q6IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rp b24NCg0KVGhlcmUgYXJlIGEgY291cGxlIGFzcGVjdHMgb2YgdGhlIOKAnG1hbmFnZXLigJ0gYXR0 cmlidXRlIHRoYXQgc2VlbSBpbmNvbnNpc3RlbnQuDQoNCkluIDQuMyBFbnRlcnByaXNlIFVzZXIg U2NoZW1hIGV4dGVuc2lvbiBpdCBzYXlzDQoibWFuYWdlcg0KDQogICAgICBUaGUgdXNlcidzIG1h bmFnZXIuICBBIGNvbXBsZXggdHlwZSB0aGF0IG9wdGlvbmFsbHkgYWxsb3dzIHNlcnZpY2UNCg0K ICAgICAgcHJvdmlkZXJzIHRvIHJlcHJlc2VudCBvcmdhbml6YXRpb25hbCBoaWVyYXJjaHkgYnkg cmVmZXJlbmNpbmcgdGhlDQoNCiAgICAgICJpZCIgYXR0cmlidXRlIG9mIGFub3RoZXIgVXNlci4N Cg0KDQoNCiAgICAgIHZhbHVlICBUaGUgImlkIiBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNl bnRpbmcgdGhlIHVzZXIncw0KDQogICAgICAgICBtYW5hZ2VyLiAgUkVDT01NRU5ERUQuDQoNCg0K DQogICAgICAkcmVmICBUaGUgVVJJIG9mIHRoZSBTQ0lNIHJlc291cmNlIHJlcHJlc2VudGluZyB0 aGUgVXNlcidzDQoNCiAgICAgICAgIG1hbmFnZXIuICBSRUNPTU1FTkRFRC4NCuKAnA0KVG8gbWUg dGhhdCBzYXlzIHRoYXQgYSB1c2VyIG1heSBoYXZlIGEgc2luZ2xlIG1hbmFnZXIsIGFuZCDigJh2 YWx1ZeKAmSBhbmQg4oCYJHJlZuKAmSBhdHRyaWJ1dGVzIGFyZSBub3QgcmVxdWlyZWQuDQoNCkhv d2V2ZXIgaW4gdGhlIFNjaGVtYSBzZWN0aW9uLCBtYW5hZ2VyIGlzIGxpc3RlZCBhcyAibXVsdGlW YWx1ZWQ6IHRydWXigJ0gYW5kIHRob3VnaCBzdWJBdHRyaWJ1dGVzIG9mIOKAnCRyZWbigJ0gYW5k IOKAnHZhbHVl4oCdIGhhdmUg4oCccmVxdWlyZWQ6ZmFsc2XigJ0gdGhlIGRlc2NyaXB0aW9uIGF0 dHJpYnV0ZSBzYXlzIGVhY2ggaXMgcmVxdWlyZWQuDQoNCklmIOKAnHZhbHVl4oCdIGFuZCDigJwk cmVm4oCdIGFyZW7igJl0IHJlcXVpcmVkLCBjYW4gdGhlIE1hbmFnZXIgc2NoZW1hIGRlc2NyaXB0 aW9uIGJlIGFkanVzdGVkPw0KU2luY2UgbWFuYWdlciBpcyBtdWx0aS12YWx1ZWQsIGNhbiBzZWN0 aW9uIDQuMyBiZSB1cGRhdGVkIHRvIHNheS4gIlRoZSB1c2VyJ3MgbWFuYWdlcnMuICBBIG11bHRp LXZhbHVlZCBjb21wbGV4IHR5cGUgdGhhdOKApuKAnSAgT3RoZXJ3aXNlLCBhdCBmaXJzdCByZWFk IChvciBmb3IgYW55b25lIGNvbWluZyBmcm9tIFNDSU0gMS4xKSBpdCBpcyBub3Qgb2J2aW91cyB0 aGF0IGl0IGhhcyBiZWNvbWUgbXVsdGktdmFsdWVkLg0KDQpUaGFua3MsDQoNClBhdHJpY2sNCg0K DQoNCg0KDQo= --_000_BN1PR04MB3923BDEDBF0627E18E78A09E2D60BN1PR04MB392namprd_ 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 Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Eb2Vz IGFueW9uZSBoYXZlIGFueSBzdHJvbmcgb3BpbmlvbnMgYWJvdXQgbWFraW5nIG1hbmFnZXIgbXVs dGktdmFsdWVkIG9yIGxlYXZpbmcgaXQgYXMtaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxicj4NCkVpdGhlciB3YXkgd2Ugc2hvdWxkIHByb2JhYmx5IGNsZWFuIHVwIHRoZSB0ZXh0 IGluIHNlY3Rpb24gNC4zIGFuZCB0aGUgc2NoZW1hIGRlZmluaXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAz MCwgMjAxNSAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gS2VsbHkgR3JpenpsZTxicj4NCjxiPkNj OjwvYj4gUGF0cmljayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1h bmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlY2FsbCB5b3VyIGNvbW1lbnQgYW5k IGdpdmVuIGxhY2sgb2YgaW5wdXQgYXQgdGhlIHRpbWUsIGl0IHdhcyBjbGVhciB0aGVyZSB3YXMg bm8gY29uc2Vuc3VzIGZvciBjaGFuZ2UuIEkgaGFkIHRvIGxlYXZlIGl0IGFzIGlzIGRlc3BpdGUg dGhpbmtpbmcgaXQgbmVlZGVkIHRvIGJlIG11bHRpLXZhbHVlZC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gQXByIDMwLCAyMDE1LCBhdCAwNjo0MSwgS2VsbHkg R3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+ a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhZCBmb3Jnb3R0ZW4gYWJvdXQgdGhhdC4mbmJz cDsgVGhlIG1vc3QgZGlzY3Vzc2lvbiB0aGF0IEkgZm91bmQgd2FzIGluIHRoaXMgZW1haWwgLQ0K PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NjaW0vY3VycmVu dC9tc2cwMjAwNy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2Np bS9jdXJyZW50L21zZzAyMDA3Lmh0bWw8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2siPk5vdGUsIHRoZSBz Y2hlbWEgYWxzbyBuZWVkcyB0byBiZSB1cGRhdGVkLiBJdCBsb29rcyBsaWtlIGl0IHNob3VsZCBi ZSBtdWx0aS12YWx1ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7IHNpbmNl IG1hbnkgb3JncyBoYXZlIHBlb3BsZSB3aXRoIG11bHRpcGxlIHJlcG9ydGluZyByZWxhdGlvbnNo aXBzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHJlbWVtYmVyIGV2ZXIgZGlzY3Vzc2luZyB0aGlzIGFu eSBmdXJ0aGVyIG9yIGlmIHdlIGFjaGlldmVkIGNvbnNlbnN1cyBvbiBjaGFuZ2luZyB0aGlzLiZu YnNwOyBUaGUgZW1haWwgdGhyZWFkIGRvZXNu4oCZdCBoYXZlIGFueSBtb3JlIGRpc2N1c3Npb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5J4oCZbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBi ZSBtdWx0aXZhbHVlZC4mbmJzcDsgSWYgYW55dGhpbmcgZWxzZSwgSSB3b3VsZCBuZXZlciB3aXNo IG11bHRpcGxlIG1hbmFnZXJzIHVwb24gYW55b25lLiA7KSZuYnNwOyBCZWluZyBzZXJpb3VzLCB0 aG91Z2gsIHRoaXMNCiBtaWdodCBmaXQgYmV0dGVyIGFzIGEgc2Vjb25kIGF0dHJpYnV0ZSB0aGF0 IGRlc2NyaWJlcyBvdGhlciByZXBvcnRpbmcgcmVsYXRpb25zaGlwcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFueW9u ZSBlbHNlIHJlbWVtYmVyIHRoaXM/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQgWzxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDE1 IDY6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEtlbGx5IEdyaXp6bGU8YnI+DQo8Yj5DYzo8L2I+IFBh dHJpY2sgUmFkdGtlOyBTQ0lNIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNYW5hZ2VyIGF0 dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgSSByYWlzZWQgdGhpcyBpc3N1ZSBiZWZvcmUgYW5k IHRoZSBjb25zZW5zdXMgd2FzIHRvIGxlYXZlIGl0LiAmbmJzcDtNYXliZSBJIGFtIG1pc3Rha2Vu PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50 aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMjksIDIwMTUsIGF0IDQ6MDYgUE0sIEtlbGx5IEdyaXp6 bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iPmtlbGx5 LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBhdHJpY2sg4oCmIHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB0aGF0IHRoZSBzY2hlbWEgc2VjdGlvbiBpcyBpbmNvcnJlY3QuJm5ic3A7IFRo ZSAkcmVmIGFuZCB2YWx1ZSBhcmUgcmVxdWlyZWQgYW5kIG1hbmFnZXIgaXMgc3RpbGwgc2luZ2xl IHZhbHVlZC4mbmJzcDsgSSB0aGluayB0aGUgdGV4dCBpbiA0LjMgc2hvdWxkIHNheTo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5hZ2VyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz O3dpZG93czogMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSB1c2VyJ3MgbWFuYWdlci4mbmJzcDsgQSBjb21wbGV4IHR5cGUgdGhhdCBvcHRpb25hbGx5IGFs bG93cyBzZXJ2aWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBwcm92aWRlcnMgdG8gcmVwcmVzZW50IG9yZ2FuaXphdGlvbmFsIGhpZXJhcmNoeSBieSBy ZWZlcmVuY2luZyA8cz50aGU8L3M+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90OyBhdHRyaWJ1dGUgb2Y8L3NwYW4+PC9zPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBhbm90aGVyIFVzZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBoaWwsIGRvIHlvdSBhZ3JlZT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi0tS2VsbHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzY2ltIFs8YSBocmVmPSJtYWls dG86c2NpbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGF0cmljayBSYWR0a2U8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBBcHJpbCAyNCwgMjAxNSA1OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBTQ0lNIFdHPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtzY2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dl c3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgYSBjb3VwbGUgYXNwZWN0 cyBvZiB0aGUg4oCcbWFuYWdlcuKAnSBhdHRyaWJ1dGUgdGhhdCBzZWVtIGluY29uc2lzdGVudC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SW4gNC4zIEVudGVycHJpc2UgVXNlciBTY2hlbWEgZXh0ZW5zaW9uIGl0IHNh eXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90Ozwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPm1hbmFnZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5czt3aWRvd3M6IDEiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdXNlcidzIG1hbmFnZXIuJm5i c3A7IEEgY29tcGxleCB0eXBlIHRoYXQgb3B0aW9uYWxseSBhbGxvd3Mgc2VydmljZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZXJzIHRvIHJl cHJlc2VudCBvcmdhbml6YXRpb25hbCBoaWVyYXJjaHkgYnkgcmVmZXJlbmNpbmcgdGhlPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90 OyBhdHRyaWJ1dGUgb2YgYW5vdGhlciBVc2VyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlJm5ic3A7 IFRoZSAmcXVvdDtpZCZxdW90OyBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNlbnRpbmcgdGhl IHVzZXInczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbWFuYWdlci4mbmJzcDsgUkVDT01NRU5ERUQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJHJlZiZuYnNwOyBUaGUgVVJJIG9mIHRoZSBTQ0lNIHJlc291cmNlIHJlcHJlc2VudGlu ZyB0aGUgVXNlcidzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2VyLiZuYnNwOyBSRUNPTU1FTkRFRC48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKAnDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG8g bWUgdGhhdCBzYXlzIHRoYXQgYSB1c2VyIG1heSBoYXZlIGEgc2luZ2xlIG1hbmFnZXIsIGFuZCDi gJh2YWx1ZeKAmSBhbmQg4oCYJHJlZuKAmSBhdHRyaWJ1dGVzIGFyZSBub3QgcmVxdWlyZWQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkhvd2V2ZXIgaW4gdGhlIFNjaGVtYSBzZWN0aW9uLCBtYW5hZ2VyIGlzIGxpc3Rl ZCBhcyAmcXVvdDttdWx0aVZhbHVlZDogdHJ1ZeKAnSBhbmQgdGhvdWdoIHN1YkF0dHJpYnV0ZXMg b2Yg4oCcJHJlZuKAnSBhbmQg4oCcdmFsdWXigJ0gaGF2ZSDigJxyZXF1aXJlZDpmYWxzZeKAnSB0 aGUgZGVzY3JpcHRpb24gYXR0cmlidXRlIHNheXMNCiBlYWNoIGlzIHJlcXVpcmVkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JZiDigJx2YWx1ZeKAnSBhbmQg4oCcJHJlZuKAnSBhcmVu4oCZdCByZXF1aXJlZCwgY2Fu IHRoZSBNYW5hZ2VyIHNjaGVtYSBkZXNjcmlwdGlvbiBiZSBhZGp1c3RlZD88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5TaW5jZSBtYW5hZ2VyIGlzIG11bHRpLXZhbHVlZCwgY2FuIHNlY3Rpb24gNC4zIGJlIHVwZGF0 ZWQgdG8gc2F5LiAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUg dXNlcidzIG1hbmFnZXJzLiAmbmJzcDtBIG11bHRpLXZhbHVlZCBjb21wbGV4IHR5cGUNCiB0aGF0 4oCm4oCdICZuYnNwO090aGVyd2lzZSwgYXQgZmlyc3QgcmVhZCAob3IgZm9yIGFueW9uZSBjb21p bmcgZnJvbSBTQ0lNIDEuMSkgaXQgaXMgbm90IG9idmlvdXMgdGhhdCBpdCBoYXMgYmVjb21lIG11 bHRpLXZhbHVlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYXRyaWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB3923BDEDBF0627E18E78A09E2D60BN1PR04MB392namprd_-- From nobody Thu Apr 30 11:42: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 8A2791B2EBA for ; Thu, 30 Apr 2015 11:42:13 -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 rAgtxIE9isYX for ; Thu, 30 Apr 2015 11:42: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 2DD461B2EB9 for ; Thu, 30 Apr 2015 11:42:11 -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 t3UIg9PR004832 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 18:42:10 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 t3UIg8Ps012780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2015 18:42:08 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3UIg78S013566; Thu, 30 Apr 2015 18:42:07 GMT MIME-Version: 1.0 Message-ID: <95d74655-eca8-49ef-a128-320b7a1da07a@default> Date: Thu, 30 Apr 2015 11:42:06 -0700 (PDT) From: Michael Frost Sender: Michael Frost To: Kelly Grizzle , Phil Hunt References: 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="__1430419327368218348abhmp0006.oracle.com" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Patrick Radtke , SCIM WG 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: Thu, 30 Apr 2015 18:42:13 -0000 --__1430419327368218348abhmp0006.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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]=20 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 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. =C2=A0 =C2=A0 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 =C2=A0 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.=C2=A0 Phil On Apr 30, 2015, at 06:41, Kelly Grizzle wrote: I had forgotten about that.=C2=A0 The most discussion that I found was in t= his 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 updated. It looks like it sh= ould be multi-valued =C2=A0 since many orgs have people with multiple reporting relationships. =C2=A0 I don=E2=80=99t remember ever discussing this any further or if we achieved= consensus on changing this.=C2=A0 The email thread doesn=E2=80=99t have an= y 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 managers upon anyone. ;)=C2=A0 = Being serious, though, this might fit better as a second attribute that des= cribes other reporting relationships. =C2=A0 Anyone else remember this?=20 =C2=A0 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 =C2=A0 I believe I raised this issue before and the consensus was to leave it. =C2= =A0Maybe I am mistaken? =C2=A0 Phil =C2=A0 @independentid HYPERLINK "http://www.independentid.com"www.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com"phil.hunt@oracle.com =C2=A0 On Apr 29, 2015, at 4:06 PM, Kelly Grizzle wrote: =C2=A0 Patrick =E2=80=A6 thanks for the feedback. =C2=A0 I think that the schema section is incorrect.=C2=A0 The $ref and value are = required and manager 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 tha= t optionally allows service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 providers to represent organizational hierar= chy 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 tha= t optionally allows service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 providers to represent organizational hierar= chy by referencing the =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 re= presenting 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 repr= esenting 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, and =E2=80=98value= =E2=80=99 and =E2=80=98$ref=E2=80=99 attributes are not required. =C2=A0 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=9Cvalu= e=E2=80=9D have =E2=80=9Crequired:false=E2=80=9D the description attribute = says each is required. =C2=A0 If =E2=80=9Cvalue=E2=80=9D and =E2=80=9C$ref=E2=80=9D aren=E2=80=99t requir= ed, can the Manager schema description be adjusted? Since manager is multi-valued, can section 4.3 be updated to say. "The user= 's managers. =C2=A0A 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-valued. =C2=A0 Thanks, =C2=A0 Patrick =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --__1430419327368218348abhmp0006.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

It is mul= ti-valued in the example in 8.3 and in the schema on page 60, and in our im= plementation.=C2=A0 I think only the text in section 4.3 refers to manager = as singular.

 

-mrf

 

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

<= o:p> 

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


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

 

 

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

<= p class=3DMsoNormal> 

I recall= your comment and given lack of input at the time, it was clear there was n= o 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 mos= t discussion that I found was in this email - http://www.ietf.org/mail-arc= hive/web/scim/current/msg02007.html.

 

&nbs= p;  Note, the sche= ma also needs to be updated. It looks like it should be multi-valued=

  since many orgs have people with multiple reporting relationsh= ips.

 

I don=E2=80=99t remember ever discussing= this any further or if we achieved consensus on changing this.  The e= mail 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?

 

 

I believe I raised t= his issue before and the consensus was to leave it.  Maybe I am mistak= en?

 

=

 

 

Pat= rick =E2=80=A6 thanks for the feedback.

 

I th= ink 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 shou= ld say:

 =

manager

      The user's manager.  A complex type=
 that optionally allows service
&nbs=
p;     providers to represent organizational hierarchy =
by referencing the
 &=
nbsp;    "id" attribute of another User.
 
Phil, do you agree?
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'> 
--Kelly
 
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Patrick Radtk=
e
Sent: Friday, April 24, 2015 5:47 PM
To: SCIM WG
<=
b>Subject: [scim] Manager attribute wording suggestion

 

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

=  <= /span>

In 4.3 Enterprise User Schema= extension it says

"mana= ger

   =
   The user's manager.  A complex type that optionally allow=
s service
    &n=
bsp; providers to represent organizational hierarchy by referencing the
      "id=
" attribute of another User.
&n=
bsp;
      =
value  The "id" of the SCIM resource representing the user's=

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

=E2=80=9C

To me that sa= ys 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: tru= e=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 attrib= ute says each is required.

&n= bsp;

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

Since manager is = multi-valued, can section 4.3 be updated to say. "The user's manager= s.  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

 

 

 

&n= bsp;

 

--__1430419327368218348abhmp0006.oracle.com-- From nobody Thu Apr 30 12:20: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 32A141A9135 for ; Thu, 30 Apr 2015 12:20: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 CcLGTHuJTTQG for ; Thu, 30 Apr 2015 12:20:41 -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 394091A8B84 for ; Thu, 30 Apr 2015 12:20:41 -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 t3UJKeNi030164 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Apr 2015 19:20:40 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 t3UJKdH3027066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2015 19:20:39 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 t3UJKcYW000805; Thu, 30 Apr 2015 19:20:38 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Apr 2015 12:20:37 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC33F1D0-6816-4A96-9370-6B52D156614E" From: Phil Hunt X-Priority: 3 In-Reply-To: <95d74655-eca8-49ef-a128-320b7a1da07a@default> Date: Thu, 30 Apr 2015 12:20:36 -0700 Message-Id: <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> To: Michael Frost X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Patrick Radtke , SCIM WG , 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: Thu, 30 Apr 2015 19:20:49 -0000 --Apple-Mail=_BC33F1D0-6816-4A96-9370-6B52D156614E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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: >=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 --Apple-Mail=_BC33F1D0-6816-4A96-9370-6B52D156614E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed.

Will need consensus/direction from the chairs on this and = along 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.

 

-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=_BC33F1D0-6816-4A96-9370-6B52D156614E-- From nobody Thu Apr 30 13:50: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 5136E1A00A8 for ; Thu, 30 Apr 2015 13:50:44 -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 wjWCvYGHHOfP for ; Thu, 30 Apr 2015 13:50:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C751E1A0060 for ; Thu, 30 Apr 2015 13:50:40 -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; Thu, 30 Apr 2015 20:50: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.008; Thu, 30 Apr 2015 20:50:39 +0000 From: Kelly Grizzle To: Phil Hunt , Michael Frost Thread-Topic: [scim] Manager attribute wording suggestion Thread-Index: AQHQfuCe7BnrE2sksEaJOKg/kqo11Z1ko+zggAAKSYCAAOjR4IAAH7qAgAAhU9CAABTiAIAACsIAgAAXPuA= Date: Thu, 30 Apr 2015 20:50:38 +0000 Message-ID: References: <95d74655-eca8-49ef-a128-320b7a1da07a@default> <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> In-Reply-To: <472BFF6D-159B-4CF2-9A8A-AEBABA546073@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 372AE419009B94372AE566 authentication-results: oracle.com; 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: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(164054003)(51914003)(19625215002)(19580395003)(54356999)(77156002)(50986999)(16236675004)(5001770100001)(86362001)(74316001)(102836002)(62966003)(76176999)(106116001)(33656002)(15975445007)(19617315012)(40100003)(16601075003)(19580405001)(99286002)(2950100001)(2900100001)(87936001)(76576001)(93886004)(122556002)(66066001)(19609705001)(46102003)(92566002)(19300405004)(2656002)(5001960100002); 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_BN1PR04MB392BEEA50DBDAE5DC7C7A30E2D60BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2015 20:50:38.8588 (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: Cc: Patrick Radtke , SCIM WG 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: Thu, 30 Apr 2015 20:50:44 -0000 --_000_BN1PR04MB392BEEA50DBDAE5DC7C7A30E2D60BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgbG9va3MgbGlrZSB0aGlzIGdvdCBjaGFuZ2VkIGJhY2sgaW4gT2N0b2JlciBpbiByZXZpc2lv biAxMiBvZiB0aGUgY29yZSBzY2hlbWEgZG9jLg0KDQogICBEcmFmdCAxMiAtIFBIIC0gTml0cyAv IENvcnJlY3Rpb25zDQoNCiAgICAgIC4uLg0KDQogICAgICBDb3JyZWN0ZWQgZW50ZXJwcmlzZSBV c2VyIG1hbmFnZXIgYXR0cmlidXRlIHRvIHVzZSBzdWItYXR0cmlidXRlDQogICAgICB2YWx1ZSBh bmQgbWFrZSBtdWx0aS12YWx1ZWQNCg0KSSBoYWRu4oCZdCByZWFsaXplZCB0aGF0IHRoaXMgY2hh bmdlIHdlbnQgaW4uICBVcCB1bnRpbCB0aGVuIG1hbmFnZXIgaGFkIGJlZW4gc2luZ2xlLXZhbHVl ZCBzaW5jZSBTQ0lNIDEuMC4gIElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IHRoaXMgY2hhbmdl IHNob3VsZCBzdGF5LCB0aGVuIGl0IHNlZW1zIGxpa2Ugd2UgbmVlZCB0byB1cGRhdGUgc2VjdGlv biA0LjMuDQoNClJlZ2FyZGluZyB0aGUgZmFjdCB0aGF0IOKAnHJlcXVpcmVk4oCdIGlzIGZhbHNl IGZvciB0aGUg4oCcdmFsdWXigJ0gYW5kIOKAnCRyZWbigJ0gc3ViLWF0dHJpYnV0ZXMsIHRoaXMg aXMgY29uc2lzdGVudCB3aXRoIHRoZSByZXN0IG9mIHRoZSBhdHRyaWJ1dGUgZGVmaW5pdGlvbnMg dGhhdCBhcmUgcmVmZXJlbmNlcy4gIEkgYWdyZWUgd2l0aCB5b3UsIFBhdHJpY2ssIHRoYXQgdGhl c2Ugc2hvdWxkIGJlIHJlcXVpcmVkLg0KDQotLUtlbGx5DQoNCkZyb206IFBoaWwgSHVudCBbbWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDE1 IDI6MjEgUE0NClRvOiBNaWNoYWVsIEZyb3N0DQpDYzogS2VsbHkgR3JpenpsZTsgUGF0cmljayBS YWR0a2U7IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBbc2NpbV0gTWFuYWdlciBhdHRyaWJ1dGUgd29y ZGluZyBzdWdnZXN0aW9uDQoNCkFncmVlZC4NCg0KV2lsbCBuZWVkIGNvbnNlbnN1cy9kaXJlY3Rp b24gZnJvbSB0aGUgY2hhaXJzIG9uIHRoaXMgYW5kIGFsb25nIHdpdGggdGhlIG90aGVyIGlzc3Vl ICg0MDEvNDAzLzUwMSBzdGF0dXMgY29kZSBjbGFyaWZpY2F0aW9uKS4NCg0KUGhpbA0KDQpAaW5k ZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp ZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ DQoNCk9uIEFwciAzMCwgMjAxNSwgYXQgMTE6NDIgQU0sIE1pY2hhZWwgRnJvc3QgPG1pY2hhZWwu ZnJvc3RAb3JhY2xlLmNvbTxtYWlsdG86bWljaGFlbC5mcm9zdEBvcmFjbGUuY29tPj4gd3JvdGU6 DQoNCkl0IGlzIG11bHRpLXZhbHVlZCBpbiB0aGUgZXhhbXBsZSBpbiA4LjMgYW5kIGluIHRoZSBz Y2hlbWEgb24gcGFnZSA2MCwgYW5kIGluIG91ciBpbXBsZW1lbnRhdGlvbi4gIEkgdGhpbmsgb25s eSB0aGUgdGV4dCBpbiBzZWN0aW9uIDQuMyByZWZlcnMgdG8gbWFuYWdlciBhcyBzaW5ndWxhci4N Cg0KLW1yZg0KDQpGcm9tOiBLZWxseSBHcml6emxlIFttYWlsdG86a2VsbHkuZ3JpenpsZUBzYWls cG9pbnQuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDE1IDEwOjI4IEFNDQpUbzog UGhpbCBIdW50DQpDYzogUGF0cmljayBSYWR0a2U7IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBbc2Np bV0gTWFuYWdlciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0aW9uDQoNCkRvZXMgYW55b25lIGhh dmUgYW55IHN0cm9uZyBvcGluaW9ucyBhYm91dCBtYWtpbmcgbWFuYWdlciBtdWx0aS12YWx1ZWQg b3IgbGVhdmluZyBpdCBhcy1pcz8NCg0KRWl0aGVyIHdheSB3ZSBzaG91bGQgcHJvYmFibHkgY2xl YW4gdXAgdGhlIHRleHQgaW4gc2VjdGlvbiA0LjMgYW5kIHRoZSBzY2hlbWEgZGVmaW5pdGlvbi4N Cg0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAxNSAxMDoyOCBBTQ0KVG86IEtlbGx5IEdyaXp6bGUNCkNj OiBQYXRyaWNrIFJhZHRrZTsgU0NJTSBXRw0KU3ViamVjdDogUmU6IE1hbmFnZXIgYXR0cmlidXRl IHdvcmRpbmcgc3VnZ2VzdGlvbg0KDQpJIHJlY2FsbCB5b3VyIGNvbW1lbnQgYW5kIGdpdmVuIGxh Y2sgb2YgaW5wdXQgYXQgdGhlIHRpbWUsIGl0IHdhcyBjbGVhciB0aGVyZSB3YXMgbm8gY29uc2Vu c3VzIGZvciBjaGFuZ2UuIEkgaGFkIHRvIGxlYXZlIGl0IGFzIGlzIGRlc3BpdGUgdGhpbmtpbmcg aXQgbmVlZGVkIHRvIGJlIG11bHRpLXZhbHVlZC4NCg0KUGhpbA0KDQpPbiBBcHIgMzAsIDIwMTUs IGF0IDA2OjQxLCBLZWxseSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208bWFp bHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+IHdyb3RlOg0KSSBoYWQgZm9yZ290dGVu IGFib3V0IHRoYXQuICBUaGUgbW9zdCBkaXNjdXNzaW9uIHRoYXQgSSBmb3VuZCB3YXMgaW4gdGhp cyBlbWFpbCAtIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJl bnQvbXNnMDIwMDcuaHRtbC4NCg0KICAgTm90ZSwgdGhlIHNjaGVtYSBhbHNvIG5lZWRzIHRvIGJl IHVwZGF0ZWQuIEl0IGxvb2tzIGxpa2UgaXQgc2hvdWxkIGJlIG11bHRpLXZhbHVlZA0KICBzaW5j ZSBtYW55IG9yZ3MgaGF2ZSBwZW9wbGUgd2l0aCBtdWx0aXBsZSByZXBvcnRpbmcgcmVsYXRpb25z aGlwcy4NCg0KSSBkb27igJl0IHJlbWVtYmVyIGV2ZXIgZGlzY3Vzc2luZyB0aGlzIGFueSBmdXJ0 aGVyIG9yIGlmIHdlIGFjaGlldmVkIGNvbnNlbnN1cyBvbiBjaGFuZ2luZyB0aGlzLiAgVGhlIGVt YWlsIHRocmVhZCBkb2VzbuKAmXQgaGF2ZSBhbnkgbW9yZSBkaXNjdXNzaW9uLg0KDQpJ4oCZbSBu b3Qgc3VyZSB0aGF0IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBtdWx0aXZhbHVlZC4gIElm IGFueXRoaW5nIGVsc2UsIEkgd291bGQgbmV2ZXIgd2lzaCBtdWx0aXBsZSBtYW5hZ2VycyB1cG9u IGFueW9uZS4gOykgIEJlaW5nIHNlcmlvdXMsIHRob3VnaCwgdGhpcyBtaWdodCBmaXQgYmV0dGVy IGFzIGEgc2Vjb25kIGF0dHJpYnV0ZSB0aGF0IGRlc2NyaWJlcyBvdGhlciByZXBvcnRpbmcgcmVs YXRpb25zaGlwcy4NCg0KQW55b25lIGVsc2UgcmVtZW1iZXIgdGhpcz8NCg0KRnJvbTogUGhpbCBI dW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDI5LCAyMDE1IDY6NDEgUE0NClRvOiBLZWxseSBHcml6emxlDQpDYzogUGF0cmljayBSYWR0a2U7 IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rp b24NCg0KSSBiZWxpZXZlIEkgcmFpc2VkIHRoaXMgaXNzdWUgYmVmb3JlIGFuZCB0aGUgY29uc2Vu c3VzIHdhcyB0byBsZWF2ZSBpdC4gIE1heWJlIEkgYW0gbWlzdGFrZW4/DQoNClBoaWwNCg0KQGlu ZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50 aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT4NCg0KT24gQXByIDI5LCAyMDE1LCBhdCA0OjA2IFBNLCBLZWxseSBHcml6emxlIDxrZWxseS5n cml6emxlQHNhaWxwb2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+ IHdyb3RlOg0KDQpQYXRyaWNrIOKApiB0aGFua3MgZm9yIHRoZSBmZWVkYmFjay4NCg0KSSB0aGlu ayB0aGF0IHRoZSBzY2hlbWEgc2VjdGlvbiBpcyBpbmNvcnJlY3QuICBUaGUgJHJlZiBhbmQgdmFs dWUgYXJlIHJlcXVpcmVkIGFuZCBtYW5hZ2VyIGlzIHN0aWxsIHNpbmdsZSB2YWx1ZWQuICBJIHRo aW5rIHRoZSB0ZXh0IGluIDQuMyBzaG91bGQgc2F5Og0KDQptYW5hZ2VyDQoNCiAgICAgIFRoZSB1 c2VyJ3MgbWFuYWdlci4gIEEgY29tcGxleCB0eXBlIHRoYXQgb3B0aW9uYWxseSBhbGxvd3Mgc2Vy dmljZQ0KDQogICAgICBwcm92aWRlcnMgdG8gcmVwcmVzZW50IG9yZ2FuaXphdGlvbmFsIGhpZXJh cmNoeSBieSByZWZlcmVuY2luZyB0aGUNCg0KICAgICAgImlkIiBhdHRyaWJ1dGUgb2YgYW5vdGhl ciBVc2VyLg0KDQpQaGlsLCBkbyB5b3UgYWdyZWU/DQoNCi0tS2VsbHkNCg0KRnJvbTogc2NpbSBb bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdHJpY2sgUmFkdGtl DQpTZW50OiBGcmlkYXksIEFwcmlsIDI0LCAyMDE1IDU6NDcgUE0NClRvOiBTQ0lNIFdHDQpTdWJq ZWN0OiBbc2NpbV0gTWFuYWdlciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0aW9uDQoNClRoZXJl IGFyZSBhIGNvdXBsZSBhc3BlY3RzIG9mIHRoZSDigJxtYW5hZ2Vy4oCdIGF0dHJpYnV0ZSB0aGF0 IHNlZW0gaW5jb25zaXN0ZW50Lg0KDQpJbiA0LjMgRW50ZXJwcmlzZSBVc2VyIFNjaGVtYSBleHRl bnNpb24gaXQgc2F5cw0KIm1hbmFnZXINCg0KICAgICAgVGhlIHVzZXIncyBtYW5hZ2VyLiAgQSBj b21wbGV4IHR5cGUgdGhhdCBvcHRpb25hbGx5IGFsbG93cyBzZXJ2aWNlDQoNCiAgICAgIHByb3Zp ZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5IGJ5IHJlZmVyZW5jaW5n IHRoZQ0KDQogICAgICAiaWQiIGF0dHJpYnV0ZSBvZiBhbm90aGVyIFVzZXIuDQoNCg0KDQogICAg ICB2YWx1ZSAgVGhlICJpZCIgb2YgdGhlIFNDSU0gcmVzb3VyY2UgcmVwcmVzZW50aW5nIHRoZSB1 c2VyJ3MNCg0KICAgICAgICAgbWFuYWdlci4gIFJFQ09NTUVOREVELg0KDQoNCg0KICAgICAgJHJl ZiAgVGhlIFVSSSBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNlbnRpbmcgdGhlIFVzZXIncw0K DQogICAgICAgICBtYW5hZ2VyLiAgUkVDT01NRU5ERUQuDQrigJwNClRvIG1lIHRoYXQgc2F5cyB0 aGF0IGEgdXNlciBtYXkgaGF2ZSBhIHNpbmdsZSBtYW5hZ2VyLCBhbmQg4oCYdmFsdWXigJkgYW5k IOKAmCRyZWbigJkgYXR0cmlidXRlcyBhcmUgbm90IHJlcXVpcmVkLg0KDQpIb3dldmVyIGluIHRo ZSBTY2hlbWEgc2VjdGlvbiwgbWFuYWdlciBpcyBsaXN0ZWQgYXMgIm11bHRpVmFsdWVkOiB0cnVl 4oCdIGFuZCB0aG91Z2ggc3ViQXR0cmlidXRlcyBvZiDigJwkcmVm4oCdIGFuZCDigJx2YWx1ZeKA nSBoYXZlIOKAnHJlcXVpcmVkOmZhbHNl4oCdIHRoZSBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUgc2F5 cyBlYWNoIGlzIHJlcXVpcmVkLg0KDQpJZiDigJx2YWx1ZeKAnSBhbmQg4oCcJHJlZuKAnSBhcmVu 4oCZdCByZXF1aXJlZCwgY2FuIHRoZSBNYW5hZ2VyIHNjaGVtYSBkZXNjcmlwdGlvbiBiZSBhZGp1 c3RlZD8NClNpbmNlIG1hbmFnZXIgaXMgbXVsdGktdmFsdWVkLCBjYW4gc2VjdGlvbiA0LjMgYmUg dXBkYXRlZCB0byBzYXkuICJUaGUgdXNlcidzIG1hbmFnZXJzLiAgQSBtdWx0aS12YWx1ZWQgY29t cGxleCB0eXBlIHRoYXTigKbigJ0gIE90aGVyd2lzZSwgYXQgZmlyc3QgcmVhZCAob3IgZm9yIGFu eW9uZSBjb21pbmcgZnJvbSBTQ0lNIDEuMSkgaXQgaXMgbm90IG9idmlvdXMgdGhhdCBpdCBoYXMg YmVjb21lIG11bHRpLXZhbHVlZC4NCg0KVGhhbmtzLA0KDQpQYXRyaWNrDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGlu ZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_BN1PR04MB392BEEA50DBDAE5DC7C7A30E2D60BN1PR04MB392namprd_ 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 aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFw cGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGxvb2tzIGxpa2UgdGhpcyBnb3QgY2hh bmdlZCBiYWNrIGluIE9jdG9iZXIgaW4gcmV2aXNpb24gMTIgb2YgdGhlIGNvcmUgc2NoZW1hIGRv Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBEcmFmdCAxMiAtIFBIIC0gTml0cyAvIENvcnJlY3Rpb25zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29ycmVjdGVkIGVudGVy cHJpc2UgVXNlciBtYW5hZ2VyIGF0dHJpYnV0ZSB0byB1c2Ugc3ViLWF0dHJpYnV0ZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUgYW5kIG1ha2UgbXVsdGktdmFs dWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIGhhZG7igJl0IHJlYWxpemVkIHRoYXQgdGhpcyBjaGFuZ2Ugd2VudCBp bi4gJm5ic3A7VXAgdW50aWwgdGhlbiBtYW5hZ2VyIGhhZCBiZWVuIHNpbmdsZS12YWx1ZWQgc2lu Y2UgU0NJTSAxLjAuJm5ic3A7IElmIHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IHRoaXMgY2hhbmdl IHNob3VsZCBzdGF5LA0KIHRoZW4gaXQgc2VlbXMgbGlrZSB3ZSBuZWVkIHRvIHVwZGF0ZSBzZWN0 aW9uIDQuMy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgdGhlIGZhY3QgdGhhdCDigJxyZXF1aXJlZOKA nSBpcyBmYWxzZSBmb3IgdGhlIOKAnHZhbHVl4oCdIGFuZCDigJwkcmVm4oCdIHN1Yi1hdHRyaWJ1 dGVzLCB0aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgYXR0cmlidXRlIGRl ZmluaXRpb25zIHRoYXQgYXJlDQogcmVmZXJlbmNlcy4mbmJzcDsgSSBhZ3JlZSB3aXRoIHlvdSwg UGF0cmljaywgdGhhdCB0aGVzZSBzaG91bGQgYmUgcmVxdWlyZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLUtlbGx5 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMTUgMjoyMSBQ TTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBGcm9zdDxicj4NCjxiPkNjOjwvYj4gS2VsbHkgR3Jp enpsZTsgUGF0cmljayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtz Y2ltXSBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dlc3Rpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaWxsIG5lZWQgY29uc2Vuc3VzL2RpcmVjdGlv biBmcm9tIHRoZSBjaGFpcnMgb24gdGhpcyBhbmQgYWxvbmcgd2l0aCB0aGUgb3RoZXIgaXNzdWUg KDQwMS80MDMvNTAxIHN0YXR1cyBjb2RlIGNsYXJpZmljYXRpb24pLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBl bmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBBcHIgMzAsIDIwMTUsIGF0IDExOjQyIEFNLCBNaWNoYWVsIEZyb3N0ICZsdDs8YSBocmVmPSJt YWlsdG86bWljaGFlbC5mcm9zdEBvcmFjbGUuY29tIj5taWNoYWVsLmZyb3N0QG9yYWNsZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBpcyBtdWx0 aS12YWx1ZWQgaW4gdGhlIGV4YW1wbGUgaW4gOC4zIGFuZCBpbiB0aGUgc2NoZW1hIG9uIHBhZ2Ug NjAsIGFuZCBpbiBvdXIgaW1wbGVtZW50YXRpb24uJm5ic3A7IEkgdGhpbmsgb25seSB0aGUgdGV4 dCBpbiBzZWN0aW9uIDQuMyByZWZlcnMgdG8gbWFuYWdlciBhcw0KIHNpbmd1bGFyLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LW1yZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtlbGx5IEdyaXp6bGUgWzxhIGhyZWY9Im1haWx0 bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iPm1haWx0bzprZWxseS5ncml6emxlQHNhaWxw b2ludC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAx NSAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50PGJyPg0KPGI+Q2M6PC9iPiBQYXRy aWNrIFJhZHRrZTsgU0NJTSBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIE1hbmFn ZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Eb2VzIGFueW9uZSBoYXZlIGFueSBzdHJvbmcgb3BpbmlvbnMgYWJvdXQgbWFraW5n IG1hbmFnZXIgbXVsdGktdmFsdWVkIG9yIGxlYXZpbmcgaXQgYXMtaXM/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkVpdGhlciB3YXkgd2Ugc2hvdWxkIHByb2JhYmx5IGNsZWFu IHVwIHRoZSB0ZXh0IGluIHNlY3Rpb24gNC4zIGFuZCB0aGUgc2NoZW1hIGRlZmluaXRpb24uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBo aWwgSHVudCBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5tYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJp bCAzMCwgMjAxNSAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gS2VsbHkgR3JpenpsZTxicj4NCjxi PkNjOjwvYj4gUGF0cmljayBSYWR0a2U7IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IE1hbmFnZXIgYXR0cmlidXRlIHdvcmRpbmcgc3VnZ2VzdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlY2FsbCB5b3VyIGNvbW1lbnQg YW5kIGdpdmVuIGxhY2sgb2YgaW5wdXQgYXQgdGhlIHRpbWUsIGl0IHdhcyBjbGVhciB0aGVyZSB3 YXMgbm8gY29uc2Vuc3VzIGZvciBjaGFuZ2UuIEkgaGFkIHRvIGxlYXZlIGl0IGFzIGlzIGRlc3Bp dGUgdGhpbmtpbmcgaXQgbmVlZGVkIHRvIGJlIG11bHRpLXZhbHVlZC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gQXByIDMwLCAyMDE1LCBhdCAwNjo0MSwgS2Vs bHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNv bSI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhZCBmb3Jnb3R0ZW4gYWJvdXQgdGhhdC4m bmJzcDsgVGhlIG1vc3QgZGlzY3Vzc2lvbiB0aGF0IEkgZm91bmQgd2FzIGluIHRoaXMgZW1haWwg LQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NjaW0vY3Vy cmVudC9tc2cwMjAwNy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv c2NpbS9jdXJyZW50L21zZzAyMDA3Lmh0bWw8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPk5vdGUsIHRoZSBzY2hlbWEgYWxz byBuZWVkcyB0byBiZSB1cGRhdGVkLiBJdCBsb29rcyBsaWtlIGl0IHNob3VsZCBiZSBtdWx0aS12 YWx1ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Jm5ic3A7IHNpbmNlIG1hbnkgb3JncyBoYXZlIHBlb3Bs ZSB3aXRoIG11bHRpcGxlIHJlcG9ydGluZyByZWxhdGlvbnNoaXBzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27i gJl0IHJlbWVtYmVyIGV2ZXIgZGlzY3Vzc2luZyB0aGlzIGFueSBmdXJ0aGVyIG9yIGlmIHdlIGFj aGlldmVkIGNvbnNlbnN1cyBvbiBjaGFuZ2luZyB0aGlzLiZuYnNwOyBUaGUgZW1haWwgdGhyZWFk IGRvZXNu4oCZdCBoYXZlIGFueSBtb3JlIGRpc2N1c3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBub3Qg c3VyZSB0aGF0IEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBtdWx0aXZhbHVlZC4mbmJzcDsg SWYgYW55dGhpbmcgZWxzZSwgSSB3b3VsZCBuZXZlciB3aXNoIG11bHRpcGxlIG1hbmFnZXJzIHVw b24gYW55b25lLiA7KSZuYnNwOyBCZWluZyBzZXJpb3VzLCB0aG91Z2gsIHRoaXMNCiBtaWdodCBm aXQgYmV0dGVyIGFzIGEgc2Vjb25kIGF0dHJpYnV0ZSB0aGF0IGRlc2NyaWJlcyBvdGhlciByZXBv cnRpbmcgcmVsYXRpb25zaGlwcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFueW9uZSBlbHNlIHJlbWVtYmVyIHRoaXM/ DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDE1IDY6NDEgUE08YnI+DQo8Yj5Ubzo8 L2I+IEtlbGx5IEdyaXp6bGU8YnI+DQo8Yj5DYzo8L2I+IFBhdHJpY2sgUmFkdGtlOyBTQ0lNIFdH PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNYW5hZ2VyIGF0dHJpYnV0ZSB3b3JkaW5nIHN1Z2dl c3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJl bGlldmUgSSByYWlzZWQgdGhpcyBpc3N1ZSBiZWZvcmUgYW5kIHRoZSBjb25zZW5zdXMgd2FzIHRv IGxlYXZlIGl0LiAmbmJzcDtNYXliZSBJIGFtIG1pc3Rha2VuPzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyI+d3d3 LmluZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXBy IDI5LCAyMDE1LCBhdCA0OjA2IFBNLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86 a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIj5rZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXRyaWNrIOKA piB0aGFua3MgZm9yIHRoZSBmZWVkYmFjay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCB0aGUgc2No ZW1hIHNlY3Rpb24gaXMgaW5jb3JyZWN0LiZuYnNwOyBUaGUgJHJlZiBhbmQgdmFsdWUgYXJlIHJl cXVpcmVkIGFuZCBtYW5hZ2VyIGlzIHN0aWxsIHNpbmdsZSB2YWx1ZWQuJm5ic3A7IEkgdGhpbmsg dGhlIHRleHQgaW4gNC4zIHNob3VsZCBzYXk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFuYWdlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5czt3aWRvd3M6IDEiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdXNlcidzIG1hbmFnZXIuJm5ic3A7 IEEgY29tcGxleCB0eXBlIHRoYXQgb3B0aW9uYWxseSBhbGxvd3Mgc2VydmljZTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZXJzIHRvIHJlcHJl c2VudCBvcmdhbml6YXRpb25hbCBoaWVyYXJjaHkgYnkgcmVmZXJlbmNpbmcgPHM+dGhlPC9zPjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 aWQmcXVvdDsgYXR0cmlidXRlIG9mPC9zcGFuPjwvcz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYW5vdGhlciBVc2Vy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5QaGlsLCBkbyB5b3UgYWdyZWU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLUtlbGx5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gc2NpbSBbPGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlBhdHJpY2sgUmFkdGtlPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjQsIDIwMTUg NTo0NyBQTTxicj4NCjxiPlRvOjwvYj4gU0NJTSBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2Np bV0gTWFuYWdlciBhdHRyaWJ1dGUgd29yZGluZyBzdWdnZXN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhlcmUgYXJlIGEgY291cGxlIGFzcGVjdHMgb2YgdGhlIOKAnG1hbmFnZXLigJ0g YXR0cmlidXRlIHRoYXQgc2VlbSBpbmNvbnNpc3RlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIDQuMyBFbnRl cnByaXNlIFVzZXIgU2NoZW1hIGV4dGVuc2lvbiBpdCBzYXlzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5h Z2VyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXM7d2lkb3dzOiAxIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlIHVzZXIncyBtYW5hZ2VyLiZuYnNwOyBBIGNvbXBsZXggdHlwZSB0aGF0 IG9wdGlvbmFsbHkgYWxsb3dzIHNlcnZpY2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGVycyB0byByZXByZXNlbnQgb3JnYW5pemF0aW9uYWwg aGllcmFyY2h5IGJ5IHJlZmVyZW5jaW5nIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWQmcXVvdDsgYXR0cmlidXRlIG9mIGFub3RoZXIg VXNlci48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSZuYnNwOyBUaGUgJnF1b3Q7aWQmcXVvdDsgb2Yg dGhlIFNDSU0gcmVzb3VyY2UgcmVwcmVzZW50aW5nIHRoZSB1c2VyJ3M8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFn ZXIuJm5ic3A7IFJFQ09NTUVOREVELjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICRyZWYmbmJzcDsgVGhlIFVS SSBvZiB0aGUgU0NJTSByZXNvdXJjZSByZXByZXNlbnRpbmcgdGhlIFVzZXInczwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWFuYWdlci4mbmJzcDsgUkVDT01NRU5ERUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvIG1lIHRoYXQgc2F5cyB0aGF0IGEgdXNl ciBtYXkgaGF2ZSBhIHNpbmdsZSBtYW5hZ2VyLCBhbmQg4oCYdmFsdWXigJkgYW5kIOKAmCRyZWbi gJkgYXR0cmlidXRlcyBhcmUgbm90IHJlcXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3dldmVyIGluIHRo ZSBTY2hlbWEgc2VjdGlvbiwgbWFuYWdlciBpcyBsaXN0ZWQgYXMgJnF1b3Q7bXVsdGlWYWx1ZWQ6 IHRydWXigJ0gYW5kIHRob3VnaCBzdWJBdHRyaWJ1dGVzIG9mIOKAnCRyZWbigJ0gYW5kIOKAnHZh bHVl4oCdIGhhdmUg4oCccmVxdWlyZWQ6ZmFsc2XigJ0gdGhlIGRlc2NyaXB0aW9uIGF0dHJpYnV0 ZSBzYXlzDQogZWFjaCBpcyByZXF1aXJlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYg4oCcdmFsdWXigJ0gYW5k IOKAnCRyZWbigJ0gYXJlbuKAmXQgcmVxdWlyZWQsIGNhbiB0aGUgTWFuYWdlciBzY2hlbWEgZGVz Y3JpcHRpb24gYmUgYWRqdXN0ZWQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2luY2UgbWFuYWdlciBpcyBtdWx0 aS12YWx1ZWQsIGNhbiBzZWN0aW9uIDQuMyBiZSB1cGRhdGVkIHRvIHNheS4gJnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHVzZXIncyBtYW5hZ2Vycy4gJm5ic3A7 QSBtdWx0aS12YWx1ZWQgY29tcGxleCB0eXBlDQogdGhhdOKApuKAnSAmbmJzcDtPdGhlcndpc2Us IGF0IGZpcnN0IHJlYWQgKG9yIGZvciBhbnlvbmUgY29taW5nIGZyb20gU0NJTSAxLjEpIGl0IGlz IG5vdCBvYnZpb3VzIHRoYXQgaXQgaGFzIGJlY29tZSBtdWx0aS12YWx1ZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UGF0cmljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NjaW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN1PR04MB392BEEA50DBDAE5DC7C7A30E2D60BN1PR04MB392namprd_--